“Waiting on Supplier” Isn’t an Update

“Waiting on Supplier” Isn’t an Update

In travel ops, supplier dependency is normal. Airlines, hotels, bedbanks, and local partners create timelines you do not control.

What is not normal is treating “waiting” as a customer communication strategy.

When teams scale past 15 agents, “waiting on supplier” becomes a default message that feels safe internally but creates two external outcomes: reopens and escalations. It also inflates your queue, because every “no-news” message generates more follow-up demand.

Why “waiting” breaks service quality

Customers do not reopen because they love chatting. They reopen because they are missing one of three things:

  • Ownership: who is responsible for moving this forward.
  • Progress: what has actually been done since the last message.
  • Timing: when they will get the next update, even if the answer is still “pending.”

“We’re waiting on the supplier” provides none of those. It shifts uncertainty to the customer, so they try to reduce it by pinging your team. That is how your inbox becomes a follow-up factory.

The operational cost of vague updates

Vague updates feel fast. They are expensive.

  • Reopens multiply: “Any news?” messages pile up, especially on WhatsApp.
  • Touches per case climb: multiple agents spend time reading and re-reading history.
  • Queue inflation: your team creates additional inbound volume through ambiguity.
  • SLA distortion: first response stays green while resolution and customer confidence deteriorate.
  • Escalation risk increases: customers interpret silence as neglect, not dependency.

If you are measuring only speed, you will miss this. If you track reopens and time-to-resolution, it becomes obvious.

Where it shows up (travel-specific)

Supplier dependency is real, but the “waiting” message is overused in predictable scenarios:

  • Refunds: “pending with airline” without explaining timeline boundaries and next check-in.
  • Hotel amendments: “awaiting confirmation” without stating what you requested and when you will chase.
  • Rebooking during disruptions: “checking options” without clarifying constraints (fare rules, seats, payment approval).
  • Name corrections: “submitted” without confirming fees, documentation, and confirmation window.

The pattern is the same: the customer is left managing uncertainty.

What to send instead: the 4-part update

You do not need longer messages. You need structured messages.

Every supplier-dependent update should include four fields:

  • What we did: “We submitted the refund request to Airline X with ticket numbers Y.”
  • What we are waiting for: “We need airline approval before the processor can release funds.”
  • When you will hear from us next: “Next update by tomorrow 14:00 UTC, even if still pending.”
  • What we need from you (if anything): “Nothing else needed right now” or a single consolidated ask.

This reduces reopens because it replaces uncertainty with cadence.

A simple rule that prevents reopen inflation

If a case is blocked on a supplier, you need an update cadence SLA, not just a response-time SLA.

For example:

  • Acknowledge quickly (set expectations).
  • Update on a fixed cadence while blocked (so the customer does not have to ask).
  • Resolve when the dependency clears (execute and document).

This is how you stay responsive without letting your queue get hijacked by follow-ups.

How to audit your operation in 30 minutes

Pull 20 recent cases with supplier dependency and answer:

  • Did we state a clear next update time in writing?
  • Did we explain what action was taken (not just “waiting”)?
  • Did the customer reopen before our next planned touch?

If most reopens happen before your next proactive update, you do not have a supplier problem. You have a cadence problem.

Close: dependency is normal. vagueness is optional.

You cannot control supplier timelines. But you can control how uncertainty is managed.

When you replace “waiting on supplier” with time-bound ownership and cadence, service quality improves and workload drops. Not because you moved faster, but because you stopped creating extra inbound demand.