Case study · AI implementation
A working AI-enhanced CRM demonstration showing what AI handles, what ordinary software handles, where people keep control, and how I would evaluate the result.
The problem
A small home-services business runs on the phone. The people best equipped to answer it are the people who are under a sink, on a roof, or driving between jobs. So calls go to voicemail, and a homeowner with a leak calls the next company on the list.
The knock-on problems all come from the same place. Intake is inconsistent, because whoever picks up asks whatever they remember to ask. Follow-up is slow, because it depends on someone finding time at the end of a long day. Quotes take days for jobs that were quoted in someone’s head on the drive home. Review requests get sent when someone remembers.
Limited capacity creates inconsistent data and slow follow-up. The workflow design follows from choosing the appropriate role for AI, ordinary software, and human judgment at each step.
The workflow
Color shows who owns each step. Gray marks deterministic software, green marks AI, and gold marks human review.
The decisions
Some steps use ordinary software even though AI could handle them. Those choices matter as much as the AI features.
| Step | Handled by | Why |
|---|---|---|
| Answer the inbound call | AI | Open-ended conversation. A phone tree cannot handle "my water heater is leaking and I have a dog in the yard." |
| Capture name, address, and phone | AI, then human | A language model extracts the details. A deterministic lookup validates the address before the workflow uses it. |
| Classify job type and urgency | AI | AI can interpret an unstructured description and map it to a defined job type and urgency level. |
| Assign a technician | Software | Deterministic rules handle skills, geography, and availability with clear, explainable results. |
| Set the price on a quote | Human | Pricing carries liability. The system assembles line items, and a person sets and owns the final number. |
| Draft the follow-up message | AI, then human | Drafting saves real time. Sending is consequential, so the draft waits for approval before it reaches anyone. |
| Book the appointment | Software | Ordinary scheduling logic handles calendar conflicts accurately and consistently. |
| Flag a review for a response | AI, then human | AI can flag the review type, while a person approves any public response. |
When it goes wrong
These examples show how a production implementation should detect problems, stop safely, and route work to a person.
| Failure scenario | Detection rule | Expected response | Human owner |
|---|---|---|---|
| The address is unclear or misheard | Validation lookup fails | Asks once more, then records the lead as address unconfirmed and sends it to a person | Office manager, before dispatch |
| Ambiguous job classification | Required classification details are missing or conflicting, or no supported category is returned | Creates the lead and routes it to human triage for assignment | Triage queue |
| Calendar service is unavailable | Booking call returns an error | Says it cannot confirm a time, takes the request, and promises a callback. Never invents a slot | Lead flagged needs scheduling |
| Request falls outside supported scope | Intent classified as unsupported | Stops trying to solve it and offers a callback from a person | Escalation queue |
| Caller asks to cancel, escalate, or makes a threat | The transcript contains a defined escalation signal: cancellation intent, a request for management, abusive language, or a threat | No automated message is sent at all. The workflow stops and hands the whole thing over | Owner, directly |
When required information is missing, conflicting, or outside defined workflow boundaries, the system routes the work to a person.
Rollout
For a small home-services team, I would start with one narrow use case and expand only after the workflow proves useful.
Sit with whoever answers the phone. Map the real path from call to booked job, including the parts that only exist in someone’s head. Measure the baseline before touching anything: missed calls, time to first response, how often intake is incomplete.
A baseline everyone agrees is accurate
After-hours missed calls only. Every AI output is reviewed by a person before it reaches a customer. Keeping the scope narrow makes it easier to compare the pilot against the existing process.
Review shows the extraction is trustworthy and staff are not working around it
Extend to business-hours overflow. Loosen approval on the single lowest-risk step and nothing else. Train the full team with hands-on sessions. Re-measure against the baseline.
Metrics moved and staff would object if you removed it; expand, adjust, or stop
Measurement
These are proposed measures. The demonstration has no operating business or baseline, so there are no measured results.
| Metric | How you’d baseline it | The decision it drives |
|---|---|---|
| Missed-call recovery rate | Phone log, 30 days prior | The core value case. If this does not move, stop the project |
| Time to first response | Lead created → first contact timestamp | Whether speed is genuinely improving or just moving somewhere else |
| Intake completeness | Share of leads with every required field | Whether AI intake captures the required information more consistently |
| Edit rate on AI drafts | Share of drafts changed before sending | Quality signal. High and staying high means the drafts are not earning their place |
| Escalation rate | Share of calls handed to a person | Scope signal. Tells you where the real boundary sits |
| Staff adoption and confidence | Structured staff interviews before launch and at day 90 | Whether the workflow fits how the team actually works or needs to change |
Limits
This demonstration uses fictional data. It does not include real customers, live call volume, production schedules, measured results, or a security review.
This demonstration tests the workflow and implementation choices. It does not prove team adoption inside an established process.