From the shared inbox to the CRM in minutes: an AI agent that triages quote requests and support tickets, and waits for your approval

Reading time, and almost nobody measures it. Before a quote exists, someone finds quantities and materials in the email and every attachment, looks up the customer's history and decides who owns the request. We looked for an independent 2026 survey of this intake step and did not find one. The figures in circulation come from vendors: Mavlon, which sells RFQ automation, wrote on 16 February 2026 that reading an RFQ email takes 10 to 20 minutes and extracting data from one drawing 30 minutes to 2 hours. That is a vendor claim based on its own shop visits, with no sample size.

There is independent data on speed. Modern Machine Shop's 2026 Top Shops benchmark (survey run 1 February to 10 April 2026, published 5 October) reports a 51% win rate on new business for shops that turn quotes around within a day, against 41% for slower shops. Machine shops, self-reported, a correlation. Still the best dated number we found on speed and winning.

Treat the rest with care. One consultancy page says the average manufacturing quote dropped from 3.4 days to 3.7 hours and calls that 85% faster; the arithmetic only holds if a day has eight hours, and no source is given.

It turns one messy message into one checked record plus a draft, and parks both in a review queue. The model reads the email and attachments and writes the draft reply. Everything between those two steps is ordinary code against your CRM, ERP or helpdesk. Eight steps, two of them with a language model:

1. Ingest from the shared mailbox, a portal form or the helpdesk API, attachments included.
2. Extract body text, PDF, Excel and scanned pages (through OCR) into a fixed schema. Every field keeps a pointer to the page or cell it came from.
3. Validate in code: units, quantities as numbers, required fields present.
4. Match the customer by email domain or VAT ID, lines against your catalogue, and previous quotes for the same items. Free-text product descriptions go through retrieval over the catalogue; we explain how we pick that approach in RAG, fine-tuning or long context.
5. Classify type, urgency and owner, by rules wherever a rule exists.
6. Write the CRM deal, ERP quote draft or helpdesk ticket.
7. Draft the reply: a draft quote, or a precise request for the missing information.
8. Queue it for approval. Nothing customer-facing leaves yet.

A trimmed extraction record looks like this (IDs are placeholders):

{
  "request_type": "rfq",
  "source": {"channel": "email", "input_sha256": "9f2c...e41a"},
  "customer": {"crm_id": "acct_0000", "method": "email_domain", "confidence": 0.98},
  "lines": [
    {"customer_ref": "BRKT-220 rev C", "qty": 1200, "unit": "pcs",
     "matched_sku": null, "confidence": 0.61,
     "evidence": {"file": "drawing_pack.pdf", "page": 3}}
  ],
  "requested_delivery": "2027-01-15",
  "missing": ["material grade", "surface finish"],
  "proposed_action": "request_missing_info",
  "price": null
}

price is always null. The agent never fills it.

On one screen, before anything reaches a customer or touches a price. The left half shows the original email and attachments, with the source text of each extracted field highlighted. The right half shows the fields, the matched customer, SKUs and past quotes with confidence scores, the rule checks that passed or failed, and the proposed reply. Four buttons: approve, edit, reject, escalate. The approver's name and timestamp are stored with the action. Edits are stored as a diff; those diffs become the test set for the next prompt version.

Some things always need a person:

• prices, discounts and payment terms;
• delivery dates and any other commitment, plus warranties and legal terms;
• any field under the confidence threshold, and any request type not yet released for automation.

Low-risk steps can run alone after a shadow period: the acknowledgement with a reference number, creating the record, tagging and routing. We release them one at a time, each with a date and the name of whoever signed it off.

Even vendors that sell autonomy now count the hand-off. In March 2026 Fin (formerly Intercom) moved from resolutions to "outcomes", and one outcome is a procedure where the agent gathers context, reads and writes to external systems, then hands off to a human agent.

