SME collaboration, reconsidered

Forty-eight percent of proposal teams have named SME collaboration as their top challenge. That number has held steady for five consecutive years, through a major shift in proposal tooling, through the rise of generative AI, through three different waves of “the future of work.” The number does not move.

That is the most important fact in the proposal industry, and the industry has spent five years trying to solve it with better communication. Better project management. Better Slack integrations. Better calendar tooling. Better async writeups. Templates, dashboards, kickoff meetings, status standups. None of it has moved the number.

This is the canonical version of the argument I have been making in field notes all year. The argument: every playbook that attacks the SME bottleneck via better communication misses the point. The real problem is the economic tradeoff the SME is facing, and any solution that does not change that tradeoff fails. There are three patterns that partially change it. There is one that fully changes it. Even that one breaks under specific conditions, and the breaking matters. The piece is structured around all of that.

The economic frame

A subject-matter expert at the kind of company that responds to RFPs is one of three things: a senior engineer, a senior security or compliance person, or a senior commercial-finance lead. Sometimes they are a product manager. Sometimes they are a customer-success lead with deep technical context. The common thread is that their time is the company’s most expensive minutes, and the company has built incentive structures around using those minutes on revenue-producing work — billable engagements, customer-retention escalations, strategic build, or board-relevant analysis.

Proposal work is not on the list of revenue-producing work most companies have built incentives around. It is treated as overhead. The SME’s quarterly review does not include a line for “supported five RFP responses.” Their bonus does not move when a bid wins; their bonus is tied to the products they build or the deals they close, not the deals their colleagues close on behalf of the company. The relationship between proposal work and the SME’s career trajectory is, in most companies, indirect to the point of invisibility.

This is the entire problem. The SME is making a rational tradeoff. They are asked to spend an hour on a proposal question. The hour costs them: it is an hour not spent on the work their performance review covers. The hour gives them: the warm feeling of being a good colleague, plus a small amount of credit if anyone bothers to track it, which mostly they do not. They put it off. They half-do it. They write a paragraph that is technically true but that the writer has to re-write to be useful. They miss the deadline. They blame their calendar. They are not lying about their calendar.

Quilt has documented that sales engineers spend 100 to 300 hours per RFP response — 12 to 37 full workdays per deal. That number is the visible cost. The invisible cost is the strategic work those workdays did not happen on, and the SME’s growing resentment of a function that competes with the work that pays them.

Any solution to SME collaboration has to face this tradeoff directly. A solution that says “we will give the SME a better way to enter their answer” has not changed the tradeoff. A solution that says “we will only ask the SME on questions where their judgment is genuinely required” has changed it. A solution that says “we will preserve the SME’s answers across many proposals so they only answer once” has changed it more.

This is the frame. Everything below is variations on whether a given pattern actually changes the tradeoff or only pretends to.

The three patterns that partially work

There are roughly three categories of solution that have been tried in the industry, with varying degrees of success. None of them fully solves the problem. All of them help.

The ticket model

The first pattern is to treat SME asks as tickets, with SLAs, capped batch sizes, and a structured queue. The proposal manager does not Slack the SME randomly. They open a ticket per question, assign it, set a deadline derived from the proposal’s timeline, and let the SME work the queue at their own cadence.

Lohfeld Consulting has argued that proposal managers spend more time chasing SME responses than building strategy, and the ticket model is the institutional response — make the chasing structured so it can be delegated and audited.

This works. It is the table-stakes practice for any team beyond a certain scale. It works because it gives the SME predictability — they know what is in their queue, they know when each thing is due, they can batch. It also gives the proposal manager visibility — open tickets, missed SLAs, concentration on specific SMEs.

What it does not do is change the underlying economic tradeoff. The SME still has to spend their hour. The ticket is just a more orderly way to ask. Teams that adopt the ticket model see SME response time tighten by maybe 20 to 30%. They do not see the SME bottleneck disappear. The Qorus 48% number sits in the ticket-using teams as well as the non-using teams.

The ticket model is necessary. It is not sufficient.

The reviewer model

The second pattern flips who writes. Instead of the SME drafting from scratch, the proposal writer drafts from the SME’s existing material — past responses, internal documentation, recorded interviews — and the SME’s role becomes review and approval, not authorship.

This is a meaningful shift. Reviewing a draft takes a fraction of the time that drafting from a blank page takes. An SME who would take 90 minutes to write a 400-word answer can review and edit a writer-drafted version in 15 minutes. The economic tradeoff has changed: the SME is being asked for 15 minutes, not 90.

