Quote intake, from inbox to CRM record
The most common coordination tax in an owner-led company is somebody re-typing a request that already arrived in writing. This build removes the typing without removing the judgement.
Reference build 01
Keelix’s own build — not a client result · in progressWhat this exists to fix.
Quote requests arrive in three or four different shapes, and somebody re-keys each one into the system that actually holds the record. The work is dull, it is easy to get wrong, and it happens at the exact moment a prospect is deciding how responsive the company is.
The usual failure of automating it is that the automation is confident about ambiguous requests. A misread quantity or a wrong ship-to address is more expensive than the typing ever was, so the control point matters more than the extraction.
How it is put together.
Plain enough for an owner to follow, specific enough for whoever maintains it afterwards.
-
Intake
A dedicated mailbox and web form endpoint collect requests. Every item is stored raw and unmodified before anything else touches it, so the original is always recoverable.
-
Extraction
A language model produces a structured record against a fixed schema — customer, line items, quantities, dates, delivery terms — and is required to return an explicit confidence and a quote of the source text for every field it fills.
-
Validation
Deterministic checks run before a human ever sees it: known customer lookup, catalogue match on part numbers, quantity sanity bounds, and required-field completeness. These are ordinary code, not model calls, because they must not vary.
-
Control point
A person sees the extracted record beside the original document, with low-confidence fields marked. Approving writes to the CRM. Rejecting sends it to the manual queue and records why, which is what later improves the schema.
-
Write and audit
On approval the record is written to the CRM through its API, and the raw source, the extraction, the confidence, the reviewer, and the timestamp are retained together as one auditable trail.
-
Fallback
If extraction fails, the CRM is unreachable, or the model provider is down, the request lands in the same manual queue the business used before the build existed. Nothing is lost and nothing is silently dropped.
How it will be evaluated.
The procedure is published before a run exists, so the evaluation cannot be rewritten around a preferred result.
-
Freeze a versioned input set covering email, PDF, and web-form requests. Retain each raw source and record how the sample was selected before processing begins.
-
Run every input through the fixed extraction schema and deterministic validation checks. Keep the source quotation, confidence, validation outcome, and proposed record together.
-
Present each proposal beside its source for review. Record approvals, corrections, refusals, and field-level disagreements without treating a reviewer correction as a successful extraction.
-
Exercise provider failure, CRM failure, and ambiguous-input paths. Confirm that each request reaches the manual queue once, remains recoverable, and is never silently dropped.
-
Compare end-to-end handling time and cost with the recorded manual baseline. Retain the harness, anonymized run record, calculation method, and failure log before publishing a figure.
What it has to do to count.
Agreed before construction, published whether or not they are met.
- Every field the model fills can be traced to a quote from the source document.
- No record reaches the CRM without an explicit human approval.
- Extraction disagreements with the reviewer are logged and reviewable by field.
- A provider outage degrades to the manual queue without losing a request.
- End-to-end handling time is measured against the manual baseline recorded before the build.
- Running cost per request is recorded, including model usage.
What has been run and retained.
No completed evaluation run has been published.
Where it stops, refuses, or hands back.
A build with no stated limits has not been examined closely enough.
- Handwritten and scanned-at-an-angle documents remain unreliable and are routed to manual handling rather than guessed at.
- Novel part numbers not present in the catalogue always require a person, by design.
- The build assumes the CRM exposes a usable API. Where it does not, this becomes an integration problem before it becomes an AI problem.
- This has not yet been run at the volume of a real operation. Until it has, the timing and cost figures above stay empty.
Operational guidance
This pattern, fitted to your operation.
An Audit works out whether a build like this is the right first one for your business, and what it would take.