An AI Enquiry Workflow That Keeps Sales in Control

An enquiry arrives with a technical attachment and a short email. Before anyone can respond, someone has to identify the application, read the requirements, find the account and decide who should handle it. That preparation is a plausible place for AI assistance. Sending a confident answer is a different job.

A useful first workflow prepares a reviewable record. It should make the original evidence easier to inspect, not ask sales to trust a summary without opening the source.

Follow one request through the boundary

1. Receive. Preserve the original message, attachments and source page under the agreed access policy.
2. Extract. Copy stated requirements into a draft. Attach source references and leave absent information blank.
3. Check. Compare product and territory fields with deterministic routing rules. Flag conflicts rather than choosing silently.
4. Review. A responsible person accepts or corrects the record and selects the next clarification.
5. Commit. Write the approved record to CRM and retain the approval. Sending an external message requires its own permission.

Keep the first version small enough that a reviewer can compare its output with the original request. If reviewing the assistant becomes more work than preparing the record, investigate that before adding another integration.

Decide what happens when the evidence disagrees

Suppose the email names one delivery country while an attachment gives another. The system should preserve both references and ask for a decision. It should not select the newer-looking document unless there is an approved rule that makes that appropriate.

The same applies to account matches. Similar company names do not establish that a request belongs to an existing strategic account. Route uncertain matches for review, particularly where account ownership or territory agreements matter.

These are constructed test cases. Build the actual evaluation set from authorised records and ask the people who handle exceptions to define acceptable outcomes.

Use rules where the rule is known

A required delivery country, an allowed file type and an approved territory mapping do not need probabilistic interpretation. A model may help extract those values from prose or summarise the application, but the system should validate the result before acting.

Do not ask a model to invent missing units, infer a certification or manufacture a delivery commitment. Mark the field unresolved. That makes the draft less complete but more useful to an accountable reviewer.

Separate responding to an enquiry from future marketing. Define the purpose and appropriate handling of personal information with a qualified reviewer. A generic mandatory marketing-consent checkbox is not a substitute for that work.

Test failure recovery, not only extraction

Run the workflow in shadow mode before permitting CRM changes. Compare routes, omitted requirements, unsupported facts and reviewer effort. Keep easy cases and exceptions identifiable in the results.

Then test a timeout after approval, a duplicate submission and a failed CRM write. A retry must not create several opportunities or send the same message repeatedly. The reviewer needs to know whether the record is drafted, approved, committed or failed.

NIST's measurement guidance is useful background for evaluation. It does not set a universal acceptable error rate for an industrial enquiry. Define tolerances by consequence and stop on failures the team cannot safely contain.

Give the operating owner a manageable job

Draft

Email states Germany; attachment states Austria. Preserve both source references. The draft has no approved territory.

Review

The account owner confirms Austria after clarification and approves revision 2. This is a human decision, not a model inference.

Write timeout

The CRM request times out. Its status is unknown, not necessarily failed: the record may already exist.

Recovery

Look up DEMO-042/revision-2 using the integration's stable external identifier. If present, reconcile the returned record; if absent, retry under the CRM's supported duplicate-prevention contract. If the API cannot establish either outcome, hold for manual reconciliation.

Completion

Mark committed only after confirmation. Do not send an external reply as a side effect of retrying a CRM write.

The exact mechanism depends on the CRM API. The acceptance test is observable: simulate a lost response after a successful write and confirm that recovery preserves one record and the approval history. This article concerns implementation; the permission guide decides what the assistant may do, while the RFQ checklist defines the information it handles.

Agree who updates routing rules and product sources, who reviews failed runs, and who can disable write access. Keep permissions limited to the workflow's actual needs. A sales-preparation assistant does not need unrestricted access to every customer record.

The RFQ intake checklist helps stabilise the fields before implementation. If the real problem is an undefined owner or inconsistent source data, fix that first. You do not need to buy an audit before recognising a known process defect.

The first operating review should answer a practical question: does the receiving person reach a sound next decision with less reconstruction? More generated summaries do not establish that on their own.