What the confirmation button has actually reserved

## The calendar was correct and the promise was incomplete

We rehearsed sixty appointments that required a practitioner and an additional room or support resource. Nine looked available in the product without all the necessary resources being reserved. The calendar was not producing a random error. It represented the practitioner, which was the object we had originally asked it to represent. The product's confirmation then implied something larger:that the appointment could proceed within the provider's agreed administrative arrangements. The gap was between the model and the promise made through it.

That distinction matters because a technically correct component can participate in a misleading service. It is tempting to explain the incident as a missing check and move directly to implementation. A check may be part of the answer, but it does not settle the product question. We first needed to identify which resources belonged inside the commitment, who defined their constraints and what the user should be told when one condition remained unresolved. Otherwise the new check could simply move the ambiguity to another screen.

My earlier preference had been for a simpler release. The practitioner-first path required fewer decisions and was easier to demonstrate. I had treated the remaining coordination as familiar work that clinic staff already performed. That assumption made the product look more complete than it was. Staff knowledge was carrying a responsibility the interface did not acknowledge. A product leader should be willing to describe that transfer of work, including when it is a deliberate and acceptable choice, rather than allow it to disappear inside the word 'simple'.

The provider still decides what a service requires. Our scheduling software does not determine clinical suitability or priority. The product can represent the agreed administrative resource rules and make their status visible, but it cannot acquire professional judgement by combining calendars. We needed that boundary to remain clear as the reservation model became more capable. More functionality can make an interface appear more authoritative, which is precisely why the explanation of its limits should become more careful as the product develops.

## Paying for the less convenient product decision

Engineering proposed retaining the planned design and producing an exception list for clinic staff. It was a reasonable alternative, not evidence that engineers did not care about the problem. The approach protected the release date and used an operating process that customers understood. Its weakness was that the user would still see a confirmation before the exception had been resolved. Research and clinic operations argued that this was the wrong point at which to transfer uncertainty to the customer. I accepted their argument.

We approved ₹74 lakh for combined resource reservation work and displaced a reporting enhancement. The delay was part of the decision, not an incidental inconvenience to omit from the case. Product investment is scarce, and the reporting enhancement had legitimate users too. The choice required us to explain why the meaning of confirmation deserved priority over additional reporting capability in that release. I do not want a decision account in which the chosen option receives all the benefits and the alternative is deprived of its reasonable case.

The revised model had to deal with change as well as initial selection. If one resource becomes unavailable, the product needs a coherent account of the existing reservation and the next action. A successful initial booking is only one moment in the appointment's life. The person making the change, the receiving clinic team and the person attending should not each see an incompatible version of the commitment. That does not require every participant to receive every internal detail; it requires the states relevant to their responsibilities to agree.

The repeat rehearsal covered the same sixty scenarios and did not reproduce the nine known clashes. We recorded that result precisely. It did not demonstrate that every configuration at all 186 clinic organisations would behave correctly, or that a clinical outcome had improved. Provider setup and further exception review remained necessary. A product team can be proud of removing a known failure without turning a bounded exercise into a universal claim. The narrower statement is more useful because it tells colleagues what evidence they can rely on and what still requires examination.

I also wanted the support account to change. If the design makes a commitment that depends on several resources, support staff need to understand which condition prevented confirmation and who can resolve it. A message that merely says the booking failed leaves the operating problem unexplained. At the same time, the interface should not expose unnecessary internal complexity to the person arranging an appointment. The work is to make the relevant condition understandable, with a route to resolution, without turning every user into an administrator of the resource model.

## Questions that belong above the backlog

A board should not choose the arrangement of booking controls or approve individual calendar rules. It can ask whether management understands the obligations inside the product promise. That question reaches investment, support capacity and the way success is reported. If a transaction is counted as complete before a necessary resource has been secured, the performance measure may reward an unfinished commitment. Directors can ask management to explain that definition and the consequences of changing it without taking over the product team's design responsibility.

The useful discussion includes the cost of alternatives. A manual coordination process may be appropriate in a small or unusual setting, provided the promise and responsibility are explicit. Automation is not automatically the superior answer. What concerns me is an operating model that depends on manual work while the product narrative implies that the work has disappeared. That mismatch can create unrealistic expectations for customers and unrealistic investment claims inside the company. A clear account allows management to decide where automation is worth its continuing cost.

The evidence should also follow the task beyond the initial success screen. Can staff revise the arrangement coherently? Is the person making the appointment told which commitment remains valid? Does support know the unresolved condition? These questions are related, but they should not be collapsed into one attractive completion percentage. Each concerns a different point at which the product can transfer responsibility. Observing those points can reveal why a flow that performs well in a demonstration still creates difficult work during ordinary service delivery.

I would bring this experience to a board as a way of questioning the product account, not as a universal prescription for scheduling. Different services have different constraints and acceptable forms of coordination. The transferable discipline is to identify the promise, make its dependencies explicit and examine the evidence that they have been satisfied. Management should then choose the design and operating process that fit the business. A director's contribution is to help ensure that the investment case and the customer's understanding refer to the same commitment.

The rehearsal changed my view of a good confirmation button. Its quality is not measured only by how readily somebody can press it. The button stands at the end of a set of decisions about resources, responsibility and unresolved conditions. When those decisions are sound, the interaction can be simple without being misleading. When they are not, a polished screen can conceal work that somebody else will have to discover later. I now ask what has actually been reserved before asking how quickly the product can display the word 'confirmed'.