How to Handle Cancellations and Refunds Without Manual Work
A client cancels a tour three days before departure. Now what? In most agencies, the answer involves a chain of manual steps: someone notifies the accountant, the accountant calculates what's owed, an agent writes to the client, the director approves the refund, and eventually someone logs into online banking and makes a transfer. The client waits two to four days — sometimes longer — wondering whether the money is actually coming. By the time it arrives, they've already told two friends how difficult your agency is to deal with.
Cancellations are unavoidable in travel. Flights get cancelled. Visas get denied. Family emergencies happen. What determines whether a cancellation damages your agency's reputation is not the cancellation itself — it's how fast and how cleanly you handle it. This article walks through every component of a modern, automated cancellation and refund workflow: what to define upfront, how to set up the CRM flow, how digital refunds work via Click and Payme, and why every cancellation needs a logged record.
"A cancelled booking is not the end of the relationship. A slow, confusing refund process is."
Why Manual Cancellation Handling Fails
The problem with a manual cancellation process isn't that people are careless — it's that the process depends entirely on people remembering, communicating, and calculating correctly, without any system to catch errors or enforce steps. Here's what routinely goes wrong:
- Calculation errors. Different agents apply different cancellation percentages. There's no single source of truth for the policy.
- Delays from approval chains. The accountant needs the director's sign-off. The director is in a meeting. The client waits and calls again.
- No audit trail. When a client disputes the refund amount a month later, nobody can find the original cancellation record or who approved it.
- Booking status not updated. The seat or room remains marked as occupied in your system, blocking new sales until someone notices and fixes it manually.
- Client left in the dark. No automatic notification means the client doesn't know the cancellation has been received or when to expect the refund.
Each of these failures is predictable and preventable. The solution is not to hire more careful people — it's to replace the manual process with a structured, automated workflow.
Define Your Cancellation Policy Before Anything Else
Automation can only work consistently if there is a clear policy to automate. Before touching your CRM configuration, you need a written cancellation policy that defines exactly what percentage is refunded at each stage. A typical structure for tour agencies in Uzbekistan looks like this:
| Cancellation Timeframe | Refund Amount | Notes |
|---|---|---|
| 30+ days before departure | 100% refund | Minus booking processing fee (if any) |
| 15–29 days before departure | 75% refund | 25% cancellation fee retained |
| 7–14 days before departure | 50% refund | Deposit typically non-refundable |
| 3–6 days before departure | 25% refund | Only portion above non-refundable costs |
| 0–2 days before departure | No refund | Full cancellation fee applies |
This policy should appear in your booking confirmation documents, on your booking confirmation page, and ideally as a checkbox the client acknowledges before payment. When this is in place, the refund calculation becomes a formula — not a judgment call — and your CRM can apply it automatically based on the departure date stored in the booking record.
Automating the Cancellation Flow in Your CRM
Once your policy is defined, the CRM can handle the entire operational sequence without agent intervention at each step. Here is what the automated flow looks like:
Client or agent initiates cancellation
Either the client submits a cancellation request through a form on your booking confirmation page, or an agent marks the booking as "Cancellation Requested" in the CRM. Both paths feed the same workflow.
CRM calculates refund amount automatically
The system reads the departure date from the booking record, calculates the number of days remaining, applies the matching policy tier, and displays the refund amount to the agent for confirmation — no manual arithmetic required.
Booking status changes to "Cancelled"
Upon confirmation, the booking card moves to "Cancelled" status. The seat or room is released immediately in your availability system. The booking history is preserved with a timestamp and the agent who actioned it.
Client receives automatic cancellation notification
A templated message fires immediately via Telegram or email: "Your booking [reference] has been cancelled. A refund of [amount] will be processed to your Click/Payme account within 1–3 business days." The client knows immediately — without calling to ask.
Refund task is created and assigned
A refund task appears in the accountant's queue in the CRM, pre-populated with the booking reference, client name, payment method, original transaction ID, and the calculated refund amount. One click to open the Click or Payme merchant dashboard and process it.
Refund Processing via Click and Payme
If the original payment was made through your Click or Payme merchant account — which it should be, for exactly this reason — the refund is straightforward. You do not need to initiate a bank transfer, obtain the client's card number again, or ask the client for any additional information.
How it works digitally: Both Click and Payme allow merchants to initiate a reversal directly from the merchant dashboard or via API, referencing the original transaction ID. The refund is credited to the same account or card the client used for the original payment. Typically, the funds appear within one to three business days depending on the provider and the client's bank.
Via the merchant dashboard (no API): Log into Click Business or Payme Business, locate the transaction by reference number or date, select "Refund," enter the amount, and confirm. That's it. The entire process takes under two minutes per transaction.
Via API (automated): For agencies processing more than 15–20 cancellations per month, the CRM can call the Click or Payme API directly when the accountant clicks "Process Refund" in the task queue. No browser login required — the refund is initiated programmatically and the transaction status is written back to the booking record automatically.
The critical point: if the original payment was collected as a personal card transfer, none of this is possible. The agency has no formal refund mechanism — only a manual bank transfer with no connection to the original payment, no automatic record, and no protection in a dispute. This is the strongest practical reason to move all payment collection through your merchant accounts.
Handling Partial Refunds: Deposit Kept, Balance Returned
Many agencies collect a non-refundable deposit at booking — typically 20–30% of the tour price — and the remainder closer to departure or upon full payment. When a cancellation occurs after the deposit has been paid but before the balance, you need to return only the balance portion while retaining the deposit.
In practice this means: if a client paid a 30% deposit of 3,000,000 UZS and later paid the 70% balance of 7,000,000 UZS, and then cancels within the 50% refund tier, the calculation is: total paid is 10,000,000 UZS, 50% refund is 5,000,000 UZS, minus the non-refundable deposit of 3,000,000 UZS already retained, so the actual transfer back to the client is 2,000,000 UZS.
Your CRM should store each payment transaction separately — deposit payment, balance payment — linked to the booking. When a cancellation is processed, the system references all linked transactions and calculates the net refund across all payments. Both transactions can be partially reversed via Click or Payme against their respective original transaction IDs. The client receives one clear message showing what was paid, what is being retained, and what will be refunded — with no room for confusion about the arithmetic.
A partial refund calculation done manually by memory is how disputes start. A partial refund calculated by the system from stored transaction records, shown to the client in writing, is how disputes end before they begin.
Logging and Audit Trail: Every Cancellation Must Be Recorded
Every cancellation that goes through your system should generate an immutable log entry. This is not about bureaucracy — it protects your agency in three very real situations:
The minimum fields every cancellation log entry should contain: booking reference, client name, original booking amount, cancellation date, departure date, days-to-departure at cancellation, policy tier applied, refund amount calculated, refund amount approved, payment method, original transaction ID(s), refund transaction ID(s), and the agent who actioned the cancellation. All of this should be generated automatically by the CRM — not assembled by hand in a spreadsheet.
Get Your Cancellation Flow Set Up Correctly
If your agency is still handling cancellations through a chain of Telegram messages and manual bank transfers, you're spending 2–4 hours per cancellation on work that a well-configured CRM handles in under 10 minutes — most of it automatically. More importantly, you're creating disputes, errors, and reputational risk that no amount of careful manual work can fully prevent.
Setting up an automated cancellation and refund workflow requires three things: a clear written policy, a CRM configured to apply it consistently, and Click or Payme merchant accounts so refunds can be processed digitally. If you need help configuring any part of this for your agency, book a free consultation. We've implemented this workflow for agencies across Uzbekistan and can typically have it running within a week.