The Inbox Triage Build Standard

1. What this standard covers

The shared accounts or admin inbox of a small business: the address on the invoices, the website and the van. Supplier invoices, quote requests, job updates, statements, remittances, complaints, spam. A trade on ServiceM8 or Simpro with a bookkeeper on Xero, a builder with a site office, a service business with one admin reading everything. If one mailbox is where the work arrives, this applies.

It sits under the paper, which argues the inbox is the job rather than an interruption to it. Two standards continue from here. A supplier invoice this standard files as evidence is what the Invoice Check standard reads next, matched against the order. The phone equivalent is the Booked After Hours standard, which holds the same line: take the message, write it once, never decide for a person.

What it does not cover. It does not classify well. Whether a build tells a statement from an invoice is the builder’s problem and the stub cannot prove it. What the stub proves is the shape: one kind, off the list, filed to a record, queued with an owner, and nothing sent without a release. A build that classifies badly but conforms still loses nothing, because the wrong kind lands in a queue a person reads. A build that classifies well and files into folders loses things every week.

What cannot meet it. A job system with no API cannot take the filing write, so on Tradify the record side of this standard cannot be met. The message can still be filed against the supplier in Xero and the job reference kept on the item, and the standard says that plainly rather than claiming a write that does not exist.

2. The objects, and what is in them

Six objects. The release is the one most builds leave out, because a reply appears to go out fine without anybody having said so. The evidence is the other, because the body text looks like enough until the bookkeeper needs the PDF.

Message                           # theirs, read from the mailbox
  - id, thread_id, from, received_at, subject, body_ref
  - hash                           # of the raw message; what quarantine files under
  - attachments[] { hash, name }

Classification
  - message_id, kind, confidence, classified_at
  - kind is one of: supplier_invoice | quote_request | job_update
      | statement | complaint | remittance | spam | other
                                   # closed. A free-text kind is a failure

