AI Voice, SMS, and Worker Dispatch System for Service Businesses

By Amar Kumar

This brief proposes an AI voice and SMS dispatch system for a one-person field-service operation moving to a remote model: local sub-contractors perform on-site work while the owner manages bookings from another time zone. The architecture would combine Vapi.ai for inbound voice, Twilio for SMS, Make.com as the orchestration layer, OpenAI for unstructured text interpretation, and a job-management CRM such as ServiceM8 or Tradify — automating the path from first phone call through property-access negotiation to sub-contractor confirmation.

Proposed outcome: A hands-free dispatch pipeline where callers receive a booking link mid-call, paid web forms create provisional job cards, Make.com texts real-estate agents for access, and sub-contractors accept jobs via Y/N SMS — with WhatsApp escalation only when automation cannot resolve the thread.

Scenario

This is a proposed solution for a recurring pattern: a solo operator in the trades or inspection space who must scale without being on the phone all day.

• Business model: One-person service business (e.g. building inspections, pest control, handyman) based in Sydney, Australia, transitioning to remote management from overseas
• Workforce: Preferred and backup sub-contractors mapped by postcode; owner dispatches work but does not attend sites
• Customer entry: Inbound phone calls for quotes/bookings; website form with payment for confirmed jobs
• Access coordination: Real-estate agents control property access; SMS negotiation for lockbox codes and time slots
• CRM: ServiceM8, Tradify, or equivalent field-service software (Google Sheets acceptable as a staging layer during migration)
• Escalation channel: Owner WhatsApp for ambiguous agent replies, declined sub-contractors, or SLA breaches

Problem

When the owner moves time zones, the manual loop — answer phone, text agent, call subbie, update CRM — becomes a single point of failure. Missed calls mean lost revenue; delayed access texts stall the whole day.

• Always-on phone burden — customers expect immediate answers; voicemail kills conversion for time-sensitive inspections
• Fragmented booking path — caller details live in call notes, form data in email, and job status in CRM; nothing links automatically
• Agent SMS ambiguity — replies like “should be fine, code 4821” or “how about Friday?” need human judgment unless structured parsing exists
• Sub-contractor chase — texting one subbie, waiting, then manually trying the backup burns hours the owner no longer has in-market
• CRM hygiene — addresses pasted from forms arrive malformed; provisional vs dispatched job states drift without enforced state machine
• Compliance & trust — Australian Privacy Act applies to customer phone numbers; SMS must identify the business; recorded voice calls need clear disclosure where required

Requirements

Functional

• Workflow 1 — Inbound voice + booking SMS: Vapi assistant on Twilio number answers with owner script; mid-call send_sms tool fires booking link to caller’s mobile
• Workflow 2 — Form → provisional job: Website payment webhook triggers Make.com; OpenAI normalizes address; CRM job card created in Provisional status
• Workflow 3A — Agent access request: On new booking, Twilio SMS to listing agent requesting access at proposed date/time
• Workflow 3B — Agent reply parsing: Inbound agent SMS → OpenAI structured JSON (yes / no / alternate_time / lockbox_code / unclear); router updates calendar or escalates
• Workflow 3C — Sub-contractor dispatch: Postcode lookup → text preferred subbie with job details; Y accepts, N or 30-min timeout → backup subbie; all-decline → WhatsApp alert
• State machine: Job statuses: provisional → access_pending → access_confirmed → dispatch_pending → dispatched → escalated
• Owner override: WhatsApp commands or CRM manual flag to pause automation on a job

Non-functional

• Latency: Booking SMS during call < 5 s; agent outbound within 60 s of form submit
• Idempotency: Duplicate webhooks must not create twin job cards or double-text agents
• Observability: Make.com execution history + central log sheet or Airtable for SMS thread audit
• Timezone: All scheduled times stored in Australia/Sydney; displayed correctly in CRM and SMS copy
• Secrets: API keys in Make connections vault; no credentials in scenario JSON exports shared to client
• Testability: Staging Twilio numbers and mock agent/subbie contacts for end-to-end rehearsal before go-live

Architecture

Three Make.com scenarios (voice-adjacent webhook, booking intake, SMS conversation hub) sit between customer touchpoints and the CRM. Vapi owns real-time voice; Twilio owns SMS transport; OpenAI modules classify agent and subbie replies.

flowchart TB classDef voice fill:#ede9fe,stroke:#7c3aed,color:#5b21b6 classDef orch fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef sms fill:#ccfbf1,stroke:#0d9488,color:#115e59 classDef crm fill:#f1f5f9,stroke:#64748b,color:#334155 classDef human fill:#fef3c7,stroke:#d97706,color:#92400e CALL["Inbound caller\nTwilio PSTN"]:::voice VAPI["Vapi voice assistant\ncustom script + tools"]:::voice CALL --> VAPI VAPI -->|"send_sms tool"| TWOUT["Twilio outbound SMS\nbooking link"]:::sms FORM["Website form + payment\nStripe / WP webhook"]:::orch MK1["Make: Booking intake\naddress clean + CRM create"]:::orch FORM --> MK1 MK1 --> CRM["ServiceM8 / Tradify\nprovisional job card"]:::crm MK1 --> MK2 MK2["Make: Access + dispatch hub\nrouters + delays"]:::orch MK2 -->|"3A: access ask"| AGENT["Real-estate agent SMS"]:::sms AGENT -->|"inbound reply"| MK2 MK2 --> GPT["OpenAI structured parse\nintent + lockbox + time"]:::orch GPT --> MK2 MK2 -->|"3C: dispatch offer"| SUB["Sub-contractor SMS\nY / N loop"]:::sms SUB --> MK2 MK2 --> CRM MK2 -->|"unclear / all decline"| WA["Owner WhatsApp alert"]:::human

