Emailed orders, into the ERP, without the retyping.
Orders do not arrive as data. They arrive as a PDF attached to an email, and someone retypes them into the ERP.
The pattern is the same in every distributor and wholesaler we look at. A shared orders@ mailbox fills up with purchase orders and quote requests: each one a PDF or a spreadsheet, each one laid out differently, each one from a customer whose part numbering does not match yours. Somebody opens it, finds the customer, looks up every line, checks stock and price, and types the order into the ERP by hand. Then they reply to confirm.
The ERP is not the problem. It is a SQL Server database on a server in your building, it works, and it is not moving. The mailbox is not the problem either. The cost sits in the human bridge between them, and that bridge is staffed all day.
- Orders wait in a queue. An order that lands at 16:40 gets keyed tomorrow, and the customer hears nothing tonight.
- Keying errors reach the warehouse. A transposed quantity or the wrong pack size becomes a credit note and a return.
- Exceptions are invisible. Nobody spots that a line is discontinued, priced off an expired quote, or over the customer's credit limit until it is already picked.
- Nobody can answer the simple question. "What is on order for this customer right now?" needs someone to open the ERP and run a query.
// the work is not deciding — it is reading, looking up, and typing. That part is automatable.
Amazon Quick sits between the mailbox and the ERP. It reads the order, checks it against live ERP data, writes it back, and drafts the reply — and a person still approves anything that matters.
your existing systems
- outlook
orders@ - onedrive documents
- sql server erp (on-prem)
amazon quick
- Quick Automate process
- connectors: outlook · onedrive
- MCP actions → ERP
- chat agent + Quick Sight
what comes out
- order written to the ERP
- confirmation or exception reply
- an order book you can ask
// the ERP keeps its schema, its server, and its network. Quick reaches it over a private path, not the public internet.
// illustrative, modelled at roughly 400 emailed orders a month averaging 6 lines each. Not measured client figures.
This is the part worth understanding. The model does not just summarise the email — it calls tools that read and write your ERP, and every one of those tools is something your administrator defined and switched on.
Read the order out of the email
every mail toorders@ · real-timeBefore: a person opens the attachment and reads it. After: the process starts itself, files the document, and turns the PDF into structured lines.
The Microsoft Outlook connector reaches the mailbox through the Microsoft Graph API. For an unattended process this is configured with service-to-service OAuth — client credentials, application permissions, no signed-in user to depend on — so intake keeps running at 02:00 and does not break when a member of staff changes their password. The attachment is filed to OneDrive through the OneDrive connector, and the agent extracts the customer, the reference, the delivery date, and every line: part, description, quantity, unit, price.
A representative run: a 6-line order as a scanned PDF, from a customer who writes their own part codes and abbreviates units. Extracted to structured lines with the customer's codes preserved alongside the ERP's, and a note that line 4's unit is ambiguous — CS could be case or carton.
Check it against the live ERP
per order line · before anything is writtenBefore: a person looks up each line in the ERP and squints at the customer's price list. After: the agent calls a tool per check and gets the same answers, from the same database, in one pass.
This is where an agent differs from a chatbot. The ERP is exposed to Quick as a set of MCP tools — resolve_customer, match_part, check_stock, get_contract_price, check_credit — each one a narrow, named operation with a declared input schema, not open SQL access. Quick registers each tool as an action it can invoke, and the model chooses which to call and with what arguments. Nothing is invented: every quantity, price, and stock figure in the result came back from your SQL Server.
A representative run: 5 of 6 lines matched and in stock; line 3's part is discontinued with a successor part suggested by the ERP; the contract price on line 5 is 4% below the customer's current agreement because their PO quotes an expired quote number; the order total keeps the account inside its credit limit.
Write the order back — or raise the exception
on a clean order · human approval on anything flaggedBefore: the order is typed into the ERP, twice if it is urgent. After: a clean order is written straight through; a flagged one is queued for a person with the reasoning attached.
A create_order tool writes the header and lines through the ERP's own stored procedures, so its validation, numbering, and audit trail still apply — Quick never writes to tables directly. Clean orders go through. Anything the checks flagged goes to a person with the extracted data, the ERP's answer, and a draft reply, so the decision takes seconds instead of a fresh investigation. Quick Automate handles this queue as case management with retries and error branches, which is the difference between it and a simple flow.
A representative run: lines 1, 2, 4, 5, 6 written as order SO-118422; line 3 held as an exception with the successor part and a draft email asking the customer to confirm the substitution. The confirmation email goes out only after a human approves it.
Let the team ask the order book
on demand · in Quick or in OutlookBefore: somebody runs a query, or asks the person who can. After: the question is asked in English and answered from the same live data.
The same ERP connection backs a Quick chat agent, so sales can ask "what is open for this account, and what is late?" and get an answer from the database rather than from a stale export. Quick Sight covers the dashboard side of that data, and the Amazon Quick extension for Outlook puts the agent in the side panel next to the email being answered — with the OneDrive knowledge base indexing the order documents themselves, so the terms in a signed PO are searchable too.
A representative run: "anything for this customer stuck for more than five days?" returns two orders, the reason each is held, and a drafted chase email — composed in the Outlook side panel, on the thread it belongs to.
Three systems, four mechanisms. Reading your ERP and writing to it are deliberately not the same path.
| system | mechanism | direction |
|---|---|---|
Outlook orders@ | Microsoft Outlook connector, Microsoft Graph API, service-to-service OAuth for unattended runs | read mail · send reply |
| OneDrive | OneDrive connector for files and folders; knowledge base indexing for search, with admin-managed service credentials preserving document-level access control | file · index · search |
| SQL Server — reporting | Quick Sight data source over a VPC connection: a private network path, requiring a resolvable DNS name and a traceable route to the private IP | read |
| SQL Server — actions | MCP action connector: a remote MCP server you host, exposing named tools that call the ERP's stored procedures | read · write |
// on-prem means the private path terminates in your VPC and continues over Direct Connect or a site-to-site VPN. The database keeps its private address; nothing is published.
Three pieces of Amazon Quick do the work. Here is what each one is for.
Quick Automate
Amazon's option for centralised, enterprise-wide automation: long-running, high-volume processes that run independently of any individual user, with control flow, case management, error handling, and custom code. Order intake is exactly its shape. Its lighter sibling, Quick Flows, is for personal and team tasks — useful here for the ad-hoc jobs around the process, not the process itself.
MCP action connectors
Model Context Protocol is the open standard for letting an AI system call your tools. You host a remote MCP server; Quick connects as the client, discovers the tools it exposes, and registers each one as an action its agents can invoke. This is how a language model gets to act on your ERP with your authentication and your authorisation, rather than being handed a database password.
Connectors & M365 extensions
First-party connectors for Outlook and OneDrive, running over Microsoft Graph, with a choice of the AWS-managed OAuth app, your own app registered in Microsoft Entra, or service-to-service credentials for unattended work. The Quick extensions put the same agent inside Word, Excel, PowerPoint, and Outlook, so nobody has to adopt a new application. On the read side, Quick Sight takes the ERP over the private VPC connection for dashboards and datasets, and a knowledge base indexes the order documents themselves.
services involved: business process automation · ai · aws
An agent that can write to your ERP is a real permission. It should be a narrow one.
- Tools do not switch themselves on. Quick discovers what an MCP server exposes, then lists each tool as an action for review — an administrator turns it on deliberately. Each connector carries separate permissions for creating, sharing, and using an action.
- Narrow tools, not open SQL. Every ERP operation is a named tool with a declared schema, writing through existing stored procedures. There is no free-form query path, so the model cannot reach a table nobody meant to expose.
- A human approves anything flagged. Substitutions, price mismatches, credit holds, and low-confidence extractions queue for a person. When output cannot be parsed, the order is escalated, never silently dropped.
- The private path stays private. The ERP is reached over a VPC connection; traffic stays off the public internet, and a private MCP server can sit behind that same connection.
- Enterprise prerequisites are real. MCP integrations and VPC connections require an Enterprise subscription, and only remote MCP servers are supported — local stdio connections are not. Worth knowing before the design, not after.
- Trust is your call, not the platform's. AWS is explicit that it does not evaluate the trustworthiness of a third-party MCP server or the behaviour of the tools it exposes. That is why, in this build, the only MCP server touching the ERP is one written for it and hosted in your account.