A support assistant answers quickly: your cancellation is complete. But the booking still exists in the reservation system. The customer received fluent language, not a completed service.
For a first support AI deployment, choose one narrow request with a source of truth and a verifiable result. Appointment changes, document checklists, and enquiry routing are easier to define than an assistant expected to handle every conversation.
Start with an enquiry
Consider an illustrative community service. A prospective resident asks about a viewing, required documents, and whether a unit is available. This is a proposed workflow, not a reported customer deployment.
Split the request into three operations. The checklist comes from an approved knowledge source. Availability comes from the booking system. The viewing request becomes a tracked CRM item. A model can interpret the message, but it should not invent inventory or confirm a booking without a system response.
Define the action contract
| Request | Source of truth | First-release behavior |
|---|---|---|
| Required documents | Versioned checklist | Explain and link the source |
| Unit availability | Inventory system | Report current response with timestamp |
| Arrange a viewing | Booking service | Propose slots; confirm after successful booking |
| Change contract terms | Authorized staff | Collect context and route for review |
| Request status | CRM case state | Return recorded state and owner |
Keep answers separate from side effects. Reading a checklist and changing a booking require different permissions and recovery paths.
Design the operator handover
Show the original message, extracted intent, sources consulted, actions attempted, and reason for escalation. Do not force the operator to reconstruct the conversation from a summary alone.
Preserve customer corrections. If the user changes their preferred date, invalidate the earlier proposal before booking. If an integration times out, show an uncertain state until reconciled; sending a request does not prove it succeeded.
Evaluate realistic conversations
Build a versioned test set from representative requests, with sensitive details removed where appropriate. Include incomplete requests, conflicting dates, mixed languages, unavailable inventory, duplicate submissions, and users changing their minds.
Have an operator define the expected resolution or escalation for each case. Judge the answer and resulting system state separately. A friendly answer can still create the wrong booking.
Measure correct resolution, inappropriate confirmation, unnecessary escalation, operator handling time, and reopened cases. Count self-service completion only when there is evidence of a completed outcome; silence after a reply is not proof of resolution.
Roll out with explicit release gates
In shadow mode, the assistant proposes a response while a person handles the request. Review disagreements and record causes. Next, allow approved informational replies while keeping writes behind review. Expand only for request types that meet agreed evaluation criteria.
The release gate should name supported intents, error classes that block release, integration failure behavior, and the person able to pause automation. Set numeric targets from the workload and consequences, not an arbitrary benchmark.
What the client should receive
A usable delivery includes the intent map, knowledge-source ownership, integration field mapping, evaluation cases, review interface, and incident runbook. Establish who updates checklists and policies; otherwise the assistant becomes stale even if its model stays unchanged.
Explore our community workflow concept or discuss a focused first release.
