The job is straightforward: identify the customer, understand the request, prepare the next step and make sure someone is accountable for it. The difficulty is the exceptions. An existing customer uses a different address, a message contains two requests, an attachment cannot be read, or the CRM is temporarily unavailable. Design those paths alongside the easy one.
The workflow at a glance
| Step | Responsibility | Output |
|---|---|---|
| Receive | Inbox/form integration | An event with a stable message ID |
| Interpret | AI within a defined extraction schema | Proposed name, company, request and missing fields |
| Validate and match | Rules and CRM lookup | An existing record, a new-contact proposal or an exception |
| Prepare | AI using approved service information | Draft response and proposed follow-up |
| Approve | Named team member | Approved, edited or rejected action |
| Commit and record | Restricted integration | CRM change, permitted message and an audit record |
1. Receive once, process once
Capture a stable event identifier and record processing state. Integrations often retry a webhook or deliver events more than once. Before creating a contact or task, check whether that event has already been completed. Limit the workflow to the agreed inbox, folder or form rather than granting unnecessary access to everything.
2. Extract information without inventing it
Ask for a defined set of fields and allow an explicit missing value. A model should not supply a company name, phone number, budget or deadline just because the CRM expects one. Keep the original message attached to the proposed interpretation so the reviewer can check it quickly.
Treat the enquiry and any retrieved document as untrusted input. A message asking the automation to ignore its rules, reveal another customer's data or send an unrelated message must not become an instruction. Enforce tool access and approval rules outside the text generation step.
3. Match the right CRM record
Start with deterministic identifiers such as an exact approved email match. Do not let a plausible company-name guess overwrite an existing customer. Ambiguous matches should create a review task. Record which fields are proposed to change and preserve enough history to understand what happened.
4. Draft from approved business information
The draft can use an approved service catalogue, delivery conditions and current prices. It should not promise a discount, deadline or capability that the source does not support. A request outside those sources becomes a question for the team. Keep proposal preparation separate from signing or accepting an agreement.
5. Make approval an actual control
A reviewer sees the enquiry, matched record, proposed changes and message draft together. Approval authorises that specific action. If the proposal changes materially afterwards, require another review. The tool that sends or writes should verify approval; a sentence in the prompt saying 'ask first' is not the whole control.
6. Keep failed work visible
Use bounded retries for temporary API failures and route unresolved items to an owned queue. Distinguish a draft prepared successfully from a message actually sent or a record successfully saved. Show partial completion clearly so a person does not repeat an action that already happened.
What to test before launch
- A normal new enquiry and an existing customer reply
- A duplicate event and a retry after a partial failure
- Missing contact information and ambiguous CRM matches
- A message containing hostile instructions or unrelated personal data
- An unsupported price, deadline or service request
- An expired account connection and an unavailable CRM
- An edit after approval and an attempted action without approval
Measure the work the team still does
Compare a representative sample before and after launch. Record total human handling time, review time, correction rate, unresolved exceptions and operating cost. Count the whole process, not just the seconds taken to generate a draft. A faster draft is not useful if matching errors create more work elsewhere.
This is the shape of a First Workflow Live engagement: a narrow process, explicit controls and a measurable handover. The implementation checklist helps prepare the access and decisions needed to scope it.