Contact · Penciled.software
Tell us what you would pencil in, and what you need to check first.
Email [email protected]. There is no form on this page and no reservation is created when you follow the link. It opens your email application; you decide whether to send a message. The hold lifecycle remains planned, so contacting us begins a discussion rather than unlocking a working booking account.
A useful message has one appointment and one hesitation
Describe the kind of appointment, the decision that keeps it provisional and roughly how long that decision takes. A practitioner waiting for a client's travel check is a more useful starting point than a request for flexible scheduling. It tells us whose decision is outstanding and what an expiry would mean. Use a fictional date and neutral labels. There is no need to forward an actual client conversation or explain sensitive personal circumstances.
Say what your current process does while you wait. Does a note reserve the time in practice, or can someone else still book it? Does another team member know the note exists? What happens if the person never replies? These details reveal whether the planned third state would solve the problem or merely rename it. They also let us discuss a refusal or release with the same care as a successful confirmation.
Describe the pause between interest and commitment
Begin with an appointment you cannot sensibly confirm immediately. Perhaps a client needs to check travel, a colleague needs to agree to join, or a practitioner needs an answer before choosing between two possible windows. Describe the decision without naming the client or forwarding their messages. The useful input is the reason a short, explicit pause would help. A hold is not automatically better than an ordinary booking; it should solve a specific hesitation.
Say how long the decision normally takes and what happens when nobody answers. An afternoon and a week create different expectations for the person holding the slot and the person offering it. Do not start by choosing a countdown because it looks tidy on a page. Start with the work someone must finish before they can honestly say yes. The proposed expiry should be understandable to both sides, rather than a surprise hidden behind a button.
Walk through both exits on paper first
Take a fictional slot and write down three states: open, provisionally held and confirmed. Add the expiry you would want a holder to see. Then write two endings. In one, the holder confirms before that point; in the other, they do nothing and the planned hold releases. This small exercise reveals whether your team is using held to mean a genuine reservation, a preference or merely a note. Those meanings should not be mixed.
Try one awkward ending as well: the person returns after the proposed expiry. What would you want the message to say if the time is no longer open? What nearby alternatives would still be useful? Penciled's replacement-suggestion idea is planned, not wired. Treat this as a design conversation about the desired response, not a test of a running system. A drawing of an expired hold cannot prove that capacity was released or another booking was protected.
Leave with a question answered, not an imaginary account
A useful first conversation should establish whether the proposed third state fits your work, which part of the lifecycle matters most and what you would need to see before trying it. Ask specifically about hold creation, expiry, confirmation and the late-return case. The fixed-slot floor described elsewhere on this site does not by itself answer those questions. The hold lifecycle is not built, so there is no Penciled account or live reservation to hand over at the end of this page.
Keep your current booking process authoritative while the product is being developed. Do not tell a client that an illustration on this website has reserved their time. Joining the waitlist is an email conversation; it does not store payment details or commit you to a tier. The planned Personal, Pro and Team packaging helps explain the direction of the product, but a price label is neither a working feature nor a promise that a particular release will arrive by your deadline.
Ask what the proposed hold means in your particular case.
Use a separate fictional adult example: Nell offers finish-sample consultations at a small furniture studio. A visitor can attend Thursday 22 October 2026 at 15:00 but needs a colleague to choose which sample set to discuss. Nell's inquiry is not about automatically finding a time. It is about whether that outstanding choice is a sensible reason to reserve a particular consultation provisionally.
The rough message says, “We need tentative appointments.” A more answerable version says, “The time works, but one preparation decision remains. We want to understand whether your proposed hold reserves capacity during that decision, and which part of that behavior can actually be demonstrated.” This gives the recipient a concrete distinction to address without sending an actual client's messages or contact details.
The expected reply has two parts: an explanation of the proposed meaning and an honest account of its implementation status. A design answer may be useful while the hold mechanism remains unbuilt. Nell should not summarize a clear explanation as proof that a working provisional reservation is available. Understanding a mechanism and operating it are different outcomes.
If the preparation decision does not affect whether the visitor will attend, the inquiry may reveal that an ordinary confirmed appointment is the better description of the human arrangement. That is a useful answer too. Contact should not begin by assuming that the product's central idea must be appropriate for every hesitation a business encounters.
Name the late-return question instead of asking for flexibility.
Another invented inquiry concerns a proposed hold that ends at noon on Wednesday 21 October, ahead of the Thursday consultation. The visitor returns at 12:20 on Wednesday and wants to accept. The question is not simply whether the product is flexible. It is what the visitor should be told when the earlier provisional claim no longer establishes a reservation for that time in the proposed design.
A useful message preserves the order of events: intended appointment, proposed cutoff, late return. It asks whether the described workflow distinguishes an expired claim from a still-valid invitation to confirm. It should also ask which parts are only design explanations. There is no running Penciled timer or release worker behind the dates in this example.
The reply might clarify the intended late-return message while leaving alternative suggestions unavailable. Keep that distinction in the notes. A helpful explanation of expiry does not establish automatic rescheduling, access to an external calendar or a ranked list of new appointments. The current site names those application ideas as planned rather than treating them as consequences of one status label.
The reasonable objection is that users want an easy next step, not a detailed account of states. An easy next step still needs a truthful starting point. A message that implies the old claim remains valid would obscure the very question being discussed. The inquiry can ask for understandable wording without pretending the unavailable behavior has already been implemented.
Put an indispensable requirement near the beginning.
Suppose Nell's fictional studio also needs another booking system to reflect any change immediately. That is an additional requirement. It is not established by the idea of a provisional state or by the existence of a product webpage. The message should state the dependency plainly instead of assuming that every familiar calendar connection accompanies the proposed hold.
A precise inquiry asks, “Our evaluation depends on a working connection to our existing scheduling process. Is that part of the current surface, or is the conversation limited to the proposed lifecycle?” No provider credentials, live calendar feed or actual booking export is needed to ask that scope question. This page offers no connection flow and does not authorize a transfer of those materials.
The correct reply may leave the requirement unmet. A reader should retain that result even if the rest of the explanation fits the studio's needs. Planned branding, displayed tiers or an early-access label cannot supply the missing dependency. Nor does a contact message create an implementation commitment or a date by which a feature must operate.
This is where the distinction between enquiry and onboarding matters. The page is a way to start a discussion. It is not a practitioner account, an accepted project or a service activation. An inquiry that ends with “the required connection is unavailable” can still save the reader from making an unsupported operational assumption.
Pass on the answer without enlarging what it says.
After a product conversation, Nell prepares a note for adult colleague Dev. The first draft says, “Penciled can manage our tentative appointments.” That sentence combines the design explanation, the unbuilt mechanism and the unresolved external dependency into one affirmative claim. It is broader than the fictional discussion has established.
A faithful revision says, “We discussed what a provisional claim and its expiry would mean. The current pages do not provide a working hold. Our required connection remains unresolved, so no appointment should be treated as reserved through this evaluation.” The revised note is useful because it preserves both the answer and its practical consequence for the studio's existing process.
If Dev has a further question, keep it specific: which operation is missing, what result the team needs and whether the previous answer addressed it. Do not forward a real customer's history to make the discussion seem more concrete. An invented case can carry the same decision structure without turning a marketing enquiry into operational case handling.
The mail link itself establishes none of this conversation. It can open the reader's own email application; sending and receiving remain separate events in that channel. The page does not prove delivery, promise a reply or save the draft as a booking. The useful output is an accurately scoped human exchange, with any unanswered requirement still visible to the next reader.
Ask about the missing piece before making plans around it
If a working expiry, a particular calendar connection or a team permission model is essential, say so at the beginning. The correct answer may be that the necessary behavior is not built. A conversation is useful when it makes that boundary clearer. It should not leave you planning a client-facing rollout based on an illustration. No purchase, account or delivery date is created by joining the waitlist, and planned pricing is not a charge authorization.
For privacy or procurement questions, name the review you need rather than sending the records you hope to place in a future service. This page does not establish negotiated hosting, retention, deletion or support terms. If your question concerns a particular sentence on the site, include its path and the claim you want clarified. The feature ledger and privacy guide are useful companions because both distinguish the current marketing surface from the product being designed.