Which side of the RFQ process are you automating?
An RFQ is a request for quotation. This guide is for a supplier's sales or operations team receiving customer requests by email and retyping them into a quote workspace. It covers intake and review before pricing or sending a quote. Procurement tools that send RFQs to suppliers and compare their bids address a different task.
How to turn an email into a checked request
Start by defining the fields your team needs, capture only the relevant messages, extract those fields, check them and prepare a draft for review. Use rules for predictable formats; consider AI interpretation when wording or attachments vary. Automating intake does not require automating the price decision or sending the quote.
The example below is fictional and illustrates a design, not a live integration or measured customer result. Imagine this message: ‘Please quote 12 units of part AX-20 for delivery to our Helsinki office.’ The requested delivery date is absent. A workflow should preserve that uncertainty instead of inventing a date.
| Field | Extracted value | Review decision |
|---|---|---|
| Part code | AX-20 | Check against the approved product list. |
| Quantity | 12 units | Confirm the unit and allowed quantity. |
| Delivery location | Helsinki office | Ask for a complete delivery address. |
| Delivery date | Not provided | Request clarification; do not guess. |
| Price | Not provided | Leave pricing to the agreed pricing process. |
Build the intake flow in six steps
Use this as a workflow design sequence. Exact setup depends on your mailbox, destination and access permissions; it is not an Outlook or Gmail connector tutorial.
- 1. Select the input: choose one mailbox, folder or request type and decide who handles messages outside it.
- 2. Define the output: list required fields, valid formats and where each value came from. Keep the original email reference.
- 3. Extract the details: map stable fields with rules; test interpretation for variable wording. Mark unreadable attachments for review.
- 4. Validate and check duplicates: compare required fields and identifiers. Decide whether a repeated message is a new request, correction or duplicate.
- 5. Prepare a review: show extracted values beside the source and let a person correct them or ask for missing information.
- 6. Update and confirm: after approval, record the destination result. On failure, reconcile whether a record already exists before retrying.
Inspect five cases in our implemented reference
The table below comes from the same validated fixtures and decision evaluator as our public quote-intake demo, matched against recorded LangGraph executions. Each graph run pauses for review, then resumes with a synthetic reviewer decision. These are inspectable implementation records, not a customer case study.
Extraction is preset, no AI model is called and no live mailbox or destination is connected. The records demonstrate policy routing and the review boundary. They do not establish production AI accuracy, restart recovery or time savings. Use the downloadable checklist as a starting point and replace the cases with your own approved examples before a pilot.
| Synthetic case | Policy decision | Recorded result |
|---|---|---|
| Complete quote request | Prepare for approval | Approved preview prepared; no external write. |
| Missing delivery information | Request missing information | Synthetic reviewer declined; processing stopped. |
| Possible duplicate request | Review a possible duplicate | Synthetic reviewer declined; processing stopped. |
| Ambiguous attachment | Verify extraction manually | Synthetic reviewer declined; processing stopped. |
| Destination system unavailable | Queue a retry | Approved payload preserved for retry; no external write. |
Handle normal requests and exceptions differently
These are hypothetical routing decisions to agree with the workflow owner before connecting a live system.
| Request | Next step | What remains blocked |
|---|---|---|
| All required fields present | Prepare a checked draft for approval. | Sending a quote or creating an order before approval. |
| Delivery details missing | Draft a clarification question. | Treating the request as complete. |
| Possible duplicate | Show the earlier request to a reviewer. | Creating a second destination record. |
| Destination update times out | Check whether the first write succeeded. | Blindly retrying a potentially completed write. |
Is your shared inbox a good place to start?
This guide is for operations, sales and customer service teams that repeatedly read similar emails, open attachments and copy details into another tool. A candidate task has a named owner, a predictable output and enough repeated handling to investigate.
Consider a hypothetical quote request: a person reads an email and PDF, copies product codes and quantities into a spreadsheet, checks delivery details and prepares a reply. A pilot could prepare those fields and highlight missing information before a person approves the next step. This is a proposed workflow, not a measured customer result.
Why a shared inbox becomes hard to manage
A request arrives by email, but the work does not stop there. Someone opens the attachments, copies the important details, checks whether the request already exists, asks for missing information and updates another system.
Microsoft's documentation shows two ways this can go wrong. A shared-mailbox flow may not receive attachment content unless it is set up correctly. Microsoft also notes that its usual duplicate warning is not shown when a workflow creates the record. These examples do not tell us how often problems happen, but they show why attachments and duplicates need their own checks.
Five checks that keep the work under control
A useful workflow should make each check easy to see. Your team should know why a request stopped, what a reviewer changed and whether another system was updated.
- Check the input: make sure the email and attachment can be opened and read.
- Check the details: show what is missing instead of guessing.
- Look for duplicates: stop before creating the same record twice.
- Choose the next step: approve, ask a question, try again or send the case to a person.
- Keep a history: record the source, the checks, the review and the final update.
What the demo shows
The demo follows the main steps of a real intake workflow. It reads an email and attachment, builds a clear request, checks missing details and duplicates, previews the next update and waits for a person to approve it.
The demo uses preset examples. It is not connected to a real mailbox or customer system. A live version still needs secure access, file reading, user permissions, protected storage, failed-step retries, monitoring and a named support owner.
Decide where AI is useful and where rules are enough
If every request arrives through the same structured form, field mapping and rules may be sufficient. Consider AI interpretation when wording or document layouts vary, then validate the extracted result against the fields the next step requires.
Begin with a draft or a review queue rather than an unattended reply. Scope mailbox access, attachment formats and the destination separately; an available API or connector does not by itself establish that the complete workflow will work with your tools.
What to test before building
Choose real examples from the work your team already does. Include normal requests and difficult ones. Then answer these questions before deciding what to build.
- Which emails should the workflow handle, and who handles the rest?
- Which details must be present before the work can continue?
- How will you recognise a possible duplicate?
- Which file problems can be tried again, and which need a person?
- What can happen automatically, and what always needs approval?
- How will the team notice and fix a step that only partly succeeded?
Prepare a small email automation pilot
Bring a process description, the required output fields and a representative mix of normal and difficult requests. Agree on a private way to review anonymized examples; the public demo does not accept files or connect to your inbox.
Measure manual handling time before the pilot. During testing, record incorrect fields, missed duplicates, requests sent to review and time spent correcting outputs. Compare the complete handling effort, including review and maintenance. Any saving remains an estimate until measured on your workflow.
Apply this to one workflow
Still finding a starting point? We can help you identify opportunities. If you already have one task, use the free check or explore a scoped pilot. No files or customer data are needed for an initial inquiry.
Related guides
Sources
- Microsoft LearnDetect duplicate data so you can fix or remove it
- Microsoft LearnIssues triggering emails with attachments from shared mailbox
Sources support the specific statements linked above. They do not establish that a tool or reference workflow will fit a customer's systems and data.