Rebooked Orders: Support Visibility

The problem

When an order gets rebooked, the original booking is cancelled and a new one is created with better margins. From the customer's side nothing visibly changes. They keep the confirmation email from the booking they originally made.

So when they call with a question, they read out the old confirmation number. And support had nothing.

Our system showed the original booking. It didn't show what replaced it: which provider now held the reservation, the new confirmation number, the new rate, or the cancellation policy that now applied. To answer a basic question, an agent had to leave our platform, log into the provider's own system, and manually search for the booking while the customer waited.

That happened on every call about a rebooked order.

What I did

I started with the people taking the calls rather than with the ticket describing the problem. What surfaced in those conversations was that the pain wasn't really the missing data. It was the lookup. Agents knew the information existed somewhere; the cost was the detour to go find it, repeated on every call, while someone was on the line.

That reframed the requirement. This wasn't a reporting feature. It was a visibility feature, and the measure of success was whether an agent ever had to open a provider platform during a call.

Instead of writing a spec next, I built a working prototype within days and put it in front of the ops leaders. Reacting to a screen moved the conversation faster than another round of requirements discussion, and it surfaced things nobody had raised in the interviews, including that agents needed the cancellation and booking logs rather than just the current state. When something was disputed, the logs were the answer.

We iterated until the screen was settled. Then I wrote the specification engineering built from: scope, what was deliberately out of scope, the edge cases the prototype never exercised, and the questions still open rather than pretending they were resolved.

Engineering built it. I validated it in QA. It's live, and I maintain it.

Decisions worth explaining

Search had to resolve superseded confirmation numbers. The customer is reading from an email that points at a cancelled booking. If searching that number returns nothing, or returns a cancelled record with no onward link, the agent is back on the provider's site and the feature has failed at the one moment it exists for. Old confirmations resolve to the order and show what replaced them.

Show the chain, not just the current state. The screen presents both bookings and what changed between them: provider, rate, and policy. An agent explaining a rebooking to a confused customer needs the before and the after, not a single current record with no history.

A better rate can mean a worse policy. Rebooking optimizes for margin, and the replacement booking sometimes carries stricter cancellation terms than the original. That's the case where an agent most needs the screen, so the policy difference is called out rather than buried in a comparison table.

Include the logs. Cancellation requests, provider references, confirmation timestamps, who or what triggered the rebooking. This came out of the prototype review, not the interviews. It's what gets used when a customer disputes what happened.

Separate internal figures from customer-facing ones. Margin is why rebooking happens and it belongs on the screen for ops, but an agent on a call should never be reading from it. It's marked internal.

Outcome

Agents answer questions about rebooked orders from one screen. The provider platform lookup is gone from the call path, which is where the time was going.

I own it through QA and maintenance, so the handoff didn't end my involvement.