By Sonny HuynhThis is an implementation guide for a service business that wants one clean system from first interest to delivery handoff. It is not a list of apps. It is the logic the apps need to follow.
The sample company in this playbook sells custom operations work. Replace its fields, owners, and message copy with your own. Keep the structure.
What you are building
One lead can enter through a form, a missed call, an email, a direct message, or a referral. No matter where it starts, the system should answer six questions:
- Who is this person and what did they ask for?
- Do we already have this person in the system?
- What are we allowed to send them?
- Who owns the next useful action?
- What should happen if they reply, book, go quiet, or say no?
- When the deal closes, what does delivery need so the client does not repeat the entire story?
If your automation cannot answer one of those questions, it is not ready to send anything.
Think about a restaurant ticket. The server does not yell "somebody ordered food" into the kitchen. The ticket names the table, the meal, the changes, the allergies, and the person responsible for each station. Your lead record is that ticket. Consent is the allergy note. The workflow is the kitchen line. Human review is the chef who stops a plate that does not look right.
The Handoff Map
Map every workflow with these seven boxes before choosing tools.
| Box | Question | Example | | --- | --- | --- | | Trigger | What exact event starts this? | Website form submitted | | Context | What facts must travel with it? | Name, company, request, source, consent | | Decision | What determines the next path? | Existing record, fit, urgency, consent | | Action | What useful thing happens? | Route owner and send requested resource | | Human rule | When must a person take over? | Duplicate conflict or unclear request | | Proof | How do we know it worked? | CRM activity and delivery event recorded | | Failure | What happens when a dependency breaks? | Retry twice, queue work, alert owner |
Do not accept words like "AI handles it" in any box. Name the input, decision, action, owner, and evidence.
Run the 20-minute leak audit
Pick ten recent leads. Use actual records, not memory. For each lead, record:
| Field | What to write down | | --- | --- | | Entered at | The first timestamp you can verify | | First useful response | When they received an answer or next step | | Owner | The person responsible at that moment | | Missing context | Anything the owner had to hunt for | | Current state | New, evaluating, booked, won, lost, quiet, unsubscribed | | Next action | A specific action and due time, or blank | | Handoff failure | Duplicate, no owner, wrong channel, no stop rule, missing promise |
Then answer four questions:
- How many leads had no visible owner?
- How many had no specific next action?
- How many were contacted through a channel without a recorded consent state?
- How many closed deals reached delivery without a complete promise and scope summary?
You do not need an industry benchmark to find your first build. The repeated failure in your own ten records is enough.
Use one lead data contract
Every entry channel should create or update the same core record. A form cannot call the field business_name while the CRM calls it account and the email workflow calls it companyName unless one normalization step translates them.
Required lead fields
| Field | Type | Required | Rule | | --- | --- | --- | --- | | lead_id | text | yes | Stable internal ID, never an email address | | first_name | text | yes | Trim spaces, preserve the person's capitalization when possible | | last_name | text | no | Do not invent it | | email | email | one contact method | Lowercase for matching, keep original for display | | phone | phone | one contact method | Store in one international format | | company | text | no | Keep blank if unknown | | request | long text | yes | What the person actually asked for | | source | controlled value | yes | form, call, email, dm, referral, event | | source_detail | text | no | Campaign, page, referrer, or event name | | email_consent | enum | yes | granted, denied, unknown | | sms_consent | enum | yes | granted, denied, unknown | | owner_id | text | after routing | Must match a real user or queue | | lifecycle_state | enum | yes | new, evaluating, booked, won, lost, quiet, unsubscribed | | next_action | text | after routing | A verb, an object, and a due time | | last_meaningful_event_at | datetime | yes | Reply, booking, meeting, consent change, or decision |
Unknown is not the same as no. Unknown means the workflow cannot use that channel until the business establishes a lawful basis and records it.
Write the first useful response
The first response should prove three things:
- The request arrived.
- The system understood what the person asked for.
- There is a clear next step.
Example email for a document workflow inquiry:
Subject: the PDF-to-TMS example you asked for
Jordan,
I got your request for the PDF-to-TMS workflow. Here is the example map with the extraction fields, exception queue, and test cases.
One question so I send the right version: are the documents mostly rate confirmations, bills of lading, or a mix?
Sonny
That is useful. "Thanks for reaching out, somebody will contact you soon" is a receipt, not a response.
Your first Handoff Map worksheet
Fill this in for one entry channel before building the entire funnel.
| Box | Your answer | | --- | --- | | Trigger | | | Required context | | | Duplicate key | | | Consent rule | | | Routing decision | | | First useful action | | | Human takeover rule | | | Success evidence | | | Retry rule | | | Alert owner | |
You now have enough to find the leak and define the first useful slice. The rest of the playbook gives you the routing, nurture, handoff, failure, and test rules needed to build it.