Day 171: Cancelling a Booking Does Not Rewind the Business

The appointment is cancelled. The preparation has already been done. The confirmation has already been read.

An Undo button cannot make all three disappear.

For founders and marketing leaders commissioning agent-assisted booking, recovery belongs in the commercial budget. A successful booking creates commitments; reversing it can require new work, leave costs behind and finish somewhere other than the original starting point.

This is not the retry problem. Retrying asks the service to complete the same intended action without duplicating it. Cancellation asks for a different outcome after that action succeeded.

Begin after the booking succeeded

Consider a fictional site-assessment service. An authorised agent has booked a visit, the service has collected payment and a confirmation has reached the customer. The customer subsequently authorises cancellation.

For this illustration, stipulate that preparation has already incurred a charge. The service's agreed cancellation terms allow the visit to be cancelled and the remaining payment returned, but retain that preparation charge. These are invented scenario conditions, not a statement about any provider's policy or anyone's legal rights. No booking, payment or agent was tested.

The business must now reach a new, acceptable position. Merely deleting the appointment would leave the payment and customer communication unresolved.

Microsoft's compensating-transaction guidance describes actions that undo the effects of completed work using application-specific rules. It explicitly includes a customer requesting cancellation of a completed operation, and warns that compensation need not restore the original state.[1]

That distinction is the design problem here: resolve the commitment without pretending it never happened.

Draw the recovery states

This diagram shows one stipulated route, not a required technical sequence:

BOOKED
Visit reserved; payment collected; confirmation delivered
    |
    | Customer authorises cancellation on the stated terms
    v
CANCELLATION IN PROGRESS
Release visit; return refundable payment; send cancellation notice
    |
    +-- All required actions confirmed --> SETTLED
    |   No visit due; refund completed; preparation charge retained;
    |   cancellation notice delivered; original history remains
    |
    +-- An action unresolved -----------> PARTIALLY RECOVERED
        Completed actions stand; outstanding work needs resolution

“Settled” does not mean “as if nothing happened”. Preparation consumed resources. The original message existed. The payment now has a refund associated with it rather than no history at all.

Suppose the visit is released but the refund remains unresolved. In this example, the business should report those states separately: the customer no longer has an appointment, but the financial recovery is incomplete. It should not describe the whole request as finished or recreate the visit merely to make the records look symmetrical.

Microsoft notes that compensation can itself fail and may require manual intervention.[1] A recovery route therefore needs a way to retain completed progress and put outstanding work in someone's hands.

Separate three meanings of undo

Technical rollback reverses changes within a supported transaction boundary. It is not a general power to erase effects already committed across independent services or experienced by people.

Cancellation is the business decision to end the future commitment under applicable terms. It determines what should stop and what remains owed.

Compensating actions carry out the necessary adjustments: releasing the visit, issuing the permitted refund and sending a corrective notification. They act on the world as it is now, not on an untouched copy of the past.[1]

A saga is one architecture for coordinating distributed transactions. AWS documents both compensating steps and the extra complexity they introduce.[2] That does not make a custom orchestration stack necessary for every booking. An existing platform's native cancellation route may be sufficient if it supports the actual business rules and required outcomes.

Buy the recovery, not just the booking

For the founder commissioning this fictional route, the acceptance discussion should include the cost of preparation that cannot be recovered, who funds refunds, who resolves incomplete cancellations and what the customer hears while those actions remain open.

Do not bury those choices inside the label “Undo”. Ask the supplier to demonstrate the stipulated partial-recovery state as well as the fully settled one before accepting the implementation.

The GEO boundary is equally important. Helping someone discover and understand an offer is different from obtaining permission to book it; neither establishes permission or a supported method to cancel it. This is an agentic commercial-workflow design lesson, not a claim that answer engines universally transact or reward cancellation features with better visibility.

The commissioning choice is concrete: fund the route out of the commitment alongside the route into it. A cancelled appointment can be a successful recovery even when the business cannot return to where it started.

Sources

[1] Microsoft Azure Architecture Center, “Compensating Transaction pattern”: https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction

[2] AWS Prescriptive Guidance, “Saga orchestration pattern”: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html