Capture the request and missing fields
A service enquiry may arrive with documents and an informal deadline. Define the fields required for a quote: service type, quantity, requested date and customer identity. AI can propose a structured interpretation and flag ambiguity. Keep the original evidence available to the reviewer. Missing fields should lead to a question or review state rather than a plausible invented value.
Call the existing pricing function
Pass validated fields to the application’s pricing rules. Capture the rule version, units and rounding behavior used for the draft. If the requested service has no valid price, stop for a decision. The model may explain the quote, but the amount should remain traceable to the approved calculation. This also makes later corrections reproducible.
Separate draft approval from sending
A person may approve the amount but still need to confirm capacity or delivery terms. Define exactly what the approval covers and which version of the quote it refers to. A changed deadline or attachment should invalidate the affected approval. Sending must use the accepted revision and a repeat-action safeguard so a retry cannot notify the customer twice.
Test the ordinary and awkward enquiries
Include a complete enquiry, missing information, an unsupported service and a duplicate delivery event. Confirm that the correct customer owns the record and that exceptions reach a person. The scenario is an illustrative design, not a measured client success. Its value lies in explicit rules and evidence that can be tested before the module reaches real customers.
A quote is a business commitment, not generated text
An incoming email asks for a service, includes a file and mentions “as soon as possible”. The AI module can identify the service and flag the ambiguous deadline. It should not invent a date, assume capacity or offer an unsupported discount. The application needs validated fields before a pricing function can produce a useful draft.
Give every quote a status: incomplete, draft, awaiting review, approved and sent. These states prevent a generated response from being mistaken for an authorized offer. When the inputs change, recalculate and require any relevant approval again. Store the decision and the exact version that was sent.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Missing deadline | Ask or route to a person. | No fabricated binding date. |
| Pricing | Use an approved calculation. | Reproducible inputs and totals. |
| Delivery | Send only the approved version. | Permission, recipient and send record. |
Where this goes wrong
Test repeated emails and network retries. The same request must not create duplicate quotes or repeated external sends. A timeout may mean “outcome unknown”, not “nothing happened”; reconciliation is safer than an unconditional retry.
Automate preparation without silently automating the right to make a commitment.
Turn it into a working checklist
- Retain the source request.
- Calculate with approved deterministic rules.
- Bind approval to the quote revision.
- Test missing data and duplicate events.
A concrete next step
Use a permitted sample set containing a standard enquiry, an incomplete one, an exception and a duplicate. Review the resulting records with the process owner before connecting any real outbound channel.
Watch a related case
The video could not be loaded. Try again later.