Item                              # one per thread
  - id, thread_id, kind
  - record_ref (nullable)          # job:<id> or supplier:<id>; null where nothing matches a record, for spam, and for other; never null when a record matches
  - owner (a named person), due (from the kind's clock)
  - status (open | answered | escalated | quarantined)
  - message_ids[]                  # a follow-up adds to this, never a second item

Acknowledgement                   # the only automatic outbound
  - item_id, sent_at, promised_by  # "a person will reply by <promised_by>"

Release                           # a named person, never a rule
  - item_id, person, at

Evidence                          # the attachment, not the body
  - hash, message_id, record_ref

An Item whose thread already has one is the defect this standard exists to make unrepresentable: a raise with no existing id should not be possible for a thread that has one. A reply with no Release before it is the other.

3. The checks, in order

The order is the claim. The kind comes before the filing, the filing before the queue, and the queue before anything is sent, because a build that acknowledges first and files later produces a customer who was promised a reply on an item nobody owns.

1. Every message gets exactly one kind from a closed list. The kinds are supplier_invoice, quote_request, job_update, statement, complaint, remittance, spam and other. Every message gets one of those and only one. A free-text kind, or a message with two kinds or none, fails.
2. A message about a job or a supplier is filed against that record by id. The message is attached to the job or the supplier it belongs to, by the record's own id, never as a copy in a folder. A filed message with no record id fails. A message classified other may stay unfiled, but it must become a task for a person.
3. A supplier invoice attachment is filed as evidence with its hash and the message id. The attachment is the artefact, filed as evidence carrying its hash, the message id and the supplier record, so the Invoice Check standard can read it where it was filed. The body text alone is not the artefact.
4. Every classified message lands in the queue for its kind, with a named owner and a due date. Each kind has a queue, and the queue has a named owner and a response clock. The item takes the owner's name and a due date from that clock. A message with no queue, no owner or no due date fails.
5. A complaint is escalated to a named person with the full message, and nothing is sent to the customer. A complaint is never acknowledged, answered or summarised by the machine. It is handed whole to a named person, and the item is marked escalated. Any outbound on a complaint fails.
6. The only automatic outbound is an acknowledgement, and any substantive reply carries a named person's release. The machine may send one thing on its own: an acknowledgement saying a person will reply and by when. Anything that quotes a price, a date or a decision leaves only after a release event naming a person. A reply with no release fails.
7. Each kind carries a response clock, and an item past its clock escalates to the owner's manager. The clock belongs to the kind, not to whoever happens to be looking. An open item still unanswered when its clock runs out is escalated to the owner's manager, named. It never just gets older.
8. A follow-up in the same thread updates the existing item. One thread is one item. A second message in a thread the build has already raised an item for is filed to that item, and the item now carries both message ids. A second item for one thread fails.
9. Spam is filed to quarantine with its hash, retrievable, and never deleted by the machine. A message classified spam is moved to quarantine with its hash, where a person can find it. The machine never deletes a message. A message the machine trashed fails.
10. Message id, kind, record, owner, clock, what was sent and by whom are retrievable by message. When the customer says nobody answered, the record shows the message, its kind, the record it was filed to, the owner, the due date, every outbound and the person who released it.
11. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
12. The pass test passes. On the real mailbox for a week: a real supplier invoice filed as evidence against its supplier, a real complaint reaching a person untouched, a real thread of three messages held as one item, and nothing substantive sent without a release.

4. The four queues

A queue is a table with an owner’s name and a clock on every row. It is not a folder. A folder holds copies and nobody owns it; a queue holds items and somebody does. The kind “other” has a queue too, and it is the one the business should read most carefully, because it is where the classifier gave up.

5. The acknowledgement and the release

The machine may send one thing on its own: an acknowledgement that says a person will reply, and by when. The “by when” is the item’s due date, which came from the kind’s clock, so the promise is one the queue can keep. The acknowledgement has no free text in it. It cannot quote a price or a date because there is nowhere to put one.

Everything else is a substantive reply, and a substantive reply leaves only after a release event that names a person. The person writes or approves the words; the build records the release, then sends exactly those words. There is no rule with a threshold here, unlike the invoice standard, because there is no number to put a threshold on. A reply is a decision, and a decision is a person’s.

The complaint is the case that proves the gate. It gets no acknowledgement, not even the harmless one, because a cheerful automatic reply on a complaint is worse than silence. It is handed whole to a named person and the item is marked escalated. What that person says is theirs.

6. Threads, spam and the clock

One thread is one item. Before a build raises an item it reads whether the thread already has one, and a follow-up is added to that item rather than raised beside it. The pass test asks for a real thread of three messages held as one, because two items for one conversation is how a customer gets answered twice with different answers, or not at all because each item looked like somebody else’s.

Spam is filed to quarantine with its hash, where a person can find it. The machine never deletes a message, spam included, because the day the classifier calls a real remittance spam is the day the business needs to get it back. Quarantine is a queue with an owner like any other. It is just one that is read monthly rather than daily.

The clock belongs to the kind. A complaint has hours, a quote request has a day, a statement has a week, and the business sets those once. An item still open when its clock runs out is escalated to the owner’s manager by name. It does not turn red in a dashboard nobody opens; it turns up in front of a second person.

7. What stays with a person

• ✓Every substantive reply: anything with a price, a date or a decision in it. A person writes or approves the words and the release carries their name.
• ✓The complaint, whole. What is said to that customer and when.
• ✓Deciding a supplier invoice is genuine. This standard files the attachment as evidence; the Invoice Check standard matches it and a person approves it.
• ✓Reading everything the machine called other. That queue is the classifier admitting it does not know.
• ✓The queue table itself: who owns each kind and how long it may wait.

8. Provider: what to stub, and what not to hand-roll

Two steps not to hand-roll: the filing write that attaches a message to the right job or supplier by id in a system you do not own, and the release gate on every reply. There is no hosted product for either. Everything else a coding agent builds against the stub in an afternoon.

provider:
  stub:       local.mock_inbox
  production: none                       # scoped build, not a product

where the live step lands
  - Nowhere hosted. The filing write against the job or supplier record
    and the release gate are a scoped build on the mailbox and the job
    system the business already runs: a shared mailbox on Microsoft 365
    or Google Workspace, a job system with an API, Xero for suppliers.
    No tool of ours sits in the path, and this block will say so until
    one does.

stays local                          # yours, and the standard
  - the classifier, and how good it is
  - the queue table: kinds, owners, managers, clocks
  - the acknowledgement wording, minus any free text
  - reading the other queue

cannot meet the standard
  - Tradify, for the job side: no API, so no filing write against a job.
    Supplier filing in Xero and the job reference on the item is the
    honest route.

A vendor selling inbox automation is usually selling the classifier and an auto-reply. Ask them three things: where does a filed message live and under what id, what went out last week that nobody released, and where is last month's spam.

9. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Every message gets exactly one kind from a closed list. The kinds are supplier_invoice, quote_request, job_update, statement, complaint, remittance, spam and other. Every message gets one of those and only one. A free-text kind, or a message with two kinds or none, fails.
• ✓2. A message about a job or a supplier is filed against that record by id. The message is attached to the job or the supplier it belongs to, by the record's own id, never as a copy in a folder. A filed message with no record id fails. A message classified other may stay unfiled, but it must become a task for a person.
• ✓3. A supplier invoice attachment is filed as evidence with its hash and the message id. The attachment is the artefact, filed as evidence carrying its hash, the message id and the supplier record, so the Invoice Check standard can read it where it was filed. The body text alone is not the artefact.
• ✓4. Every classified message lands in the queue for its kind, with a named owner and a due date. Each kind has a queue, and the queue has a named owner and a response clock. The item takes the owner's name and a due date from that clock. A message with no queue, no owner or no due date fails.
• ✓5. A complaint is escalated to a named person with the full message, and nothing is sent to the customer. A complaint is never acknowledged, answered or summarised by the machine. It is handed whole to a named person, and the item is marked escalated. Any outbound on a complaint fails.
• ✓6. The only automatic outbound is an acknowledgement, and any substantive reply carries a named person's release. The machine may send one thing on its own: an acknowledgement saying a person will reply and by when. Anything that quotes a price, a date or a decision leaves only after a release event naming a person. A reply with no release fails.
• ✓7. Each kind carries a response clock, and an item past its clock escalates to the owner's manager. The clock belongs to the kind, not to whoever happens to be looking. An open item still unanswered when its clock runs out is escalated to the owner's manager, named. It never just gets older.
• ✓8. A follow-up in the same thread updates the existing item. One thread is one item. A second message in a thread the build has already raised an item for is filed to that item, and the item now carries both message ids. A second item for one thread fails.
• ✓9. Spam is filed to quarantine with its hash, retrievable, and never deleted by the machine. A message classified spam is moved to quarantine with its hash, where a person can find it. The machine never deletes a message. A message the machine trashed fails.
• ✓10. Message id, kind, record, owner, clock, what was sent and by whom are retrievable by message. When the customer says nobody answered, the record shows the message, its kind, the record it was filed to, the owner, the due date, every outbound and the person who released it.
• ✓11. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓12. The pass test passes. On the real mailbox for a week: a real supplier invoice filed as evidence against its supplier, a real complaint reaching a person untouched, a real thread of three messages held as one item, and nothing substantive sent without a release.