System architecture — Vapi handles voice and mid-call SMS; Make.com orchestrates booking intake, agent negotiation, and sub-contractor dispatch with CRM as system of record

sequenceDiagram autonumber participant Agent as Real-estate agent participant Twilio as Twilio SMS participant Make as Make.com hub participant GPT as OpenAI GPT-4o participant CRM as ServiceM8 participant Sub as Sub-contractor participant Owner as Owner WhatsApp Make->>Twilio: access request SMS Twilio->>Agent: deliver Agent->>Twilio: reply text Twilio->>Make: inbound webhook Make->>GPT: parse reply JSON schema GPT->>Make: intent + fields alt confirmed or lockbox Make->>CRM: access_confirmed + code Make->>Twilio: dispatch offer to subbie Twilio->>Sub: job details + Y/N Sub->>Twilio: Y Make->>CRM: dispatched + assign subbie else alternate time Make->>CRM: reschedule slot Make->>Twilio: confirm new time to agent else unclear or NO Make->>Owner: high-priority WhatsApp Make->>CRM: escalated end

Agent reply sequence — OpenAI classifies unstructured SMS; confirmed access triggers sub-contractor loop; ambiguous threads escalate to owner

End-to-end flow

Happy-path pipeline — escalation branches (agent confusion, subbie decline) route to owner without blocking other jobs

Recommended stack

Recommendation: Keep the client’s stated stack — Make.com for routers and delays, Vapi.ai for voice, Twilio for SMS, OpenAI GPT-4o inside Make for JSON extraction — paired with ServiceM8 (strong AU tradie adoption) or Tradify if already licensed. A Google Sheet or Airtable sms_threads table would act as a lightweight conversation index when the CRM API lacks native SMS logging.

Why Make.com over custom code? The owner needs maintainable scenarios they can inspect; Make’s router modules map directly to the YES / alternate / NO branches. Custom Node would be cheaper at scale but harder to hand over.

Why Vapi over Twilio Studio + OpenAI? Studio struggles with natural multi-turn dialog and tool calls during live audio. Vapi’s send_sms server tool fires while the caller is still on the line — the exact UX the workflow demands.

ServiceM8 vs Tradify vs Sheets? ServiceM8’s REST API and job-status model fit provisional → scheduled → dispatched. Sheets work for MVP roster lookup but should not be the long-term job system of record.

Agent & component design

1 — Vapi inbound voice assistant

• Input: PSTN call via Twilio-imported number; caller ID for SMS destination
• Persona: Owner-provided script — services offered, pricing FAQs, booking CTA
• Tool: send_booking_link → Vapi server URL or Twilio Messages API with {{customer.number}} and static booking URL
• Output: Call transcript webhook to Make (optional logging); SMS delivery confirmation
• QA gate: Test calls with 3 script variations; verify SMS arrives before call ends; failover message if SMS fails

2 — Make scenario: booking-intake

• Trigger: Website form webhook (payment success payload)
• Steps: Dedupe by payment_intent_id → OpenAI address normalizer → ServiceM8 Create Job (status: Provisional) → write row to dispatch_log → HTTP call to wake access-dispatch scenario
• OpenAI prompt: Return JSON { street, suburb, state, postcode, formatted }; reject if confidence low → WhatsApp owner
• QA gate: 10 sample addresses including unit numbers and rural routes before prod

3 — Make scenario: access-dispatch (router hub)

4 — OpenAI reply classifier (shared module)

• Input: Raw SMS body + job context (address, proposed slot, prior messages)
• Output schema: { intent, lockbox_code, proposed_datetime, confidence, summary }
• Router thresholds: Auto-act if confidence ≥ 0.85; else escalate
• QA gate: Golden-set of 20 agent reply fixtures in Make test runs

5 — Sub-contractor roster service

• Source: Google Sheet columns: postcode_prefix, primary_name, primary_mobile, backup_name, backup_mobile
• Lookup: Make Search Rows with filter; fallback to owner alert if postcode unmapped

Implementation plan

Reporting & ops

Ops cadence would include a 15-minute daily check (failed Make runs, escalated jobs) while the owner is in a distant time zone, then a weekly 30-minute tuning session for Vapi script and SMS templates. Twilio balance and Make operation usage alerts prevent silent outages.

Proposed deliverables

Following the phased plan, a build would ship these artifacts:

• Configured Vapi assistant on production Twilio number with send_booking_link tool and owner script
• Three production Make.com scenarios (booking-intake, access-dispatch, shared error handler) with staging clones
• OpenAI classifier prompt + JSON schema documented in runbook
• ServiceM8 (or Tradify) job template with custom fields: agent mobile, lockbox code, automation status, thread ID
• Sub-contractor postcode roster Google Sheet with primary/backup columns
• dispatch_log audit sheet — every SMS and state transition
• WhatsApp escalation templates wired to owner number
• Recorded end-to-end test: live call → form submit → mock agent YES → mock subbie Y → CRM dispatched
• Operator runbook: scenario toggles, credential locations, common failure fixes

Effort estimate

Indicative effort for the three workflows through E2E test and handover (assumes CRM API access, existing website form, and owner available for UAT calls):

The hour range reflects ServiceM8 vs Tradify API familiarity, whether the website form already emits clean webhooks, and how many edge cases appear in real agent SMS threads during UAT. A fixed-price engagement would scope exactly three workflows with one CRM integration and two subbie tiers per postcode.

Glossary