SME collaboration is a UI problem
An opinion piece. Why 48% of teams still cite SME wrangling as their #1 problem after five years of vendor promises — and why the answer is not another tool but a better surface for the SME.
This is an opinion piece. The opinion: the SME bottleneck is not a workflow problem and it is not a tooling-coverage problem. It is a UI problem, and the entire category has been treating it as the wrong category of problem for a decade.
The data first. Qorus’s research, now in its fifth consecutive year, reports that 48% of proposal teams cite SME collaboration as their top challenge. Five years. The number does not move. Lohfeld Consulting calls the same thing the single most fixable problem in a proposal shop — proposal managers spending more time chasing SMEs than building strategy. Quilt’s bottleneck research puts SE time per RFP at 100 to 300 hours.
If a category has had the same dominant problem for half a decade, the category is missing something basic. My argument: what’s missing is treating the SME as the user the surface is built for.
What the category has done so far
Look at the SME features incumbents ship. Loopio, Responsive, Qvidian, QorusDocs, the post-2023 AI entrants — all of them. The features fall into three buckets:
Assignment and tracking. Tickets, statuses, dashboards, reminder emails. The proposal manager assigns a question to an SME and the system tracks whether the SME responded. This is the “task management” framing of the SME problem. The framing assumes the SME is fundamentally a worker who needs to be coordinated.
Content libraries the SME can browse. A KB the SME logs into to find the prior answer to a similar question. The framing assumes the SME is fundamentally a researcher who needs better search.
AI assistants for the SME. A bot that suggests an answer the SME edits. The framing assumes the SME is fundamentally a writer who needs faster generation.
All three framings are wrong, in the same way. They assume the SME is a participant in the proposal workflow whose job is to contribute to a response. The reality is the opposite: the SME is a domain expert whose job is something else, and the proposal team is interrupting them to extract knowledge they have. The interruption is the cost. The cost is what every “SME feature” ignores.
The interruption cost is the bottleneck
A senior security engineer’s calendar is fragmented. They have on-call rotations, design reviews, incident response, mentoring, code review. A proposal question lands in their queue and competes with all of those. The proposal question wins exactly when answering it is cheap and loses every other time.
Cheapness, in the SME’s frame of reference, is not “the tool is intuitive” or “the assignment is well-tagged.” Cheapness is “answering this question takes me less than two minutes between meetings.” If the answer requires logging into a tool the engineer doesn’t use, parsing a context that hasn’t been pre-built, and writing the response from scratch — the question is not cheap, and the question gets deferred.
Every “SME feature” that exists today fails this test in one of two ways. Either it requires the SME to log into the proposal tool (which they don’t otherwise use), or it requires the SME to do the synthesis work that the proposal manager’s draft packet should have done in advance.
What the UI has to do
The SME’s surface should look like the SME’s existing workflow, not like a proposal tool. For most SMEs we work with, that surface is Slack, Teams, or email — wherever they already are. The interaction has to be:
- Async (no scheduled meeting required).
- One question at a time (no list of 20 questions).
- Pre-contextualized (a draft packet that gives the SME enough scaffolding to write two minutes of input, not 30).
- Verbatim-respected (whatever the SME types is what gets written back, not “summarized” by a bot).
- Trackable but not nagging (the proposal manager sees the missed SLA; the SME does not get a reminder ping).
This is the design we landed on for the SME Slack bot and the draft packet we’re publishing this week. Neither is a heroic feature. The argument is that the combination — putting the question on the SME’s home turf with enough context that answering it is fast — is the fix the category has been missing.
What we’re not claiming
I am not claiming this is the only thing that matters. SMEs are also slow because the proposal questions are sometimes badly framed (see the second-question rule). They are slow because deadlines arrive late (see the eight-stage RFP pipeline on intake hygiene). They are slow because the proposal team treats them as a labor pool instead of as a knowledge source.
But the category-level pattern is consistent. Every “SME productivity feature” that ships into a tool the SME doesn’t otherwise use is a feature for the proposal manager, not for the SME. The 48% number does not move because the category has not actually built for the SME yet.
The test for any proposed solution
A simple test: how long does the SME spend in the proposal tool to answer a question? If the answer is “more than zero minutes,” the design is wrong. The right answer is the SME spends zero minutes in the tool and three minutes typing in their existing chat surface, with the proposal team doing the work to make those three minutes count.
This is an opinion. It is also the bet the product is built on.