Inbox intake

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 for the request shape.

The starter SOP

# SOP — Shared mailbox intake

Version 1.0 · Owner: Order Entry · Last approved by: <name>, <date>

## 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 the mailbox and route mail into it

Connect Outlook, then add the Outlook rule so the shared mailbox feeds the cloudsquid folder. Send yourself two or three test messages first.

Create the reconcile table

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.

Add the SOP and run a real day

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.

Review classification before anything else

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 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 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 after your first few hundred messages — classification rules are exactly the kind of thing that gets better from accumulated feedback.

Hardening

Feed the order process

Intake classifies and routes; PO matching does the order work. Two tables, one pipeline.

Reply approval gate

Drafted replies wait for approval. Once tone and accuracy are proven, narrow the gate to reply types that carry commitments.

Other intake channels

Zendesk tickets, webhooks, SharePoint drops — same table, different trigger.

API intake

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.

Getting started

Core concepts

Cookbooks

More guides

The job

What you’ll build

Ingredients

Connect the mailbox

Via the API instead

The starter SOP

Walkthrough

What good looks like

Iterating

Hardening

Feed the order process

Reply approval gate

Other intake channels

API intake

​The job

​What you’ll build

​Ingredients

​Connect the mailbox

​Via the API instead

​The starter SOP

​Walkthrough

​What good looks like

​Iterating

​Hardening

Feed the order process

Reply approval gate

Other intake channels

API intake

The job

What you’ll build

Ingredients

Connect the mailbox

Via the API instead

The starter SOP

Walkthrough

What good looks like

Iterating

Hardening