When an enquiry moves between an inbox, a spreadsheet and a CRM, its owner and next action can become difficult to see.
The pipeline below shows how our production intake pattern turns one submitted message into a structured, reviewable CRM record.
The pipeline, step by step
1. Capture — A prospect submits a form on your website (or Tally, Typeform, e-mail). The submission fires a webhook into the workflow platform (we use Make).
2. Analyse — The message is passed to an AI model with a structured prompt: extract intent, company context, volume signals and urgency from the free-text enquiry.
3. Score — The model returns structured JSON: a lead score (0–100), a status such as 'Qualified — high priority', a two-sentence summary and a suggested next action.
4. Route — The structured result is written to Google Sheets for visibility, and pushed to HubSpot: a contact is created, a deal is opened in the pipeline, and the AI summary lands as a note on the deal.
5. Follow up — The sales owner receives a notification with the score, reasons and suggested next step.
What the AI actually decides — and what it does not
The AI prepares classification, summarisation and prioritisation against agreed rules. It does not negotiate, set prices or send anything to a customer on its own. Each record it creates is visible and editable in the tools your team uses.
The review boundary keeps uncertain outputs visible instead of turning them into silent actions.
What changes for the team
The designed effect is that qualification can begin when the message arrives, prioritisation follows one visible scoring logic, and each accepted enquiry has a contextual record. The actual response-time and conversion effect must be measured in the deployed process.
The example setup uses a form, Make, Google Sheets, HubSpot and an AI model. The exact stack follows the client's existing accounts and access boundaries.
Implementation notes from a working intake pattern
The most important design decision is the data contract, not the prompt. Decide which fields make an enquiry actionable, which source value must be retained and which missing fields should trigger a question rather than a guess.
Run a calibration set before routing anything unattended. Compare extracted fields, status and next action against decisions made by the people who currently handle the enquiries. Record disagreements and change the rule or schema before widening the automation.
A production path also needs idempotency, an exception queue and visible ownership. If the CRM write fails, the enquiry must remain recoverable; if the model is uncertain, the item must remain reviewable.
Acceptance checklist
- Every source enquiry has a traceable record
- Missing information is explicit
- Classification reasons are visible
- One person or queue owns the next action
- Failures enter a monitored exception path