How it works · Penciled.software
A pencil mark needs a clear way to become ink, or disappear.
The planned lifecycle gives a provisional appointment a beginning, a visible limit and two understandable endings. Read this as a design walkthrough. No hold, expiry or confirmation is running on this website, and none of the fictional times below is a bookable appointment.
First, distinguish interest from a hold
Imagine a practitioner offering a Tuesday afternoon slot. A client likes the time but needs to check one commitment before agreeing. An ordinary note saying interested does not tell the practitioner whether to keep offering that slot. Penciled's design proposes a third state: provisionally held. The intended input is a chosen fixed slot and a clear expiry; the intended output is a visible provisional reservation, rather than a confirmed appointment in disguise.
The word held carries a responsibility. If the design counts a hold against capacity, it must stop being offered as though nobody had expressed a claim. A colored label alone would not do that work. This is precisely the unbuilt part of the product: the provisional state must exist where the booking decision is made. The current website can explain that requirement, but it does not implement it or test concurrent requests.
Make the expiry part of the agreement
A holder should not need to discover a hidden clock after making a decision. The planned expiry belongs beside the provisional time, visible before anyone relies on it. In a walkthrough, say what is being held, until when and what happens if no action is taken. Avoid phrases such as for a little while. They invite two people to read the same pencil mark as two different commitments, which is the ambiguity the product is meant to reduce.
Use a fictional example with a named timezone and an explicit deadline when discussing the design. Then ask how the late-return message should read. This does not establish that timezone handling or an expiry worker has been built for Penciled. It gives the future workflow a concrete expectation to meet. The difference matters: a static countdown caption is easy to draw, while releasing capacity correctly is a product behavior that still needs implementation.
Confirmation should settle the existing decision
The proposed confirm action turns the provisional reservation into a booking before it expires. Its purpose is to finish the decision already in progress, without asking the holder to enter the same information again. It should be clear which time is being confirmed. A confirmation message must not be used to imply that payment, service preparation or an unrelated agreement has also occurred. Those are separate requirements to discuss, not consequences invented by this page.
Walk through the successful ending in plain language: the person has checked the missing commitment, returns while the proposed hold is still valid and chooses to confirm that time. The intended output is a settled appointment. Today this remains the one-tap-confirm design in the capability list, labelled planned. There is no confirmation endpoint behind the illustration and no live checkout. A visit to this page does not change an appointment's state.
No answer should have an explicit ending too
The other proposed exit is automatic release. If the holder does not confirm before the expiry, the time returns to open capacity without a practitioner hunting down a stale note. The important outcome is clarity for both sides: the holder no longer has a provisional claim and the practitioner can offer the slot again. This is a design requirement, not evidence that a background process is currently releasing holds on this domain.
A returning holder may still need help. The planned reschedule idea is to offer a short list of nearby open slots for a person to review. An alternative should remain a proposal, rather than a silent move to a time the person never agreed to. If your work requires a different late-return policy, bring it to the conversation. The value of discussing the awkward ending now is that it exposes the expectation before anyone depends on the feature.
The pencil has not become a working reservation yet
The distinction runs through the whole site. The fixed-slot capacity floor has existing sibling-source grounding. The hold state is a separate design: it would count provisionally, carry an expiry and resolve into confirmation or release. None of those hold actions is running on Penciled.software. A route that displays this explanation does not supply the missing state transition. The small board on the home page is a static illustration, and no timer runs inside it.
That is why the next action is a conversation rather than a booking button. No date shown in an example is being offered to you, and no click can confirm a slot. Smart reschedule is also planned: applying a ranked proposal pattern to a lapsed hold has not been wired here. The useful question is whether the proposed behavior fits your work, followed by what evidence you would need to see before relying on it.