Map the work before automating it. A lead-to-booking workflow should show how an inquiry enters, which decisions change its path, who owns each next action, where exceptions go, and what event transfers the request into the booked-job process.
The map does not need to be a polished software diagram. It needs to make the operating truth visible.
Set the start and end points
Begin with an observable inquiry. Examples include:
- an inbound call or missed call;
- a website form submission;
- a calendar request;
- a chat conversation with contact details;
- a referral entered by staff;
- a lead delivered by an approved marketplace or campaign.
Do not begin with “traffic” if the system you are mapping starts only after a person contacts the business. That expands the scope into demand generation and hides the exact handoff you need to improve.
End with a booked-job handoff. The exact event depends on the operation. It could be a confirmed service appointment, a scheduled site inspection, an estimate visit assigned to a representative, or accepted work handed to dispatch or production.
Write the event in observable language. “Lead converted” is too vague. “Inspection booked for a defined date and assigned to a named owner” is testable.
Inventory every entry point
Create one row for every way an inquiry can become work for the team.
| Entry point | Information available | First destination | Initial owner | Expected next event |
|---|---|---|---|---|
| Phone call | Caller ID, conversation context, staff notes | Phone or CRM record | Call taker | Appointment, review, or follow-up task |
| Missed call | Phone number and call event | Phone system or inbox | Assigned queue | Human callback or approved acknowledgement |
| Website form | Submitted fields, page, source context | CRM or email | Intake owner | Review and first response |
| Direct booking | Contact data and appointment event | Calendar and CRM | Scheduler or assigned staff | Confirmation and operational handoff |
| Chat | Conversation and collected details | Conversation inbox and CRM | Chat owner | Human takeover, form, or booking path |
This exercise often exposes the first gap: two entry points create different records for the same kind of request, or one source has no accountable owner.
Separate paths only when the operation changes
Do not draw a branch for every service name. Draw a branch when an answer changes the next decision, owner, timing, or handoff.
Useful decision points may include:
- Does this request need urgent human review?
- Is the property inside the service area?
- Is this a service call, maintenance request, inspection, or larger estimate?
- Is the person a new lead or an existing customer with a new request?
- Can the business offer a booking now, or must someone review the details first?
- Does the request belong to a field-service, dispatch, or estimating system after this point?
An HVAC company may branch between urgent service, planned maintenance, and replacement. A roofer may branch around inspection, repair, and proposal status. A tree-service company may route customer-described storm or utility context to a trained person before a routine estimate path. The business decides the process. The CRM records and supports it.
Define every state with six questions
For each meaningful point in the journey, answer:
- What creates this state? Name the event or approved decision.
- What is true now? Use language staff can observe.
- Who owns it? Name a role, person, or queue.
- What must happen next? State the action and, when appropriate, a due condition.
- What ends the state? Define the exit event.
- What can go wrong? Add the exception path and owner.
Here is a compact example:
| State element | Example |
|---|---|
| Entry | Website estimate request passes service-area review |
| Current truth | The request is ready for scheduling review |
| Owner | Office scheduler |
| Next action | Offer or confirm the appropriate estimate slot |
| Exit | Appointment confirmed, request declined, or unable to contact under the approved process |
| Exception | Missing property details create a visible information-needed task |
Use the same fields as a reusable worksheet:
| Map field | What to record |
|---|---|
| Entry event | The observable action or approved decision that starts the state |
| Current truth | What the team can now say with evidence |
| Required context | Data that must be present before the next action |
| Owner | One role, person, or queue accountable now |
| Next action | The human or system action and any due condition |
| Exit | The event that ends this state or automation path |
| Exception | What can fail, where it becomes visible, and who owns it |
| System boundary | Which platform or team becomes authoritative next |
| Acceptance evidence | The record, message, task, log, or handoff that proves the result |
Once these answers are clear, pipeline stages and workflow rules become easier to design.
Mark human and automated responsibilities
Use two lanes on the map: system actions and human actions.
Automation can often support:
- receipt confirmation;
- record creation or update;
- assignment and notification;
- approved reminders;
- routine stage or field updates;
- stop conditions;
- exception alerts.
People should retain:
- urgency and safety judgment;
- diagnosis;
- custom pricing or estimate decisions;
- unusual qualification decisions;
- commitments about capacity or arrival;
- complaints and sensitive conversations;
- approval of customer-facing claims and messages.
The map should show the transfer between lanes. “Notify office” is incomplete. Record which office role is notified, what information they receive, what they must do, and what automation should pause while they act.
Add the failure paths before the happy path looks finished
A useful map includes what happens when the normal route fails.
Duplicate or conflicting records
What happens when the same person calls, submits a form, and books directly? Decide whether those events update one contact, one opportunity, or several legitimate opportunities.
Missing information
Do not let an incomplete address or service type disappear into a generic inbox. Create an information-needed state with an owner.
No response
Define the approved attempt process, the owner, and the closure rule. “Keep following up” is not a state.
Reply during automation
Show whether the sequence stops, branches, or waits for a person. The reply must change ownership, not merely appear in a conversation list.
Booking change
Booked, rescheduled, cancelled, and no-show events should lead to distinct next actions. Do not leave the CRM in a pre-booking state after the calendar has changed.
Manual takeover or out-of-scope request
Give staff a visible way to own an exception, and suppress messages that are no longer appropriate.
Turn the map into system requirements
Only after the process is visible should you translate it into software.
| Map decision | Possible system requirement |
|---|---|
| Several inquiry sources enter one review queue | Contact matching, opportunity rules, source fields, and assignment |
| Service type changes the next owner | Structured field and routing rule |
| Appointment confirmation ends initial follow-up | Calendar event, stage change, and workflow exit |
| Staff takeover stops automated messages | Ownership marker, reply or takeover event, and suppression rule |
| Dispatch software owns the booked job | Defined handoff payload and source-of-truth boundary |
| Missing information needs review | Exception state, task, and notification |
This prevents feature-first scope. A custom field, tag, workflow, or integration should exist because the mapped process needs it.
The map can become too detailed. Precision helps only when staff can observe and own the proposed state. Edex would not create a branch for every service label or minor activity. We branch when the next decision, owner, timing, or handoff changes.
Turn the map into acceptance scenarios
Each important path should become a test.
For every scenario, record:
- starting conditions;
- action taken;
- expected contact and opportunity state;
- expected owner;
- expected customer communication;
- expected internal action;
- expected exit or handoff;
- evidence captured;
- pass, fail, and correction status.
Include normal cases, alternate routes, and failures. A form submission that books successfully is one scenario. The same contact submitting twice, replying during a wait, booking directly, rescheduling, or falling outside the service area are different scenarios.
In one verified Edex implementation, a three-page funnel, eight-stage pipeline, and seven canonical workflows were tested through 23 documented scenarios. All 23 passed at the recorded acceptance point, and the work included deployment and handoff. The useful lesson is not that every project needs 23 tests. It is that the map, build, and acceptance record should trace to the same agreed behavior.
A useful trace has five links: map decision → system requirement → acceptance scenario → captured evidence → handoff note. If the team cannot connect a configured asset back to a mapped requirement or forward to a test, the asset may be unnecessary or the definition of done is incomplete.
Decide whether the problem is isolated or lifecycle-wide
A focused repair may be enough when one form, trigger, notification, or exit is broken and its dependencies are already understood.
A wider system scope is justified when:
- several sources create inconsistent records;
- stages do not represent the real process;
- staff ownership is unclear across handoffs;
- automation continues after replies or bookings;
- dispatch, CRM, and calendar states disagree;
- fixing one workflow would require guessing about the rest of the lifecycle.
If you are still identifying the current failure, use the diagnostic guide to where home-service leads get lost before booking. If the map is clear but implementation is not, the GHL CRM and Automation service explains how Edex scopes connected lifecycle work.
Make the next action visible
A useful lead-to-booking map gives every in-scope inquiry a visible state, owner, next action, and exit. It also shows where the CRM stops and another operational system or person takes over.
If the mapping exercise exposes several connected gaps, Request Your Lead-to-Booking System Plan. The next step should match the process, whether that is one repair, an audit, or a lifecycle-wide build.