> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt > Use this file to discover all available pages before exploring further. # Inbox intake > Turn a shared mailbox into structured, worked cases — routing, attachments, special requests captured from the email body, and drafted replies behind an approval gate. ## The job `orders@` and `invoices@` are where the work actually arrives. Someone opens each message, decides whether it's an order, an inquiry, a chaser, or spam, saves the attachment, types the relevant bits into a system, and answers the sender. The important detail — "please hold this until the 15th" — is in the third paragraph of the email body, not in the attachment. This recipe turns that mailbox into a queue of worked cases, with the email body treated as part of the document rather than as a wrapper around it. ## What you'll build ``` shared mailbox ──▶ workflow trigger ──▶ Inbox Intake (reconcile table) ──▶ review │ │ └── routes ──▶ downstream └──▶ drafted reply process (approval gate) ``` * Email arrives in a monitored folder; a case is created with the body and every attachment. * The agent classifies it, extracts what the process needs, captures any special requests from the body, and either routes it onward or answers it. * Replies are drafted, never sent unapproved. ## Ingredients | | | | ------------------- | -------------------------------------------------------------------------------------- | | **Reconcile table** | `Inbox Intake` | | **Storage tables** | `customer_master` (to identify the sender), plus whatever the downstream process needs | | **Integrations** | A connected mailbox (Outlook), and outbound email for replies | | **Model tier** | **Balanced** | | **Auto Review** | Off until routing accuracy is proven — misrouting is expensive and quiet | ## Connect the mailbox Outlook connects per project. Two ways: * **Ask the agent** — "Connect my Outlook account". It returns an authentication link. * **Via Connect** — open the project's **Connect** panel and click **Connect** next to Outlook. Once authenticated, a folder named **cloudsquid\_\[projectname]** appears in the mailbox. Anything in that folder is picked up and lands in the project within seconds. **Route mail into it with a rule** rather than by hand. In Outlook: **Settings → Rules → Add new rule**, set your conditions — sender, subject keywords, has-attachment — and choose **Move to folder → cloudsquid\_\[projectname]**. You can connect as many accounts as you need; each gets its own folder. Ask the agent "What Outlook accounts are connected?" to list them, or "Disconnect my Outlook account" with the address to remove one. Prefer a rule that routes *everything* from the shared mailbox and let the SOP decide what to ignore. A too-clever Outlook rule silently drops the edge cases you most want to see. ### Via the API instead If mail reaches you another way, post it as a case with `file_type: multipart` — an RFC 822 message with its attachments as parts. The agent then sees the body and the attachments as one document. See the [async run pattern](/concepts/async-run-pattern) for the request shape. ## The starter SOP ```md theme={null} # SOP — Shared mailbox intake Version 1.0 · Owner: Order Entry · Last approved by: , ## Purpose Classify every incoming message, extract what the downstream process needs, capture anything the sender asked for in the body, and draft a reply where one is owed. Never send without approval. ## Step 1 — Identify the sender Match the sender address against `customer_master.contact_email`. - Exact match → set `customer_number`, `sender_status: known`. - Domain-only match → `sender_status: domain_only` and name the candidates. A shared domain is not an identification. - No match → `sender_status: unknown`. Continue; do not stop. ## Step 2 — Classify the message Read the body AND every attachment before deciding. Set `message_type`: - `order` — a purchase order, or a body that clearly places an order ("please send 200 units of ..."). An attached PO wins over body text. - `order_change` — references an existing order: change, cancel, chase. Extract the referenced order number. - `inquiry` — a question: price, availability, delivery date, documents. - `complaint` — something is wrong with a delivery or invoice. - `admin` — remittance advice, address change, out-of-office, receipts. - `spam` — unsolicited, no relationship to our business. - `unclear` — you cannot tell. Use this rather than guessing. Rules: - An attachment does not decide the type on its own. A signature-image PDF on a one-line question is an `inquiry`, not an `order`. - A message with both an order and a complaint is an `order` with the complaint captured in `extra_requests`. Note it in the comment. - `spam` requires no relationship AND no attachment naming us. When in doubt, `unclear`. ## Step 3 — Capture extra communication Anything the sender asks for that is not in the attachment goes into `extra_requests`, verbatim plus a one-line summary. Examples: - "Please hold shipment until the 15th" - "Deliver to the site address, not the office" - "Invoice to our new entity from January" - "Confirm by Friday or we cancel" This is the field that gets lost in manual handling. Never drop it, and never silently apply it — record it and let review decide. ## Step 4 — Route or answer - `order` → create the case in the order process, attach all files. - `order_change` → route with the referenced order number. If no order number can be found, flag: `Needs review`. - `inquiry` → draft a reply (Step 5). - `complaint` → route to the complaint queue, draft an acknowledgement, never a resolution. - `admin` → file it, no reply. - `spam` → mark and stop. No reply, no routing. - `unclear` → `Needs review` with what you read and why you could not classify it. This is a correct outcome. ## Step 5 — Draft replies Draft, never send. Every reply: - Answers only what was asked. No commitments on price, date, or availability that are not already confirmed in our data. - Quotes the order or invoice number where one exists. - Uses the language the sender wrote in. - Ends unresolved points as explicit questions rather than assumptions. Never draft a reply that confirms an order, agrees to a date, or accepts a claim. Those need a human decision, not a draft. ## Escalation — always flag - `message_type: unclear` - Attachment that cannot be opened or read - `order_change` with no resolvable order number - Any message threatening cancellation, penalty, or legal action - Sender unknown AND the message places an order ## Outputs Fill every output field. In the comment, state: how you classified it and on what evidence, what you extracted, what is in `extra_requests`, where you routed it, and whether a reply is waiting for approval. ``` ## Walkthrough Connect Outlook, then add the Outlook rule so the shared mailbox feeds the cloudsquid folder. Send yourself two or three test messages first. `Inbox Intake`, with **Output Fields**: `message_type`, `customer_number`, `sender_status`, `referenced_order_number`, `extra_requests`, `attachments_summary`, `routing_target`, `reply_draft`, `flags`. Grant **Data Access** to `customer_master`. Paste the starter SOP into `SOP.md`. Then run one real day's mail — a day you can still remember, so you can check the classifications against what actually happened. Routing accuracy is the whole game here. Check `message_type` on every case for the first few days; a misrouted order is invisible until someone chases it. ### What good looks like **A clean routed order:** > Sender [kestrel-einkauf@example.com](mailto:kestrel-einkauf@example.com) matched customer 30412 exactly. Attachment `PO-88213.pdf` is a purchase order for 6 positions. Classified `order`. Body contains one extra request: "please deliver to the Dortmund site, not the head office" — captured in `extra_requests`, not applied. Routed to Order Match with both files attached. No reply owed. **A case the agent correctly refuses to resolve:** > Message reads in full: "As discussed — the usual, but double the blue ones. Same address." No attachment. Sender [ops@example.net](mailto:ops@example.net) does not match any `contact_email`; the domain matches two customers (40118, 40233). There is no order number, no article reference, and no prior order I can read from this project. Classified `unclear`, `sender_status: domain_only`, flagged `Needs review` with both candidate customers. An agent that guessed "the usual" would be inventing an order. This one did every check available, found the ambiguity, and put a ten-second decision in front of a person. ## Iterating Intake SOPs improve fastest, because misclassifications are obvious in review. Comment with the rule: > Remittance advices from our factoring provider keep landing as `admin` and getting filed — they need to route to AP. Add a rule: remittance advice from a known factoring sender routes to AP, not filing. Then run [the improvement loop](/concepts/improvement-loop) after your first few hundred messages — classification rules are exactly the kind of thing that gets better from accumulated feedback. ## Hardening Intake classifies and routes; PO matching does the order work. Two tables, one pipeline. Drafted replies wait for approval. Once tone and accuracy are proven, narrow the gate to reply types that carry commitments. Zendesk tickets, webhooks, SharePoint drops — same table, different trigger. Post messages as `file_type: multipart` when mail reaches you another way. All addresses, customer numbers, and message contents in this cookbook are invented. Replace them with your own.