What does AI Tripled a Sales Team's Drafting Speed. Deals Still Slowed Down mean in practice?
Deals slowed down because AI tripled drafting capacity from ten to thirty proposals weekly without expanding the human review bottleneck, causing unreviewed drafts to exceed sixty documents and grow stale. As Dr. Jonah Tebaa explains, operations constraints dictate that downstream steps set total throughput. To fix this, teams must replace drafts produced per week with the proposals shipped per week metric, sort reviews by judgment requirements, pre-validate criteria, and batch review sessions.
A five-person sales engineering team can draft ten technical proposals a week and never once hear the word "bottleneck." Give the same team an AI drafting workflow that triples their output, and within three weeks the backlog passes sixty unreviewed documents, deals go stale, and the one person with sign-off authority stops answering his calendar altogether. That is the case Dr. Jonah Tebaa, Co-CEO of Webspot, uses to explain why AI adoption inside a team so often produces less improvement than the productivity numbers promise.
The team in question — an invented composite, built from patterns that recur across mid-market enterprise software sales engineering rather than from any one company — had a simple structure. Five solutions engineers wrote proposals. One principal solutions architect signed off on every one of them before it reached a prospect. Before AI entered the workflow, each engineer produced roughly two drafts a week, for a combined ten. The architect could review about nine a week, at forty minutes per proposal across six protected hours. Nine against ten is not a crisis. It is a team that has, without anyone designing it that way, matched its drafting pace to its review pace.
The constraint that was already there
Tebaa's point is that the review step was the binding constraint on this team long before AI arrived — it was just invisible, because drafting output happened to sit close enough to review capacity that neither ever waited long on the other. Operations management has a name for this: in any linked sequence of steps, exactly one step sets the ceiling for everything downstream of it, and every other step can run faster than the ceiling without changing total output at all. Give the fast steps more speed and nothing moves. Give the slow step more capacity and the whole system moves with it.
On this team, drafting was never the constraint. Review was. The team just hadn't tested that fact yet, because nothing had pushed drafting output far enough past nine or ten to expose it.
What happens when the fast step gets faster
Then it did. With AI-assisted drafting, each solutions engineer's output climbed from roughly two proposals a week to around six — a three-hundred percent jump. Team drafting capacity went from ten a week to thirty. Review capacity did not move, because review was never a drafting task to begin with. A principal architect reading a proposal is not producing prose faster or slower; he is deciding whether a technical claim will survive a customer's engineering team, whether the proposed pricing holds up against margin requirements, and whether the scope actually matches what came out of the discovery call. None of that gets faster because the draft in front of him was generated by a model instead of typed from scratch.
The gap did what unaddressed constraints do: it compounded. Within three weeks, the unreviewed queue passed sixty proposals. Sales reps, watching deals sit untouched, began going around the intake process and pinging the architect directly, which fragmented his calendar into exactly the kind of interruptions that stretch a forty-minute review well past forty minutes. Proposals that did sit in queue went stale — pricing shifted, a competitor moved, a buying window that was open when the draft was written had closed by the time anyone looked at it. The team's actual shipped output, the number that mattered to revenue, moved from ten proposals a week to about eleven. Tripling the drafting side of the workflow bought the business roughly one additional shipped proposal. Everything else the tool produced accumulated in a pile nobody had the hours to judge.
Redesigning the checkpoint instead of hiring around it
Tebaa's argument is not that the team needed a second reviewer, at least not first. Adding headcount at a broken checkpoint tends to just move the interruption problem onto two calendars instead of one. His prescription is to redesign the checkpoint itself before adding capacity to it, in four steps he applies consistently across the teams he advises:
- Sort incoming work by how much judgment it actually needs. Routine deals written on the standard paper, below a threshold the team sets in advance, go to a senior engineer working from a checklist. The architect's queue is reserved for the deals where the terms are bespoke or the contract value justifies his attention.
- Pre-validate acceptance criteria before anything reaches a human. Pricing math, mandatory clauses, and scope alignment against the discovery call are structural checks a draft has to pass before it enters any review queue — so the person reviewing it is spending time on judgment, not arithmetic a system could have caught.
- Batch review into protected blocks. Two ninety-minute sessions a week, scheduled and defended, replace ad hoc review requests that arrive by Slack message or hallway ambush. This removes the context-switching cost that was quietly inflating every forty-minute review into something longer.
- Change what gets measured. "Drafts produced per week" gets retired as the team's headline metric in favor of "proposals shipped per week" — the number that actually reflects whether the AI tool is helping revenue move or just helping a queue grow.
Only after those four changes does Tebaa add reviewer capacity — and by then, sized correctly, it takes less of it than a straightforward headcount fix would have. In the case he describes, the architect ends up handling roughly four high-value proposals a week, about two and three-quarter hours of work. The senior-engineer tier absorbs around twenty standard proposals. Total shipped output lands near twenty-four proposals a week, close to the theoretical ceiling of thirty that the AI drafting tool made possible in the first place — achieved without a new hire.
NIST's AI Risk Management Framework treats this as a governance requirement, not an optional nicety: it calls for processes for human oversight to be defined, assessed, and documented in accordance with organizational policies from the GOVERN function. Tebaa's four-step redesign is that requirement applied to one sales team's actual checkpoint.
The question to ask before the rollout, not three weeks after
The broader lesson Tebaa draws from this case is a discipline he recommends applying before any AI production tool goes live inside a team: map exactly where the human checkpoint sits today, then ask what happens to that checkpoint at three times the current volume. If the honest answer is that it holds, the rollout is safe as designed. If the honest answer is that it breaks, the checkpoint needs to be restructured before the tool ships, not three weeks into a backlog that reps are already routing around.
His framing reframes what looks like an AI adoption story into an operations story. The technology did exactly what it was supposed to do — it made drafting dramatically faster. The failure, where one occurred, was organizational: a team scaled the part of the workflow that was easy to scale and left the part that actually determined output untouched. For Tebaa, that is the pattern worth watching for in any team layering AI onto an existing process — not whether the tool works, but whether the humans downstream of it were ever going to be able to keep up.
