What shadow mode is
A parallel run. The system watches the same inbox your team watches, reads the same jobs, sees the same data — and holds zero authority. It drafts the reply it would send, the filing it would do, the chase it would start. Everything lands in a review queue. Nothing leaves the building.
It’s the difference between hiring someone and letting them sign contracts on day one. You’d never do the second with a person. Software shouldn’t get a pass because it demos well.
Week one: wrong in interesting ways
Honest expectations: the first drafts miss. The tone is too formal for customers you’ve known for years. It misreads one vendor’s bizarre invoice layout. It doesn’t know that Sheila in accounting is the real approver no matter what the org chart says.
Every miss is information, and it splits two ways. Either the system needs a rule it doesn’t have — or your documented process needs an update, because the team’s real process never quite matches the written one. Finding those seams is half the value of the exercise, and you keep that knowledge no matter what happens next.
A typical worked example: the system drafts a payment reminder for an overdue invoice, polite and correct. Your bookkeeper, meanwhile, didn’t send one — because she knows that customer pays on the first of the month, every month, and has for six years. Nothing was wrong with the draft. Something was missing from the rules: an exception that lived entirely in one person’s head. Shadow mode is how that knowledge gets out of heads and into the system before the system is allowed to act on its absence.
The org chart says one process. The inbox runs another.
Week two: convergence and the first gates
By the second week the drafts start matching what your team would have done, and the remaining disagreements become deliberate decisions instead of bugs: this exception type goes to this person; this customer always gets a personal reply; this vendor’s invoices always get a second look.
Then permissions open one gate at a time, per workflow — never globally:
- Draft only. Everything waits in the queue. (Shadow mode itself.)
- Act with approval. The system prepares the action; a person releases it.
- Act, then review. Reversible actions go through; a human reviews the log after.
- Act with audit. Routine, proven, reversible work runs on its own — every action still logged.
Some workflows never leave gate two. Customer-facing sends often shouldn’t. That’s not the system failing to graduate — that’s the gate doing its job.
“Two weeks” is the typical shape, not a stopwatch. The exit condition is convergence, not the calendar: the drafts match, the exception queue holds only genuine exceptions, and the disagreements that remain are documented decisions. A messy inbox can take longer. A clean, narrow workflow can graduate faster. Either way, the evidence decides — not the kickoff schedule.
What you see the whole time
Proof, side by side: here’s what your team did, here’s what the system drafted, here’s where they differed and why. Not a dashboard of green lights — actual examples you can read. The exact review cadence lives in your statement of work, where commitments belong.
The numbers stay honest too. “Ninety-five percent match” means nothing without knowing what the other five percent were — five trivial formatting differences is a pass, one wrong customer promise is not. So the review leads with the misses, not the match rate.
At the end you make a real decision with real evidence: expand the workflow, adjust it, or stop. Stopping is a legitimate outcome — better to learn it in shadow than in production.
What shadow mode needs from you
Less than you’d think. Read-only access to the systems the workflow touches. A point person who can answer “why did your team handle it that way?” in a sentence or two, a few times a week. And two weeks of patience while nothing visibly changes — the work is happening in the comparison, not on the surface.
What it does not need: polished process documentation. Don’t write any for us. The gap between what would have been written and what actually happens is the most useful thing shadow mode finds, and pre-written docs just paper over it.
Why we won’t skip it
There is always pressure to turn it on after a strong demo and a long week. But skipping shadow mode means testing in production, on customers, with the business name on the emails. The review gate stays in place even when the launch team is eager to move faster.
A useful disagreement has a label
Not every difference between the system and the team means the same thing. Some are harmless preferences: a subject line, a greeting, the order of two sentences. Some reveal missing context, such as a special customer term that lives only in one person’s memory. Others expose a dangerous boundary, like a draft that assumes approval or treats an ambiguous date as settled.
Labeling those disagreements turns review into engineering. Preferences can become style rules. Missing context can become a field, lookup, or documented exception. Boundary failures can tighten the gate or remove an action from the workflow entirely. Without labels, the team merely edits drafts and hopes they improve. With labels, each correction changes a specific part of the system and leaves a reason the next reviewer can understand.