How to distribute net fares to sub agents without WhatsApp
On Monday morning the fare sheet goes out: a PDF, or a screenshot of a spreadsheet, dropped into a WhatsApp group with a few dozen sub-agents in it. By Monday afternoon two of those fares have changed at the airline, one agent has forwarded the sheet to a corporate client "so they can see the price", and somebody in Sharjah is asking whether the Karachi fare still includes the second bag. That is how most consolidators still distribute net fares to sub agents, and it works right up until the week it costs more than it earns.
This piece is about moving that distribution off messages and into a system that enforces your own rules: who sees which fare, at what price, against how much credit. Not because software is fashionable, but because each of the three failures below lands on your BSP statement, not on your sub-agent's.
Three things that go wrong when fares travel by message
None of these is dramatic on the day it happens. That is the problem.
The fare is already stale
A net fare is a snapshot of an inventory position that keeps moving. The moment it leaves your system as an image, it stops updating. The sub-agent quotes it to a family on Tuesday, the family pays on Wednesday, and the booking class it was built on closed on Monday night. Now you either reprice and lose the agent's goodwill, or you honour it and eat the difference. Agents learn quickly which consolidator honours stale sheets, and send that one their hardest bookings.
Your net leaks
A fare sheet has no idea who is reading it. Forwarded once, it reaches a retail customer who now knows exactly what the agent pays; forwarded twice, it reaches a competing consolidator who now knows exactly what you pay. Neither can be taken back. The agent's margin on that client collapses, and your position in the next conversation with the airline is weaker than it was.
There is no audit trail
When an ADM arrives for a fare-rule breach, the first question is who sold what, on which conditions, at what time. If the answer lives in a chat history spread across three staff phones, you are reconstructing it from screenshots while the deadline runs. The same is true when an agent disputes an invoice: your word, their word, and a voice note.
Add those up and the cost of getting this wrong is not a software line. It is the ADMs you cannot pass back because you cannot prove who issued under which rule, the stale-fare differences you absorb to keep good agents, and the airline negotiations you weaken because your net is circulating in public.
Distribute net fares to sub agents through rules, not messages
The alternative is unglamorous: a portal where each sub-agent signs in, searches live, and sees the price you decided they should see. The fare is never a document, so it cannot go stale or be forwarded. It is a result, recalculated on every search, under your markup and your rules.
On this platform, a consolidator account is opened from the consolidator page, and that one account can act as a consolidator, share its supplier content with a network, and sell white-label sites to agencies that want their own brand. Sub-agents are registered as business customers, with optional manual verification, and the storefront can require sign-in before anyone searches, so a fare is never shown to someone you have not approved. For the longer view of how that portal sits next to a public site, see the separate piece on a B2B travel portal for sub agents.
Per-agent visibility and pricing
Not every agent should see everything. A new agent in their first month does not need your best contracted hotel rates; a high-volume agent in Muscat probably should not pay the same markup as one who issues a ticket every other week. A portal is only an improvement over WhatsApp if it lets you encode those differences instead of flattening them.
Visibility here runs through supplier groups rather than one-to-one deals: a tenant sees the suppliers its groups grant it, and nothing else. That is the lever for who sees what. Pricing is the other lever, and it is where a consolidator should spend most of their thinking time, because markup logic that is easy to explain to an agent is markup logic that survives the agent comparing you with someone else. The detail is in our piece on markup strategy; the short version is this table.
| Question | Fare sheet in a chat group | Portal with your rules |
|---|---|---|
| Who can see a fare | Anyone the sheet reaches | Only agents you approved, signed in |
| How fresh the price is | As of when the sheet was made | As of the search |
| Different terms for different agents | Separate sheets, maintained by hand | Set once, applied on every search |
| Proof of what was sold, and to whom | Chat history | A booking record per agent |
| Adding a new agent | Another member in the group | An approval you control |
| A quote on a quiet Sunday | Fast, if someone answers | Fast, whether or not anyone answers |
| A complex multi-city itinerary | A person thinks about it | Often still needs that person |
The last row is the one people argue about, and fairly. A good WhatsApp desk beats any portal for an agent who wants a human to think about an awkward routing. Keep the desk for those. Move the routine Dubai–Cairo issue off it.
Credit control is part of distribution, not something after it
Most consolidators treat credit as an accounting problem: the agent books, the invoice goes out, and somebody chases at month end. That order is backwards. Every ticket you let an agent issue on credit is a small loan, and the decision to make it is taken at the moment of issue, not when finance opens the spreadsheet.
So the limit has to live where the booking happens. On this platform, sub-agent credit limits and settlement invoicing are first-class concepts rather than spreadsheets: the limit belongs to the agent, and settlement sits in the same system the agent booked in. When distribution and credit share one system, the question "can this agent issue this ticket right now?" has an answer before the ticket exists, instead of a phone call after it.
It changes the conversation with the agent, too. "Your limit is reached; settle the open invoice and you can issue again" is a rule they can see. "Finance says no" is a grudge.
What you keep control of
Moving to a portal should not mean handing your commercial judgement to a vendor. Before you sign up for anything, including this, check that you still own these:
- Which agents exist. You decide whether each one is verified by hand before their first search.
- What each group can see. Suppliers and content are granted through groups, not switched on for everyone.
- Your markup. Set by you, in your own admin panel, next to your own bookings, customers and reports.
- Who on your staff can change any of it. Role-based permissions, so the person who issues tickets is not automatically the person who edits markups.
- Credit. A limit per agent, and settlement invoicing that does not live in a spreadsheet.
- The relationship. If an agent wants a branded site of their own later, it should be something you sell them, not a reason to leave you.
That last point is easy to miss. The agents most likely to outgrow a chat group are your best ones, and the moment they want a public website they start talking to platforms. If you can provision it for them, under their brand and on your content, they stay inside your network.
Where to start
Do not move every agent in one week. Pick the handful who book most, approve them on the portal, and run it next to the WhatsApp group for a while. Watch what they still ask the group for: that list is exactly what your rules do not yet cover. If you are still working out the business model itself, how to become a flight consolidator covers the step before this one; if you are past it, the consolidator account is where the portal starts.