The appointment-booking prototype looks ready. A customer chooses a location, selects a time and receives a confirmation. In the demonstration, the whole journey is clear.

Then the team connects the service to live scheduling. The last available appointment can disappear while a customer is entering details. A connection can time out after the booking has been accepted. A confirmation can fail to arrive.

Each event leaves the same uncomfortable question: does the customer have an appointment?

These are product decisions as well as technical ones. Resolving them is part of moving from a convincing demonstration to a service people can use.

Decide what the customer sees when certainty disappears

A timeout does not always mean the booking failed. Asking the customer to start again could create a duplicate. Declaring success could send someone to an appointment that does not exist.

The service needs a way to check the underlying record and explain the current state. If confirmation is pending, the message should say what will happen next and how the customer can obtain help.

Support teams need that same view. A customer should not reach an agent who knows less about the failed attempt than the customer does.

Test these cases during the pilot. The resulting decisions can change the interface, the connection to scheduling and the work assigned to support.

Launch a smaller promise that can be kept

A broad prototype may cover every location and appointment type. The first live release can be narrower.

A limited service with clear eligibility, reliable booking checks and a working support path can produce more useful learning than a broad launch filled with exceptions nobody owns. The tradeoff is reach: some customers will need to keep using the existing route until the next release.

Make that boundary explicit. Do not let the pilot attract requests it cannot complete, then rely on agents to rescue them through undocumented workarounds.

The launch decision should include operational readiness. Someone must maintain appointment rules, investigate failures and decide when the service should temporarily stop accepting new bookings.

Learn from attempts that do not finish

After launch, count completed bookings against genuine booking attempts and examine where progress stops. Separate a deliberate exit from a technical failure where evidence allows. Check whether customers try again or contact support.

The UK Government Service Manual makes a useful distinction: a digital transaction requires a defined start and completion point, and incomplete attempts remain part of the calculation. Measuring completion rate

A booking service also needs to check the appointment record itself. A successful page load is not enough.

Use those findings to choose the next release. An unclear confirmation may matter more than another interface feature.

The prototype proves that a journey can make sense. Everyday operation requires the team to keep that promise when the normal path breaks.