
Bev has run the production desk at Thimble & Rye, a made-up promo decorator, for nineteen years. On Monday at 8:40 she hands her manager, Theo, a letter. She is giving two weeks' notice. She is moving near a lake and plans, in her words, to never look at a ship date again.
Theo reads the letter twice. Then he looks at the rush board. Every week, a few rush orders get bumped and a few don't, and Bev decides which. Nobody else has ever been quite sure how. Asked directly, Bev says she "just knows," which is true and not much help.
By lunch, Theo has found most of her system. Some of it lives in the scheduling tool. Some lives on four sticky notes around her monitor, one of which says "NEVER bump the hospital account" and another "Hospital account can wait (Q4 only)." The rest lives in a spreadsheet tab called DO NOT TOUCH and in Bev's memory of a 2019 incident involving a sports team and a pallet of foam fingers.
Theo had planned to automate rush triage this quarter. He now realizes the agent would need to know what Bev knows, and Bev has ten working days left. The people and company here are made up, but the deadline probably feels familiar. Before an agent can follow your rules, someone has to write them down.
Document the decisions that connect an order's facts to an action: the approved information source, the rule, the permitted outcome, and the condition that requires a person. An AI agent should not have to infer unwritten rush-order, pricing, or product-variant policies from unrelated examples.
Start with one real process owner and a narrow workflow. The objective is an instruction another qualified operator can follow and test, rather than a long prompt that only its author understands.
Observe decisions while work is happening
Start with a small set of recent orders. Sit with the person who completed them and replay the steps.
Ask what they looked at, what alternatives they rejected, and what would have changed their decision. "I chose the usual item" is a prompt to investigate which customer, product, or decoration conditions make that item usual.
Pay particular attention to workarounds. A sticky note beside the monitor, a spreadsheet of customer aliases, and a call to production may contain more useful process information than the formal training manual.
Capture the reasoning in plain language without turning every habit into a rule. Some habits reflect an old limitation or a personal preference. Confirm with the process owner which decisions the business actually wants repeated.
Theo starts on Tuesday. He pulls five orders Bev handled last week and asks her to walk him through them. By the third order she has said "obviously" eleven times, and each "obviously" turns out to be hiding a rule. Some of those rules the business wants to keep. One of them exists because a heat press broke in 2017 and was replaced in 2018.
Separate facts from decisions
An order may contain a requested delivery date, but that does not establish whether production can meet it. A price printed on a PO does not necessarily establish the approved selling price. A product name that resembles an existing item does not prove it is the right variant.
For each step, identify the source of the fact and the rule applied to it. For example: retrieve the approved quote, compare the line-item amount, and route a mismatch to the account owner.
This separation makes a process easier to maintain. If the pricing policy changes, you can update the decision rule without changing where the quote comes from. It also makes mistakes easier to diagnose: was the source wrong, the lookup wrong, or the rule wrong?
Turn vague instructions into testable conditions
"Handle rush orders carefully" expresses an intention. It does not tell an agent what to do. A stronger instruction might say:
If the requested ship date is earlier than the date on the approved production schedule, prepare a capacity-check request for the production lead. Do not confirm an earlier date to the customer.
The precise rule will depend on the company. What matters is that someone can test it and agree whether the resulting action is correct.
Use the same approach for additional charges. Identify the conditions that trigger hangtagging, private labeling, setup, or special packaging fees; specify the approved price source; and say who decides when a case is not listed. Avoid asking the model to infer a charge from an unrelated historical order.
A worked rule record for a rush request
Use this proposed record to make a rule testable. The example follows one made-up rush request:
Example rule record: rush request
Input
a PO requests shipment on Thursday; the approved production schedule currently shows Friday.
Approved source
the current schedule for this order, with its date, time, and owner.
Decision
the requested date precedes the approved date.
Permitted action
draft a capacity-check request for the production lead, including both dates.
Stop condition
do not confirm Thursday to the customer until the authorized person approves a revised plan.
Test the opposite case too: a Thursday request against an approved Wednesday ship date should not trigger the same exception solely because the dates differ. Real policies may also depend on delivery commitments, transit time, and production constraints.
The EPA's 2007 guidance on standard operating procedures (SOPs), sections 2.1–2.3 recommends preparation by knowledgeable staff, review by qualified people, and updating changed procedures. Those are transferable documentation practices; this article is not applying environmental regulations to a promo business.
Keep judgment calls visible
Some decisions should remain with people. A commercially important exception may depend on a customer relationship, a production negotiation, or information that the system cannot access.
Document the handoff rather than pretending the uncertainty has disappeared. The agent can assemble the relevant order, the conflicting facts, and the question that needs a decision. A useful handoff is specific:
The PO requests Friday delivery, but the approved schedule shows Monday shipment. Please confirm the revised plan.
A generic "something went wrong" gives the operator another investigation to perform. Also define what happens after the person answers. The workflow should record the decision with the relevant order and resume from a known step, not start over and risk repeating earlier actions.
By the end of the first week, the hospital-account sticky note has become two written rules and one question. The question goes to the account owner, because it depends on a customer relationship and not on anything in the schedule. Bev reads the finished rules and says they are "basically right," which from Bev is a standing ovation.
Use a compact instruction record
The rush-order record above follows a general pattern. For each meaningful decision, record:
- The input or event that triggers it.
- The approved source of the required information.
- The conditions that lead to each outcome.
- The permitted action and the person responsible.
- An example that passes and an example that must stop.
Add a rule owner and a review date. These details can live in the documentation system the team already uses; creating another elaborate repository is unnecessary if no one will maintain it.
Keep related examples together. A corrected order should become a test case, with a short explanation of why the correction was necessary. Over time, that collection becomes a practical record of the business's operating knowledge.
Test the instructions with another person
Before asking an agent to follow the instructions, give them to a colleague who did not write them. Ask that person to process a sample order without help.
Every question they ask is useful. It exposes a missing definition, a hidden source, or an instruction that depends on context the writer assumed was obvious.
Then test the automated workflow on the same cases. Compare decisions, not just whether the final screen looks plausible. Check charges, variants, dates, attachments, and the places where the workflow correctly stopped.
Where to start
The goal is to make routine decisions repeatable and exceptional decisions easy to find, without pretending every exception can be eliminated. Start with one difficult order your best operator handled this week, and write down what they knew that the order itself did not say.
Limits of this guidance
Example only
The example is an example rule pattern, not a customer SOP. The process owner must supply the actual scheduling, price, charge, and approval policy.
Bev's last day
On Bev's last Friday, Theo hands a sample rush order to Claire, who joined in the spring and has never touched the rush board. Claire works through it using only the written records. She asks three questions. Bev answers all three, and Theo adds each answer to the records with an example that passes and one that must stop.
Then Bev takes down her sticky notes and offers them to Theo as a keepsake. He photographs them, files the photo next to the rule records, and lets her take the originals to the lake. Nobody at Thimble & Rye believes they now know everything Bev knew. They do know which decisions are written down, which ones still need a person, and who that person is on Monday.

Ritanshu Dokania
Co-Founder
Get started
Ready to see Trelium in action?
Schedule a 30-minute conversation about the workflow you want Trelium to handle.
Talk to a Human→



