A useful discovery engagement should leave you able to decide what to change, why it matters and how the result will be tested. You should understand the current customer path, the bottleneck being addressed and the responsibilities that remain with your team. A presentation without those decisions is not enough.
Start with the problem the owner can describe. For example: suitable enquiries arrive while the crew is working, but callbacks do not have a reliable owner. Discovery should investigate that handoff before proposing a complete replacement of your tools.
Ask for a current-state map
The map should show where enquiries arrive, which information is collected, where it is stored and who makes the next decision. Include phone, forms and existing customer channels where they are relevant. Mark the awkward cases: missing information, repeat callers, schedule changes and work outside the service area.
The provider should inspect your actual process with appropriate access rather than infer it from a generic template. A small sample of approved records can identify recurring gaps, but it should not be used to announce unverified annual losses or universal conversion rates.
Require an evidence ledger
Separate observed facts, owner estimates and assumptions. If a call log shows unanswered calls, that is an observation. If someone assumes every call would have become a job, that is a hypothesis requiring review.
Use the missed-call worksheet to estimate a range with your own qualification and contribution inputs. The discovery output should identify what data is missing and whether gathering it is worth the effort before building.
Compare realistic options
Ask for at least the practical alternatives: change the operating routine, configure an existing product, add a narrow connection or replace a system. Include the option to stop if the proposed benefit does not justify the change.
For example, Jobber documents online booking and approval settings. If that existing feature covers your need, discovery should explain why additional software is or is not necessary. A custom build needs a specific reason, not just a more impressive demonstration.
Get an implementation boundary
The proposed scope should name what the system will do, what it will not decide and which actions need approval. It should specify the authoritative records, required access, customer-facing wording, exception owner and fallback.
A useful acceptance test reads like an operator scenario: a synthetic assessment request reaches the actual review queue; a person approves it; the schedule and customer status agree; a duplicate does not create a second appointment. Include failed connections and a way to pause automated action.
Avoid a scope that promises connected operations while leaving every destination unspecified. The handoff guide gives you a way to inspect the connection on one controlled record.
Understand the continuing responsibility
Ask who maintains service information, permissions and booking rules after rollout. Get the recurring costs, usage assumptions, support boundaries and the process for requesting changes in writing. Confirm what you can export and how you leave without losing your business records.
If public visibility is part of the work, ask for accurate service information and useful pages, not a guaranteed ranking. Google's people-first guidance emphasizes substantial useful content rather than output volume as the goal.
Decide at the end of discovery
You should be able to approve a narrow tested build, choose a simpler option, collect missing evidence or stop. That decision is the deliverable. An implementation plan should make dependencies and ownership clear enough that another competent person can understand it.
GlassRiver's current approach focuses on the customer journey and proving the process in its own business. Discuss your discovery scope with a concrete example of the gap, the systems you already use and the decision you want the work to support.