Because code makes errors visible and a model hides them. The model does one job: read unstructured text and fill the schema. Schema validation, lookup tables and a rule engine make every decision after that. If validation fails, a match is ambiguous or a rule cannot fire, the request fails closed into the human queue. We would not let a model choose a discount. Your price list already knows it.

This is also our answer to "agent washing", the label Gartner gave in June 2025 to assistants and RPA rebranded as agents, in the same release that forecast over 40% of agentic AI projects cancelled by the end of 2027. A pipeline with one extraction step and an approval gate is a workflow with an LLM step, and we say so (framework in Workflow or agent?). Cost stays bounded too: one extraction call per request, one retry at most, and a token cap enforced outside the model (see AI agent cost control). The extractor has no tools, which matters because every inbound PDF is untrusted input; where the pipeline writes to systems, connectors are vetted as in MCP servers in production.

Keep a per-request record that someone outside your team can check: a hash of the input, the extraction output, rule results, the model and prompt version, and who approved what and when. Six months later a buyer says "you quoted 1,200 pieces at that price". You need to show which email it came from, what was extracted, which rules passed and whose name is on the approval.

Logs in your own database prove little to an outsider: whoever runs it can edit a row. We record agent runs with SealedRun, an independent open-source tool we use. It signs each step into a hash chain that can be verified offline. Version 0.8.1 (5 November 2026) has record kinds for llm_call, tool_call, policy_decision and human_approval, which map directly onto this pipeline. Bodies can be left out of exports, so you can share proof without shipping the customer's drawings.

Three, and this is an engineer's reading, not legal advice. EU AI Act Article 50 has applied since 2 August 2026; Gibson Dunn (27 May 2026) confirmed the Digital Omnibus left the user-facing transparency duties on that date. Systems that interact directly with people must tell them so, unless it is obvious to a reasonably well-informed person, and Jones Walker (16 July 2026) notes fines of up to EUR 15 million or 3% of worldwide turnover. Whether a reply drafted by the agent but approved and sent by a human counts depends on who sends it and how much the human changes; check with counsel. Our default: auto-sent acknowledgements carry a one-line disclosure.

GDPR Article 22 gives people the right not to be subject to decisions based solely on automated processing with legal or similarly significant effects, and where such decisions rest on contract or consent, the controller must offer human intervention. Most RFQ triage never gets there. Refusing a customer credit terms might, and the approval step is that intervention.

Then the model provider. Sign its DPA. OpenAI keeps API abuse-monitoring logs up to 30 days and grants zero data retention only after approval; its EU data residency requires such modified retention terms. More on dates and duties in EU AI Act after the Omnibus.

They are strong on chat and help-centre resolution over their own data, and this autumn they got better at attachments. They stop at your ERP's price logic, your drawing-to-SKU mapping and your approval rules.

Whichever you pick, data is the usual blocker. In Salesforce's State of Service survey (3,075 respondents, 20 May 2026), 66% of service organisations use agentic AI and 72% of service operations staff call data readiness a major blocker. We use tools like n8n for plumbing and keep approval rules and the audit trail in code you own, so a platform switch does not take your history with it. The right column is our view for attachment-heavy B2B RFQs, not a verdict on the products.

This is our planning approach; outcome numbers come from your data. Week 1: collect about 300 real, anonymised requests across your types, define the schema, and write the approval rules with the people who approve today. Weeks 2 to 4: integrations, extraction, matching and the review screen. Then shadow mode: the agent runs on live traffic, sends nothing, and its output is compared with what your team actually did.

Three metrics decide go-live: field-level accuracy (a wrong quantity costs more than a wrong salutation), time from arrival to ready-to-review, and the override rate on the approval screen. We go live per request type, catalogue repeat orders first, drawing-heavy RFQs last or never. We do not promise a percentage before the shadow data exists.

Bring us ten real RFQs or tickets (anonymised) and we will return a sample extraction, the approval rules we would set, and a plan for a pilot on one request type. Send them here, or see our AI and automation services.