The reviewer model is what mature proposal shops aim for. It is also what the eight-stage RFP pipeline post named under the Draft stage: “writers draft from a knowledge base of approved, citable content blocks. SMEs are asked to review and approve a draft, not write from scratch.”

What the reviewer model needs to work: a knowledge base mature enough that the writer has source material to draft from. A junior writer with no KB and a senior SME on the other end of a Slack message is back to the original problem — the SME ends up writing it themselves because the draft was too thin to review productively. The reviewer model is downstream of having a real KB. Teams that try to start with the reviewer model and skip the KB-building step bounce off it.

The reviewer model partially solves the problem. It compresses SME time-per-question. It does not solve the question of whether the SME has to be involved at all on this specific question. Many questions in a proposal genuinely do not need the SME — the answer is already in the KB and has not changed since the last time it was reviewed.

The content-reuse model

The third pattern says: the SME writes an answer once. The KB stores it, versions it, and tracks its freshness. On the next proposal, the writer pulls the existing block, the system checks freshness, and if the block is current, the answer ships without the SME being asked at all.

This is the model that approaches a real change in the economic tradeoff. The SME is asked once, on a question they are genuinely the right person for, and their answer becomes durable content that the company gets to use across many bids. The 90 minutes the SME spent writing an answer for one RFP gets amortized across 10 future RFPs that reuse the answer.

The math: an SME who writes a 400-word answer in 90 minutes once and then reviews-and-approves that answer for 30 minutes once a year, across 10 reuses in that year, has spent 120 minutes total. The team’s writers have collectively saved 30 SME interactions of 90 minutes each. The aggregate SME burden against this question dropped from 2,700 minutes to 120. The economics are different by an order of magnitude.

The content-reuse model is what the rising tier of grounded-AI proposal tools is structured around. The reason the model can produce this 10x savings is not that the AI is doing magic; it is that the SME’s prior work is being preserved instead of re-elicited. The AI is the retrieval and drafting layer. The SME-time savings come from the KB, not from the model.

The one pattern that fully works

The pattern that fully works — and “fully” is doing some work in that sentence; we will get to its limits — is the content-reuse model with explicit freshness discipline.

Content reuse without freshness discipline is the trap. The autorfp.ai summary of Loopio reviews names this exact failure: a content library that goes stale becomes “an overpriced document repository,” and the AI on top of it surfaces outdated answers that the team ships and loses deals on. The SME’s prior work is preserved, but it is preserved indefinitely, including past the point where it is true. The result is content reuse generating false confidence, which is worse than no content reuse.

Freshness discipline is the part that makes content reuse actually work. Specifically:

Every block has a last-verified date. Not a creation date, a verification date. The verification date answers “when did a competent human last confirm this is still true.” A two-year-old block that has not been re-verified is not a usable block.

Time-bounded facts are flagged automatically. A block that says “we maintain SOC 2 Type II certification, audit period 2024-Q2 through 2025-Q2” has a date in it. The system can compute when that audit period ends. It flags the block before the period expires. The SME is asked to review just-this-block, just-because-it-is-aging, with the existing answer pre-loaded for them to update or confirm.

Ownership is per-block. Each block has an owner — the SME whose name is attached. When the SME leaves the company, every block they own gets flagged orphan, and the orphan list is part of the KB owner’s quarterly review. We covered the implementation in the per-block permissions changelog and the content-block versioning post.

Usage telemetry as a freshness signal. A block that has been used in 8 proposals in the last quarter is a high-confidence block; a block that has not been touched in 18 months is suspicious. The KB owner sees both. The retrieval system weights blocks by freshness as well as by similarity.

When all four are in place, the SME is asked exactly twice on a typical question across a year: once to author the canonical answer, once to review it during a freshness pass. Compared to the historical pattern of being asked on every proposal that touches the question — sometimes 10 to 30 times a year for a popular question — the workload reduction is structural.

This is what I mean when I say the model fully works. It does not eliminate SME time; it concentrates SME time on the moments where the SME genuinely adds value. The SME writes the answer once on the bid where they had to. The SME re-reviews when the world has changed. They do not write the same paragraph 14 times.

The compounding thesis underlying this — every proposal you ship makes the next one easier — is mechanical, not aspirational. It works exactly because the SME’s prior work is preserved and trusted across bids. If the preservation is clean, the compounding is real. If it is not, the compounding is marketing copy.

What breaks this

Three things break the content-reuse-with-freshness pattern. Each one is real, each one happens, and each one needs a specific operational answer.

