"We need a website, email and a community" is a starting conversation. It is not yet a build scope. Before a proposal becomes a project, turn that conversation into a short description of the journey, the work included and the evidence that will show it is ready.
You do not need to decide every future feature. You do need enough clarity to know what you are buying, what you must supply, and how you will review the first working release.
What should come out of a discovery call?
A useful discovery call should lead to a shared problem statement, a first customer journey, clear deliverables and exclusions, responsibilities, timing and acceptance checks. Questions that remain open should be visible before either side commits to an unclear promise.
Atlassian's requirements guidance separates requirements, assumptions, constraints and acceptance criteria. That distinction is useful here: "We need a booking route" is a requirement; "the calendar supports this connection" is an assumption until checked. The scope card below is Pro Mind Hub's practical adaptation for a small service project.
1. Write the problem as a broken journey
Describe what happens today and where work gets stuck. "People ask about our service, but their messages live in different inboxes and no one owns the next reply" gives a builder something concrete to investigate.
Compare that with "we need better automation." The second statement names a possible solution before the team has agreed on the problem. A useful first release may need a clearer handoff, a better form or a simple review routine before it needs more automation.
Pick one reader or customer type for this scope. A new prospect, a paying member and a returning client may need different journeys. Putting them all into the first release makes the agreement harder to test.
2. Define the first complete route
Choose a starting point and a useful finish. For a consultation business, the first route might be: service page, fit-call booking, confirmation and a visible next step for the owner.
Write down what the finish means. Opening a booking page is different from a confirmed appointment. A submitted form is different from a lead record with an owner. A successful payment is different from delivered access.
Aim for a small route that can work on its own. A later course library should not stop a useful consultation route from launching, provided that route meets its own acceptance checks.
3. Separate deliverables from promises
A deliverable is something you can inspect: a service page, one booking connection, a confirmation message, or a documented handoff. A commercial outcome, such as a particular number of sales, also depends on demand, traffic, the offer and follow-through.
For each deliverable, state its boundary. "Email setup" leaves too much room for assumptions. "One confirmation email for a booked consultation, with the agreed content and sender configuration" is easier to review. Whether delivery to a real inbox is included must also be explicit.
List exclusions beside the work included. Examples might be a full CRM migration, a new paid membership, historical data cleanup or ongoing campaign management. These are possible scope choices, not standard exclusions for every project.
4. Make responsibilities and dates visible
Record who supplies copy, brand assets, access, domain information and feedback. Give each needed item an owner and an agreed due date. State what happens if it arrives late, rather than leaving the deadline to be interpreted after payment.
Ask exactly when the delivery clock starts. It may be the payment date or another event stated in the proposal. Read that rule together with the preparation requirements. Do not assume that missing materials automatically pause a deadline.
Keep access requests limited to the work. Agree on how credentials or permissions will be handled through the platform's supported process; do not place passwords in the scope document.
5. Decide what "ready" looks like
Write checks that someone can perform. For example:
- A mobile visitor can read the service, understand the next step and reach the intended booking page.
- A controlled booking test reaches the expected confirmation, without charging anyone.
- The owner can identify who handles the appointment and what happens next.
- The agreed source labels appear where the chosen booking system supports them; unknown attribution remains marked unknown.
- The agreed privacy choices, contact details and recovery instructions are available.
Decide who reviews each result and how unresolved issues are recorded. A screenshot may prove the page appeared. It cannot, by itself, prove a saved appointment, delivered email or confirmed sale.
Your practical exercise: fill one scope card
Use these eight lines after your next planning conversation:
- Problem: what is happening today?
- User: who needs to complete the first journey?
- Route: where does it start and finish?
- Included: what can both sides inspect?
- Deferred: what belongs in a later release?
- Responsibilities: who supplies, reviews and decides?
- Timing and cost: what starts the clock, what is due, and what recurs?
- Acceptance: which checks show the agreed work is ready?
Fictional example: an independent consultant wants inquiries to reach a booked fit call. Release one covers the service page and booking route. A paid resource library is deferred. The consultant supplies approved service copy; the builder connects the agreed booking system. Both review the mobile route and a controlled booking before release. Prices and dates still require a written proposal.
Keep good ideas without silently expanding the project
Save new requests in a short change list. For each request, ask whether it replaces work, adds time or budget, or belongs in the next release. Atlassian's scope-creep guidance explains why a shared baseline and change review matter. A sensible new idea still needs an explicit decision.
If you are considering a connected website, booking and customer journey, explore Pro Mind Hub's Hub packages. The package buttons lead to a fit-call booking so needs and scope can be discussed. Bring your scope card, including what you have decided to defer. It will make that conversation more useful.
