Travel agency customer support: running email, WhatsApp and chat from one queue

1. The problem: three channels, no booking in sight

Most agencies didn't choose to run support on email, WhatsApp and chat. Customers chose for them. Travellers message on the app they already have open. Sub-agents email because they want a written record. Someone on the website or portal opens the chat because it's right there.

Each channel works on its own. The trouble starts when they don't meet. The agent answering a WhatsApp message can't see the email the same traveller sent an hour ago. The booking reference or PNR is in the message, but the booking itself is in another tab, and the reply goes out from a personal phone or a shared inbox that nobody else can see. Over time, conversations drift outside the booking stack, and the next person to pick up the case starts from zero.

2. What a travel-specific support queue needs

Travel helpdesk software has to do the usual helpdesk jobs, and a few that only make sense in travel:

• Tickets tied to booking context when available, so whoever replies sees which booking the question is about.
• Email, WhatsApp and chat in one view, so a conversation is one ticket whichever channel it arrived on.
• Queues and team assignment: who handles which channel, and which tickets belong to which desk.
• Message history on the ticket, so a second agent can pick it up without asking the customer to repeat themselves.
• Replies sent from the same place the ticket is read, not copied into a phone or a personal inbox.
• Chat inside the booking workspace, so agents and sub-agents don't leave the platform to talk to a customer.

The first point is the one generic tools struggle with. Travel booking support ticketing only pays off when the ticket and the booking meet. Without that, every reply starts with a search.

3. The B2B wrinkle: supporting a sub-agent network

Consumer support has one kind of customer. B2B travel sub-agent support has at least two: the sub-agent who sold the trip, and the traveller they sold it to. That changes three things.

First, who raises the ticket. Often it's the sub-agent, on behalf of a traveller you've never spoken to. The ticket needs to show which agency it came from as well as which booking it's about. If your network is tiered, the same question applies one level up. Our guide to sub-agent tiers, credit and markups covers how those hierarchies are set up.

Second, which queue it lands in. A consolidator may want sub-agent tickets handled by a partner desk and traveller tickets by an operations team. If your network spans markets, language and time zone matter too; see selling travel to sub-agents abroad.

Third, whose brand the customer sees. If your sub-agents sell under a white-label portal, the chat on that portal should carry the right logo and colours, not a third-party helpdesk badge.

4. Generic helpdesk or support inside the travel platform?

There are honest arguments on both sides.

A standalone helpdesk is a mature category. It is usually rich in general features, works for any business and may already be in use elsewhere in your company. The cost is that it sits outside the booking stack. Booking context arrives by copy-and-paste or a custom integration, the customer sees another brand, and support becomes one more system to keep in sync.

Support built into the travel platform starts from the booking. Tickets can carry booking context, chat can sit inside the booking workspace, and there is no separate silo or brand. The trade-off is scope: it is built for travel support, so check it covers the general helpdesk features your team actually uses.

The right answer depends on where your support time goes. If most tickets are about bookings, the booking link matters more than the long tail of helpdesk features.

5. Questions to ask any travel agency customer support software vendor

• Which channels are covered today: email, WhatsApp, live chat? Which ones arrive in the same queue?
• How does a ticket get linked to a booking, and what happens when the message doesn't mention one?
• Can staff see the booking while they reply, or do they switch to another system?
• How are queues and team assignment set up, and who can change the rules?
• Can sub-agents and travellers be told apart on a ticket?
• Can the chat carry your brand, including on a white-label portal?
• Is the full message history kept on the ticket across channels?
• Are replies sent from the platform, so the customer sees one consistent sender?
• Where is the data hosted, and can you choose the region?
• How does a ticket hand over between teams, for example from sales to operations, without losing history?

Ask the vendor to run one of your real tickets through the system during the demo. It shows more than a feature list.

6. How Elkanio Pulse does it

Pulse is Elkanio's multi-channel support and ticketing add-on. It brings live chat from Nucleus, support email and WhatsApp into a single ticket view. Tickets raised by staff and customers are kept with booking context when available. Incoming email threads become tickets, and replies are sent from the same place.

Chat launches directly from Nucleus, so agents and sub-agents can talk to customers without leaving the booking workspace, and you can add your logo and colours to the chat customers see. You choose ticket queues and who handles which channels. Staff sign in to a portal to see assigned and open tickets, read message history and reply to customers.

Pulse is deployed alongside Nucleus, Nova and the rest of the suite. It is not a separate helpdesk brand. If you also handle enquiries before the sale, our guide to enquiry to quote to paid booking covers that side.

Bring one recent ticket, from any channel. We'll show how Pulse would route it and where staff would reply. Request a Pulse demo.