Connect preparation to a clear next step
Your prospective client has made time for an initial conversation. The intake should help you meet them with some understanding, not make them feel they must tell their entire story before you have spoken. If an answer will not change how you prepare or what happens next, it may belong later.
For your Bristol executive-coaching practice, the useful starting point is a narrow brief: the change the person wants to explore, the type of support they are seeking and the practical next step. Your administrator can help organise that step without needing every detail that belongs in the coaching relationship.
Gbeya has an interactive intake flow with questions, conditions and a booking handover. That provides a foundation. File uploads, durable cross-device resume, client correction journeys and field-specific permissions are not established by this scoped review. Plan the experience around demonstrated behaviour, and build or verify the missing controls before promising them.
Can you explain every answer you request?
Take one planned intake and rehearse it with invented test data, not a prospective client’s details.
- For each question, name the purpose, intended reader and next action.
- Follow every branch, including a route that does not lead to booking.
- Try blank, short, unexpected and long answers; check visible and announced feedback.
- Interrupt the journey and test the exact recovery promise.
- Check the booking handover, access boundaries and the process for correction or deletion.
Publish the intake only when the questions have a purpose and the important failure paths are understood. Reduce the scope or add a clearly owned manual alternative where necessary.
This is a design and acceptance checklist, not legal advice or proof of a secure production workflow.
Four steps, with recovery and access checked separately
1 · Purpose
Name the preparation or routing decision each answer supports.
2 · Question
Explain what to provide, what is optional and what to leave out.
3 · Branch
Follow the relevant next action, without diagnosing the person.
4 · Handover
Explain the booking or closing step and verify the intended access.
Recovery check
Rehearse interruptions; persistence alone does not prove a return journey.
Access check
Verify intended readers, tenant boundaries and correction handling.
This is a planning diagram, not certification of the deployed intake. Recovery and access checks apply across the journey; do not promise unverified uploads or cross-device resume.
1. Give every question a job
Write down what you will do with each answer. “What would you like to work on?” can help you prepare an opening conversation. A detailed account of a workplace dispute may collect information about other people without improving the scheduling decision. Invite a brief description without names or confidential documents.
Separate information needed to arrange the conversation from information you may discuss once the relationship and boundaries are agreed. A shorter form is not automatically better: removing a necessary question can simply move the confusion into an email exchange. Aim for sufficient context with an explainable purpose.
- Why this matters
- A question protocol is a private list connecting each question to its purpose, reader and next action. It lets you challenge a familiar field rather than carrying it forward because the old form had it.
- Work through the example
- Suppose the draft asks for an employer, job title, manager’s name and the intended coaching topic. You may need the topic and a broad role description to prepare, while the manager’s identity has no role in this first step. Record that decision instead of collecting everything just in case.
- When the usual approach changes
- A sponsor-funded engagement may genuinely require separate billing and agreement details. Collect them at the appropriate stage and explain who needs them; do not remove necessary information in pursuit of an arbitrary field count.
- Your decision
- Keep a question when you can name the preparation or routing decision it supports. Defer or remove it when you cannot.
2. Branch on the next action, not on a judgement about the person
A person seeking individual coaching may need a different next step from someone arranging a team programme. Ask the routing question plainly and make each destination understandable. A branch should reflect your service scope, not turn a short written answer into a diagnosis or a claim about someone’s potential.
The inspected flow engine can move through questions and conditions, and it uses a qualification flag for a permitted handover. In this context, qualified means the workflow reached a configured qualifying gate or permitted handover; a redirect can set this flag too. It is not evidence that the person is a qualified sales lead, has paid, or is clinically suitable for support.
- Why this matters
- Conditional routing uses an answer to choose the next question or destination. It saves irrelevant questions only when the condition and both outcomes are tested; a hidden branch can otherwise make the intake harder to understand.
- Work through the example
- Ask whether the enquiry concerns the person’s own development or a team programme. The individual route can request a concise goal before offering the configured booking step. The team route can explain how to discuss scope. Rehearse both routes and the unexpected-answer case without sending real messages.
- When the usual approach changes
- If nearly everyone needs the same two questions, branching may add more complexity than it removes. A straightforward sequence with a clear alternative contact route can be the better design.
- Your decision
- Add a branch only when it changes a real next action. Verify every destination and keep the meaning of an internal qualification flag narrow.
3. Let someone answer without guessing the rules
Use ordinary language and show which answers are required. If a question needs a minimum amount of text, explain what a useful response contains. A character threshold cannot tell you whether an answer is thoughtful; someone may express their situation clearly in fewer words.
The current runner displays one question at a time, with choices or free text. It has required-answer and minimum-length checks. That does not establish accessible labelling, screen-reader announcements or a complete review-and-edit journey. Those need direct keyboard and assistive-technology checks before you call the experience accessible.
- Why this matters
- Visible instructions reduce avoidable guessing. An error should identify what needs attention and how to continue, while preserving useful work. One-question presentation is a layout choice, not a substitute for labelling and feedback.
- Work through the example
- Instead of “Tell us everything”, try “What would you like this first conversation to help you clarify? A brief description is enough; please leave out other people’s names.” If it is required, say so at the question. Test whether someone using a keyboard can answer, find an error and continue.
- When the usual approach changes
- Some people prefer to discuss a sensitive topic aloud or need a different way to provide information. Offer an appropriate contact alternative rather than treating difficulty with the form as lack of commitment.
- Your decision
- Judge the question by whether a person can understand and complete it. Do not treat word count, speed or smooth mouse use as evidence of suitability.
4. Rehearse interruption before promising save and resume
Your client may be answering between meetings. Test a lost connection, a page refresh and returning later. “We saved your answer” and “You can resume on another device” are different promises, and the second needs a reliable way to recognise the right person without exposing someone else’s answers.
The inspected server can resume an active attempt through the intake when given the same identifier, called a subject key. The current browser runner creates a fresh identifier when the page opens; this review did not establish durable storage across reloads or cross-device recovery. Do not advertise automatic save-and-resume on that evidence alone.
- Why this matters
- Recovery depends on both saved state and a safe way to reconnect to it. Server persistence alone does not supply a usable return journey. Retrying an answer also needs to preserve the intended question and prevent unintended repeated actions.
- Work through the example
- In a seeded test, answer the first question, disconnect before the second response returns, then reload. Record whether the original run is recovered and whether earlier text remains available. Separately test a second browser and a different test user. Leave the feature labelled unverified until the outcomes are understood.
- When the usual approach changes
- For a very short intake, a transparent restart may be acceptable if the person knows what happened and can choose another route. A long intake containing sensitive detail needs a more deliberate recovery design.
- Your decision
- Promise only the recovery path that has been demonstrated. Keep cross-device resume, answer revision and upload recovery as explicit build requirements where missing.
5. Make the handover useful and appropriately private
Tell the person what happens after the last question: whether they will see booking options, receive a closing message or be asked to contact your practice. Then check that the coach can find the relevant preparation information without asking for it again. The administrator’s scheduling task does not automatically require access to every coaching detail.
The inspected booking path rechecks an intake gate and can attach the answers to a booking. That is not proof of field-specific access, a retention schedule, a versioned privacy notice or an end-to-end deployment. Decide who should see what, how corrections are handled and how long information is needed, then test the implemented boundaries.
- Why this matters
- A handover joins the form’s outcome to the next service action. Access controls and retention decisions remain separate responsibilities. Passing a form rule does not establish permission to send unrelated marketing.
- Work through the example
- A manager chooses the individual-coaching route and supplies a short goal. The handover should show the correct service and preserve the intended preparation answer. Test that another tenant and an unauthorised role cannot read it, using seeded records rather than real client information.
- When the usual approach changes
- Some enquiries should end with a respectful explanation rather than a booking. A limited service scope is not a judgement on the person. Give a clear next step without claiming an unverified referral or support arrangement.
- Your decision
- Approve the handover only when the person’s next step, the coach’s preparation view and the access boundaries agree. Keep marketing choices separate from intake completion.
A useful intake balances preparation with the person’s effort
Purpose-first service guidance, form usability work and accessibility guidance point towards clear questions and recoverable feedback. They do not prove that every shorter form performs better. The opposing case matters: removing information that you genuinely need can create a confusing follow-up exchange.
A controlled form-design study supports testing a combination of design improvements, but it is older research in a different setting, not a forecast for your Bristol practice. Accessibility stories make different interaction needs visible; they are representative educational scenarios, not interviews with your clients.
For this practice, use a focused intake and an explicit handover, with a contact alternative and deliberate recovery checks. The UK regulator’s data-minimisation guidance supports reviewing necessity; the page is under review following legislative changes. Keep legal implementation decisions separate from this design recommendation and recheck the current guidance when making them.
Medium confidence in the scoped design recommendation; no claimed conversion lift, legal certification or complete runtime validation.
No direct Bristol client interviews or production intake tests. Code observations are separate from external design evidence.
Question review with stated assumptions
Twelve draft questions do not all belong before booking
Suppose your draft has twelve questions. Four support the initial conversation, three belong after an agreement, two are optional preparation notes and three have no defined use. Your review keeps four required questions and two optional questions in the initial journey, moves three to the later stage and removes three. That is a design decision, not evidence of a higher conversion rate.
- Needed now
- 4 required
- Optional preparation
- 2 optional
- Needed later
- 3 deferred
- No defined purpose
- 3 removed
12 draft questions = 4 needed now + 3 deferred + 2 optional + 3 removed. The initial journey contains 6 questions, of which 4 are required.
Illustrative design choices, not measured completion or conversion results.
If a necessary safety or service-scope question emerges, add it with a clear purpose. The target is an adequate intake, not the smallest possible number.
Reconcile each question to its job. Measure actual difficulties later rather than predicting results from the shorter count.
Three assumptions worth checking
A longer answer proves that a prospective client is serious.
Length checks only establish a configured amount of text. Relevance and readiness need a more careful conversation.
The server saved a run, so clients can resume on another device.
Recovery also needs a safe, usable way to reconnect to that run. The inspected browser creates a fresh key on mount.
An experienced coach can reuse the full first-session questionnaire as an enquiry form.
Those stages serve different purposes. Review the timing and audience for each question rather than copying the whole document.
Your next 30 days
Days 1–7
Define the preparation task
Choose one coaching service and write a question protocol, including intended readers and an alternative contact route.
Ready for the next step: Every question has a purpose and a stage.
Days 8–14
Build the smallest useful journey
Configure the demonstrated questions and routing; clearly mark missing uploads, correction or recovery controls as acceptance work.
Ready for the next step: The normal route and each alternative have understandable outcomes.
Days 15–21
Test interruption and access
Use seeded local or staging records to check validation, retries, refresh, role boundaries and tenant separation without real bookings or messages.
Ready for the next step: Expected and actual results are recorded, with an owner for each unresolved control.
Days 22–30
Review the complete handover
Have a colleague follow the intake and the preparation view. Check keyboard access, notice wording and the support process before a bounded release.
Ready for the next step: The published promise matches observed behaviour; thirty days is a review window, not a forced launch deadline.
Questions before publishing your intake
Does Gbeya support conditional intake questions?
The inspected engine includes questions, conditions and routing. Verify your configured branches and destinations in a safe environment before release.
Can clients upload documents?
File upload and file-type controls were not established in this intake review. Keep them in the implementation scope if your service needs them.
Can someone save and resume later?
The server can reconnect to an active intake attempt using the same identifier, but durable browser and cross-device recovery were not demonstrated. Do not promise those journeys until verified.
Does passing the intake prove someone is a qualified buyer?
It means a configured qualifying gate or handover was reached. It does not establish a sale, suitability or a paid booking.
Will intake answers reach the booking?
The inspected booking code can recheck the intake gate and attach answers. The complete deployed journey, role access and failure handling still need testing.
Should I ask for sensitive background information?
Ask only what is appropriate and necessary for the defined stage, explain its purpose and establish the relevant safeguards. This guide does not determine a legal basis or certify a sensitive-data workflow.
Prepared by Gbeya · Sources reviewed 30 October 2026. Code observations are separate from deployed recovery, permissions and booking-handover verification. No client submissions or bookings were created for this guide.