Design enquiry intake that preserves context
Capture customer enquiries across channels with useful fields, clear ownership and a safe path for incomplete requests.
Enquiry intake should leave the team with a usable request, not merely another notification. The design question is what information must survive the journey from a form or inbox to the person who will respond. AI can help interpret free text, but intake reliability depends on ordinary validation and record handling.
Separate submitted facts from interpretation
Keep the original message and its arrival details alongside any extracted fields. Store a customer’s stated requirement separately from an AI-generated summary or suggested category. This lets a reviewer resolve disagreements without searching the mailbox again and prevents later users from mistaking an interpretation for the customer’s own words.
Choose a minimal intake schema: source identifier, contact method, request text, arrival time, owner and current status. Add fields only when they change the next action. Making every field compulsory may discourage enquiries, while guessing missing values produces misleading records. Use an explicit needs-information state for genuinely required details.
Design arrival and confirmation as separate events
Give each submission a stable identifier and retain the channel’s identifier where available. The same customer may retry a form after a slow response or forward an email again. Check whether the event has already been recorded before creating another task, and distinguish repeated delivery from a genuinely new request.
Show a success message only after the intake record has been accepted by the intended system. If an acknowledgement email is separate, track its result separately. Receiving a request, sending a message and booking a consultation are different events; customer-facing wording should identify which one actually happened.
Make the next person’s work easier
Route using explicit service or location rules where possible. Use AI classification only for requests that need interpretation, with an unclassified option. Include enough context for the recipient to act: the original text, suggested category, missing details and a link to the authoritative record, rather than a vague notification.
Test malformed addresses, empty messages, repeated submissions, attachments and destination outages. Define where requests wait if the CRM is unavailable and how staff find them. An intake system that silently drops failures can appear efficient while losing work, so acceptance counts should be reconciled with destination records.
Practical checklist
- Retain original text beside extracted fields.
- Assign a stable identifier before downstream actions.
- Separate receipt, acknowledgement and booking statuses.
- Provide a visible queue for incomplete requests.
Illustrative setup: installation enquiries
A home-services company receives a form containing a postcode, preferred contact method and a description of the work. The workflow prepares a request record and highlights a missing equipment model. A coordinator asks one follow-up question before arranging a visit; the form confirmation states only that the enquiry was received.
Common questions
Should intake collect a budget immediately?
Only if it changes routing or qualification and you can explain why it is useful. Optional ranges may be more appropriate than requiring an exact number before the customer understands the service.
Can all incoming channels share one queue?
Yes, if the records retain their source and reply channel. Avoid flattening away email threads or attachment context that the person responding will need.
Further reading
Start with your actual workflow.
Turn the useful parts of this guide into a focused project brief.
Shape your project