SME collaboration, Part 2 of 4: ticketed asks and response SLAs

Part 1 of this series argued that the async interview is the pattern that works for SME collaboration. Part 2 is about the structure underneath the interview — the ticket form the SME actually receives, and the response service-level agreement (SLA) that makes the queue legible to the SME’s manager.

The most common SME workflow in commercial proposal shops is “just ping them on Slack.” It fails for a specific reason that has nothing to do with the SME’s willingness to help.

Why Slack pinging fails

A Slack ping to an SME is a request without context. The proposal manager writes “hey, can you answer this question for the RFP we’re working on?” with a screenshot of the question. The SME reads it on their phone between two engineering meetings. They do not have the buyer’s RFP open. They do not know what win themes the response is committed to. They do not know how long the answer should be or what citations the proposal manager already has from the KB. They cannot evaluate whether their answer is the right answer or whether someone else on their team should answer it instead.

The SME does one of three things. They write a short, partial answer that the proposal manager has to chase. They forward the question to a teammate who then has to chase the original requester to understand context. Or they put it on their list and forget. Quilt’s analysis reports that sales engineers spend 100 to 300 hours per RFP response — most of that time is not answering questions, it is recovering context the requester didn’t include.

The fix is not “ask better Slack questions.” The fix is to replace the Slack ping with a structured ticket.

What a ticket should contain

An SME ticket is a request packet, not a question. It includes:

• The buyer name and the RFP’s one-paragraph context.
• The exact question text from the RFP, with the section reference.
• The win themes the proposal is committed to, especially the ones this section is supposed to support.
• The KB blocks the proposal manager already has that are candidates for this answer, with their last-updated date and their author.
• The page-allocation budget — “we have 200 words for this section.”
• The deadline, expressed both as a wall-clock date and as a position in the proposal’s milestone schedule (e.g., “needed before red team on 2025-09-22”).
• The specific output the SME is being asked to produce. Not “answer this question.” Either “review the candidate KB block and approve, edit, or reject” — which is a 5-minute task — or “draft 200 words against this prompt, citing the candidate evidence” — which is a 30-minute task. The two are different, and SMEs can prioritize them differently.

The packet is shorter than it sounds — typically a single page rendered as a structured form. The proposal manager assembles it from the RFP, the capture plan, and the KB. In a tool like PursuitAgent the packet is generated automatically; in a Google Doc culture the proposal manager assembles it by hand. Either way, the discipline is to send a packet, not a ping.

Response SLAs by ticket type

Tickets need an SLA. Without one, the queue has no shape and the SME’s manager has no way to weigh proposal work against everything else on the team’s plate.

A workable scheme uses three ticket types and three SLAs:

• Review-and-approve (5-minute task, 1-business-day SLA). The proposal manager has a candidate KB block. The SME confirms it is current, accurate, and appropriate for this buyer. Approve, edit, or reject. The 1-day SLA is short because the work is short.
• Draft-from-prompt (30-minute task, 3-business-day SLA). No candidate block exists. The SME drafts a fresh answer against the packet. The 3-day SLA reflects the real work plus the queue time of a senior engineer.
• Capture-call request (60-minute synchronous, schedule within 5 business days). The question is too complex for an async draft and needs a 20- to 30-minute conversation. Part 3 of this series covers the capture call itself.

The SLAs are not aspirational; they are commitments the proposal manager negotiates with engineering management at the start of each quarter. An engineering manager who knows their team will get review-and-approve tickets at a 1-day SLA and draft tickets at a 3-day SLA can plan capacity and can defend the work against competing requests. An engineering manager who knows nothing about the queue can only react.

What changes when the ticket replaces the ping

Three things, in order of size.

The SME’s response time drops because the context is in the ticket, not in the SME’s head. They are not reconstructing the buyer or the win theme; they are reviewing a packet and producing an output the packet specified.

The proposal manager’s chasing time drops because tickets have status. A ticket is open, in-progress, or closed. A queue of tickets is a dashboard, not a chain of Slack threads in 14 channels. Lohfeld Consulting identified “spending more time chasing SME responses than building strategy” as the single biggest fixable problem in proposal shops. The ticketed-ask pattern is the fix.

The SME’s manager gets visibility for the first time. Qorus’s research on the five-year-stable 48% SME-bottleneck statistic notes that the most consistent root cause is misalignment between proposal asks and engineering capacity. A queue with SLAs makes that alignment possible. The manager can say “yes” to specific commitments and “no” to others — instead of “yes” to everything and silent failure on most of it.

What a ticket form looks like

A workable form has eight fields:

1. Ticket type (review-and-approve, draft-from-prompt, capture-call).
2. RFP and section reference.
3. Buyer context (one paragraph).
4. Question text (verbatim from the RFP).
5. Win themes this section supports.
6. Candidate KB blocks (zero or more, with links and last-updated dates).
7. Page-allocation budget.
8. Deadline (wall-clock and milestone).

Plus the metadata: requester, assigned SME, ticket status, response SLA timer.

The form is not the point. The discipline is the point. A team can implement this in a spreadsheet, in a Jira project, in a purpose-built proposal tool. The pattern is the same: replace the ping with a packet, replace the open-ended ask with a typed task, replace the silent queue with a queue that has SLAs.

Closing

Part 3 of this series is about the meeting that the capture-call ticket type opens up — the 20-minute synchronous conversation that can save four days of draft revision when the question is genuinely complex. It lands next week.

For the engineering side of how the candidate-block packet gets generated for an SME, see the engineering team’s draft-packet generation post. For the canonical post on why the SME bottleneck has been the same for five years, see Bo’s SME collaboration is a UI problem.