Context and goal
Enquiries arrive through a web form, email and a messenger. This sample covers the lead-intake reference build: one intake format, qualification, a CRM record and an alert. The goal is to keep every enquiry available for action, including requests that cannot be classified safely.
Scope
Normalize contact, channel, message, attachments, timestamp and source. Extract request type, priority, budget, summary and a reply draft. Route uncertain results to a person. Create the CRM deal with an idempotency key and notify the owner in Slack. Agree whether standard replies can be sent automatically or require approval before launch.
A replacement CRM, additional business processes and changes to payment or order records are outside this sample scope.
Sample inputs
These are fictional acceptance examples, not client messages.
- “The kitchen pipe has burst. Could someone come today? I can confirm the address in writing.” Expected: urgent service request; budget is unknown.
- “Can you quote for a booking system connected to our CRM? We have a budget of USD 3,000.” Expected: integration enquiry, stated budget preserved.
- “Need help. Existing setup stopped.” Expected: manual review if the context is insufficient; keep the original text.
Expected output
The field contract below illustrates the structured output described in the reference build. CRM mappings and allowed priorities are agreed before implementation.
{
"type": "string",
"priority": "agreed priority value",
"budget": null,
"contacts": {},
"summary": "string",
"reply_draft": "string",
"confidence": 0.0,
"needs_review": true
}A missing budget is null. A model must not infer it from the tone of the enquiry. The original source and timestamp stay attached to the record, separate from the model output.
Edge cases and failures
Short messages and mixed languages go to review when uncertain. Repeated delivery keeps the original idempotency key. Two distinct requests from the same contact remain separate enquiries.
Invalid model output or no response triggers three retries with exponential delay. After that, retain the original enquiry without enrichment and mark it for review. If the CRM is unavailable, queue the record and replay it after recovery. Alert on failures and on a 15-minute gap during configured business hours.
Acceptance
For each agreed input, inspect the original message, qualification, branch decision and CRM write. Check that missing values stay unknown, uncertain results reach review, and repeated delivery creates no second deal. Disconnect the CRM in a test environment, restore it and inspect the replayed record. Confirm that the owner can see alerts and logs.
Timeline and price
Five working days: process and schema on day one; intake on day two; qualification on day three; CRM, errors and alerts on day four; acceptance and handover on day five. Sample fixed scope: one working workflow, from USD 1,190. Provider usage and hosting are separate. A real project receives its own written scope and acceptance criteria.