The 30-day pilot pod blueprint

A pilot exists to answer one question: does this work at your volume, with your customers, against a number you agreed in advance? Most pilots fail to answer it — not because the pod underperformed, but because nobody wrote down what success meant until after the results were in.

This is the structure we use. Thirty days, because that is long enough to get past ramp and short enough that both sides stay interested.

Before day one

Four things must be agreed in writing, and none of them are negotiable afterwards:

• The baseline. What your current performance is, measured the way the pilot will be measured. Without this, month one's numbers have nothing to be compared to and the pilot becomes a matter of opinion.
• The primary metric. One. Contacts resolved per hour, qualified conversations per day, cost per handled contact — whichever actually matters to you. Secondary metrics are fine to watch; only one decides.
• The go/no-go threshold. A number, agreed by both sides, that the pilot must reach by day 30 to continue. Write down the no-go consequence too.
• The scope boundary. Which contact types, which hours, which customer segments. A pilot whose scope grows in week two cannot be compared to its own baseline.

Pod size

Small enough to fail cheaply, large enough to be real. In practice that means six to ten agents plus a dedicated team lead, and the team lead is not optional — a pilot pod supervised part-time by someone running three other campaigns tests your patience rather than the model.

Two rules that people are tempted to break:

• Do not staff the pilot with your partner's best agents. You are testing a repeatable process, and a hand-picked team produces a result that cannot be reproduced at fifty seats.
• Do not run the pilot alongside an in-house team handling the same queue unless routing is genuinely random. Cherry-picked routing invalidates the comparison in both directions.

The four weeks

Week one is training and shadowing. Expect nothing from the numbers. The useful output of week one is a list of every question the pod asked that your documentation could not answer — that list is worth keeping regardless of what happens to the pilot.

Week two is supervised live work at reduced volume. This is where undefined agent authority surfaces. Track escalations by cause, not by count.

Week three is full volume. This is your first honest data. Resist the urge to intervene; a pilot that is actively rescued in week three tells you what a rescued pilot looks like.

Week four is the measured week. Only week four counts against the go/no-go threshold, and everyone should know that from the start.

Reporting cadence

• Daily for the first two weeks: a short written note, numbers plus blockers. Fifteen minutes to write, two minutes to read.
• Weekly review call, both sides, cameras on, dashboard open. Thirty minutes.
• One mid-pilot checkpoint at day 15 with a single question on the agenda: is anything preventing week four from being a fair test? Fix those things now; after this point, changes are logged and not made.

The decision

At day 30 there are three honest outcomes, and a pilot design that only allows two is a sales process.

• Go. The threshold was met. Scale, and carry the same metric forward so the comparison survives.
• No-go with a cause. The threshold was missed and the reason is understood — documentation gaps, a bad volume assumption, a systems constraint. This is a useful result and worth what it cost.
• Extend once, briefly, and only when a specific, identified blocker cost a specific, identified amount of the measured week. Extending because the numbers were disappointing is how a pilot becomes a permanent trial nobody ever decides about.

The pilots that go badly wrong are almost never the ones that missed the number. They are the ones where no number was agreed, and the decision came down to who was more persuasive on the call.