Stale KBs. The pattern breaks when the freshness discipline is talked about but not enforced. A team that buys a tool with freshness scoring and then never staffs the freshness reviews ends up with a tool reporting that everything is current because no human has flagged anything as stale, while the underlying content drifts further from reality every month. The autorfp.ai reviews are full of this. The fix is operational: a calendared content-health sweep, not a software setting.

SMEs who will not review. Some SMEs, faced with even the once-a-quarter freshness review, will not engage. They ignore the ticket. They mark it complete without reading. They delegate to a junior who lacks the context. This is the case where the underlying economic tradeoff — proposal work does not pay — is so unfavorable that even the small ask gets refused. The fix is structural: senior leadership has to actually credit proposal-related KB work in performance reviews, comp, or visibility. If they do not, no software pattern fixes it.

Genuinely new questions. A buyer asks something nobody has been asked before. The KB has nothing. The SME has to write from scratch, and there is no prior block to amortize against. This is the case where the model produces no time savings. The mitigation is honesty: not every bid is going to be a 90% reuse bid. Some bids have a high net-new content fraction, and those bids legitimately consume SME time. The point is that they are the exception, not the steady state.

The 1up.ai team has written that “most questionnaires are quite similar, but just different enough that you can’t copy/paste every answer.” That sentence is the whole truth in compressed form. The questionnaires are similar enough that reuse with intelligent retrieval works. They are different enough that pure copy-paste does not. The KB has to be smart, and the SME has to be involved on the difference, not on the similarity.

What the tooling actually has to do

If you accept the frame above — the problem is economic, the only structural fix is content reuse with freshness, and three things break the structural fix — then the tooling job is specific.

Freshness scoring. Not as a vanity number. As an operational signal that drives the workflow. A block whose freshness score has dropped below threshold should produce a ticket in the SME’s queue, not a quiet flag in the dashboard the KB owner forgets to look at.

Ownership per block, with automatic transitions. When an SME leaves the company, the system needs to know. When a block changes ownership, the new owner needs to be notified and asked to re-review the block they have just inherited. We covered the mechanics in the per-block permissions post.

Review workflows that match SME availability. A 30-minute weekly review block on the SME’s calendar, where the system batches the most-overdue blocks for them to clear, is a different ask than “drop everything and answer this RFP question.” The system should support both, and prefer the former.

Retrieval that respects freshness. A block that is technically the best semantic match but was last verified 18 months ago should rank lower than a block that is a slightly worse semantic match but was verified two months ago. We have not perfectly tuned this; it is in the retrieval-eval pillar backlog.

Refusal on uncited or stale content. If the system cannot ground an answer in current KB content, it should refuse to draft, not generate a plausible answer from training data. Refusal is a feature. We covered why in the grounded-AI pledge in code and the hallucination monitoring post.

Diff against the buyer’s prior responses. When the same buyer comes back next year with the same DDQ, the team should be re-reviewing only the answers that changed since last submission. This is mechanical and concrete. The platform that requires the team to re-answer 200 questions when 188 of them are unchanged is the platform burning SME minutes that could be saved by software. Diffing against prior submissions is not exotic; it is bookkeeping.

Per-question evidence trails. When the SME approves a block, the approval should carry forward through every reuse — with the SME’s name, the date, and a pointer to the source documents that were attached at the time. Reviewers in subsequent bids can see who signed off and when. The SME does not have to re-justify their answer to the next reviewer who happens to read it.

What the tooling does not have to do, and what most of the category has been doing instead, is “better communication.” Better Slack bots, better calendar integrations, better @-mention notifications. These help at the margin and do not change the steady-state. The 48% number does not move because of better notifications. It moves when SMEs are actually being asked less.

Closing

Five years of unchanged numbers is the industry telling itself something. The thing it is telling itself is that the bottleneck is structural, not communication-shaped, and the solutions that have not changed the structure have not changed the bottleneck. Content reuse with freshness discipline is the one pattern that has the right shape. It works when it is implemented seriously and breaks when it is implemented as a feature checkbox.

The earlier posts in this series — stop CCing your SMEs, stop CCing your SMEs, part two, shadow SMEs belong on the invite, and the SME Slack bot architecture — covered tactical pieces. The eight-stage RFP pipeline post is the systemic frame. This piece is the synthesis.

I think the next 18 months will produce a generation of proposal tooling that takes the freshness-and-ownership frame seriously. I also think much of what is sold as “AI-powered” will continue to ship without that discipline and continue to underperform on the 48% number. The buyers who can tell the difference will get a real productivity gain. The buyers who can’t will get an expensive document repository.

I would rather be wrong about that prediction than right. If the category as a whole moves the 48% in the next five years, I will write a post titled “I was wrong about how slowly this would move,” and I will be glad to write it.