SME Interview Prep Agent Skill

---
name: sme-interview-prep
description: Prepares a bid manager to interview internal subject matter experts
  (SMEs) for an RFP, tender or DDQ, blank or part-filled. Searches what the
  organisation already knows (answer library, past responses, CRM, notes), then
  writes only the unanswered questions, grouped by subject with suggested SMEs.
  Use for SME call prep, "what should I ask the SME", or missing context in a
  bid.
---

# SME Interview Prep

A bid manager is about to spend 15 to 20 minutes of an expert's time. That time is the scarcest input to a response, and it is wasted when the interviewer arrives without knowing what the RFP asks, what the buyer cares about, or what the organisation already has on record. This skill does that preparation. It reads the RFP, researches what is already known, and writes an interview plan that contains only the questions the organisation cannot answer from its own records, grouped by subject and matched to the people most likely to know.

The output is questions and a plan, not answers. Do not draft response text in this skill.

This skill is used by many different bid teams, in different industries and with different tooling: a dedicated response platform, a shared drive of past bids, a CRM, or a folder of documents. It assumes none of them. Work out what the user's environment offers, use all of it, and say plainly what you could not reach.

## The four principles behind every plan

Each one shapes what you produce, so apply them as reasons, not as boxes to tick.

1. **Prep first.** The SME should only fill gaps. That is why research comes before questions: no question asks the SME for something a document, past answer or record already says. A question that could be answered by searching does not belong in the interview.
2. **Keep it short and focused.** Ask about outcomes, evidence and proof points, not features. A 15-minute call fits 6 to 8 questions; 20 minutes fits up to 10. Rank the gaps and cut the rest. Features and specifications are looked up, not interviewed.
3. **Use open questions.** "How did that help the client?" and "What changed?" pull benefits and stories out of an expert. Closed questions ("Do we support X?") produce a yes, and technical-detail questions produce a lecture. Neither gives the writer anything to build a win theme on.
4. **The writer writes.** The SME gives input and later checks accuracy. They do not draft. So the plan ends with a hand-off: what the writer sends back for verification, which is a list of specific claims with sources, not the whole draft.

## Workflow

### 1. Frame the RFP

Pull out: the buyer, what is being procured, evaluation criteria and weightings, mandatory requirements, response limits (words, pages), and the list of questions or sections. Record what the buyer says matters, with where it came from (RFP section, call note). If the RFP states no criteria, say so and do not guess a weighting.

### 2. Work out what you can reach

Look at what the session actually offers: uploaded files, folders, and any connected tools or data sources such as an answer or content library, document storage and wikis, a CRM, email, chat, meeting recordings, or an org directory. Use every relevant source you can reach without waiting to be told which. If the user named a location, start there.

If you can reach little or nothing, ask the user once, in one message, for the highest-value material and say what each unlocks: past responses to this buyer or similar questions, an export of the answer library or case studies, any notes from the buyer, and the names or roles of likely experts. If they have nothing to give, continue, but mark the plan "unresearched" at the top and warn that some questions may duplicate what the team already knows.

### 3. Research what is already known

This is the step that makes the rest worth doing. On a blank RFP the document tells you nothing, but the organisation usually knows a great deal and keeps it in scattered places. Find it before writing a single question.

Where to look, in this order (adapt to what exists):

1. **Answer or content library:** approved answers, case studies, product and service documentation, policies, certifications.
2. **Past responses** to RFPs, tenders, DDQs and security questionnaires: same buyer first, then same sector, then same question topic. Prefer won bids. Note the result and any evaluator feedback if recorded.
3. **Records of this buyer or opportunity:** CRM notes, emails, meeting notes or recordings, internal chat threads, discovery or kickoff briefings.
4. **Internal documents:** delivery plans, project reports, post-project reviews, wikis, team pages, presentations.
5. **People signals** (used in step 6): authors and owners of library entries, SMEs named or credited in past responses, deal or project owners, meeting participants, the org directory.
6. **Public material the organisation has published** (website, published case studies), for proof points only.

How to search:

- For each question or cluster of related questions, search with several phrasings: the question's own words, its key nouns, synonyms, the sector, and the buyer's name.
- Open and read the candidate items. Do not judge from titles. For each, check what it gives: an outcome, evidence (a number, its source and period), a proof point, whether it fits this buyer, and its date.
- Work through every question. Stop on a question once you hold strong material. Go deeper on heavily weighted questions. For a long RFP, split the work by subject and run the searches in parallel if subagents are available.
- Cite where everything came from (title, location, date). Separate fact from inference. Never invent a figure, a name or a result. When a figure matters, quote it exactly instead of paraphrasing.
- Do not copy another customer's confidential details into the plan. Cite the source and carry over only what is already approved for reuse.

What counts as unknown: a gap is only "unknown" after the answer library, past responses and buyer records (where reachable) have been searched and nothing answers it with an outcome, evidence or a proof point that fits. Name every source you could not reach in the plan, so the user can judge how far to trust the gaps.

If you find an answer that is old, written for a different kind of buyer, or contradicts another answer, do not drop it and do not treat it as unknown. It becomes a "Refresh" question: lower priority than a true gap, and phrased as "what has changed since [source, date]?"

### 4. Triage every question using what the research found

A blank RFP does not mean unknown, and a filled one does not mean covered. Judge by what the organisation knows. Give each RFP question one status:

- **Covered:** the research found outcomes, evidence and a proof point that fit this buyer.
- **Refresh:** something exists, but it is old, from a different context, or conflicting.
- **Thin:** what exists is generic. Signs: a claim with no number, no named example, no client outcome, a feature list with no benefit, "committed to" or "experienced in" language.
- **Unknown:** nothing found after searching.
- **Not for the SME:** pricing, legal terms, formatting, buyer intelligence, referee permission. Route these (step 9), do not interview for them.

### 5. Name the missing context

For each Refresh, Thin or Unknown question, say what kind of context is missing. Each type needs a different kind of question:

- **Outcome:** what changed for a client because of this
- **Evidence:** the number, its source, its period, where it is written down
- **Proof point:** a named comparable project or client, and whether they would act as a referee
- **Approach:** how it would be run for this buyer and why it is run that way
- **Differentiator:** what the organisation does here that a competitor would not say
- **Limits and risks:** what went wrong before, what should not be promised, what depends on the buyer
- **Currency:** the answer exists but may be out of date or inconsistent

There is deliberately no gap type for features or specifications. If a question needs a spec, add it to the parking lot (step 9) with a note on where to find it.

### 6. Group by subject and find who could know

**Group by subject.** Cluster the open gaps by subject matter, using the RFP's own structure and the nature of the gaps. Typical groups include delivery and implementation, security and compliance, product and technical, integrations, service and support, people and resourcing, social value or sustainability, and references and case studies, but adapt to the RFP instead of forcing a fixed list. Keep it to about eight groups and merge small ones.

**Suggest who could know, only from evidence.** For each subject, look in your sources for the people who would most likely know: the author or owner of the related library entries, an SME named in past responses on the same topic, the owner of a relevant project or account, a participant in relevant meetings, or a role in the org directory that clearly matches. Give the evidence with each suggestion, and a confidence level:

- **High:** named in the sources for this exact subject.
- **Medium:** their role or an adjacent topic fits.
- **Low:** a job title match only. Do not suggest on this basis. Ask instead.

Never guess a person from a job title alone and never invent one. Use work roles and authorship only.

**Ask when you cannot suggest.** If a subject has no suggestion at Medium confidence or above, ask the user who would know. Ask once, in one message, listing the unassigned subjects, each with the role you would expect to look for. Do not stall while waiting: deliver the plan with "To be confirmed" against those subjects, then build the per-SME call guides when the user answers. If nobody is available to answer, leave them as "To be confirmed".

### 7. Rank and cut, per SME

Once subjects are linked to people, rank each person's gaps by evaluation weight (or mandatory status), then size of gap (Unknown before Thin before Refresh), then whether only this person can fill it. Keep what fits the time box. If one person holds more than fits, split into two calls or move the low-weight gaps to the second-pass list, and say which you did. If one person covers several subjects, combine them into one call guide.

### 8. Write the questions

Rules, with the reason for each:

- **One open question at a time, one sentence.** A double-barrelled question gets half an answer.
- **Anchor each question to what is already known.** "The library says X. What it does not say is Y." This shows the SME you did the prep and keeps them on the gap.
- **Ask for the story before the number.** People remember what happened more easily than what it measured. Ask "how would we evidence that?" afterwards.
- **Use the SME's own working language**, not RFP language or sales language.
- **Do not ask for a yes/no confirmation at this stage.** Confirmation comes later, in the accuracy check.
- **Avoid leading questions** such as "Wouldn't you say this reduced cost?" The SME will agree, and the writer will have no evidence.

Adapt these stems to the specific gap. They are starting points, not a script:

- Outcome: "What changed for the client after that?" / "How did that help them?" / "What did they do differently afterwards?"
- Evidence: "How would we show that to an evaluator?" / "Where is that figure written down, and over what period?"
- Proof point: "Which job shows this best? Walk me through it." / "If an evaluator rang that client, what would they say?"
- Approach: "Walk me through how you would run this for [buyer], starting on day one." / "What would you do differently here than on a standard job, and why?"
- Differentiator: "Why do clients choose us for this?" / "What do we do here that a competitor would not?"
- Limits and risks: "What is the worst week you have had on something like this, and what did it show you?" / "What should we not promise?" / "What does this depend on from the client?"
- Currency: "This answer is from [date]. What has changed since?"

For each question, also provide:

- **Known so far:** what the research found, with its source, so the SME is not asked to repeat it.
- **Listening for:** what a usable answer contains (for example, "a client outcome, one number with its source, a named project").
- **If they drift:** a one-line redirect for when the SME starts on specifications ("I'll take the spec from the library. What did that choice mean for the client?").

### 9. Route everything that is not an SME question

- **Parking lot (look up, do not ask):** specifications, product facts and data that exist in documents. State where to look.
- **Other owners:** buyer-priority gaps to whoever owns the account; pricing to commercial; terms to legal; referee permission to account management.
- **Technical validation (separate, later step):** where the RFP asks for specific technical commitments (availability figures, recovery times, certifications, compliance statements, performance targets), list the exact claims that need a technical check, who should check them, and what evidence they need. The interview gathers the outcome story; evaluators still score on verified specifics, so these must not be dropped, only moved to a separate step.
- **Second-pass questions:** gaps that did not fit the time box.

### 10. Add the opening and the close

**Opening** (30 seconds, read aloud): how long it will take; what the interviewer has already read; that the SME will not be asked to write anything; that the draft comes back to them for an accuracy check only.

**Closing questions** (always include, they are the highest-value minute of the call):
- What should we not claim?
- Who could back this up, and would they speak to an evaluator?
- What would you add that I did not ask about?
- Who else should I speak to?

## Output format

Return markdown in the conversation so the bid manager can paste it wherever the team works. Offer to save it if a suitable destination is connected. Use these sections in this order:

```
# SME interview plan: [Buyer / RFP name]
Time box per call: [15 or 20 min] | Assumptions: [2-3 lines]

## 1. What we already know
**Search coverage** (sources searched; sources not reachable)
**Buyer priorities** (with source for each; label inferences)
**Known by subject** (table: Subject | What we have | Where (title, date) | Strength)

## 2. Question triage
(table: RFP ref | Topic | Subject | Weight | Status after research | What is still missing)

## 3. Questions by subject
### [Subject]
**Who could know:** [name, evidence, confidence] or "To be confirmed"
Questions, highest weight first. For each: RFP ref | gap type | the question |
Known so far (source) | Listening for | If they drift

## 4. Who would know? (for you)
Subjects without a confident owner, each with the role to look for.

## 5. Routed and parked
Parking lot | Other owners | Technical validation (separate step) | Second-pass questions

## 6. Call guide per SME (once owners are confirmed)
Opening | Questions in order | Closing questions

## 7. After the call
How the writer drafts and what goes back to the SME: a claims-to-confirm table
(Claim | Source | Status). Unconfirmed figures stay in brackets in the draft until confirmed.
```

Keep the research sections as tables, not narrative. Each call guide should fit one to two pages. It is a conversation guide, not a questionnaire to be emailed. If the user wants a version to send in writing, say that a written questionnaire loses the follow-up questions where most of the value comes from, and offer a shorter set of prompts instead.

## Order of questions within a call

Open with the question about the biggest outcome (it is the easiest to talk about and builds energy). Move to evidence and proof points while the story is fresh. Place approach and differentiator next. Put limits, risks and currency checks last, followed by the closing questions, so the SME finishes on what not to claim and not mid-way through a caveat.

## Edge cases

- **Blank RFP:** research is the main job. Build the "already known" picture from the library, past responses and records before triage. If nothing is reachable, mark the plan "unresearched" and say the questions are built from the RFP text alone.
- **Half-filled RFP:** existing answers are one source among several. Still search for stronger evidence, and treat answers lifted from a different context as Thin or Refresh.
- **Very large RFP:** group by subject first, research by subject, and show the top gaps per subject. State how many gaps were cut.
- **Highly technical question (security, architecture, performance):** still lead with an outcome or risk question, and put the specifics in the technical validation list.
- **Compliance yes/no requirements:** these belong in a compliance matrix. List them under technical validation if feasibility needs an expert check.
- **Little information about the team:** do not guess. Ask the user who would know (step 6).
- **SME says "I do not know":** the follow-up is "who would?", and record the name.

## Before returning, check

- Every question marked Unknown was searched for in the library, past responses and buyer records (where reachable), and the coverage section says what was and was not searched.
- Every question traces to a named RFP question and a named gap type.
- No question is closed, leading, or asks for a feature list or specification.
- The number of questions per call fits the time box.
- Nothing is stated as fact unless it appears in a cited source, and inferences are labelled.
- Every suggested person has evidence and a confidence level, and no one is suggested on a job title alone.
- Subjects without an owner are listed for the user to answer.
- Non-SME gaps are routed, not asked.
- Technical commitments the RFP asks for appear in the technical validation list.

## Worked examples (illustrative, invented)

**Example 1: implementation approach**

RFP question 3.1 (25% weight): "Describe your implementation approach and how you will limit disruption to our teams."

Research found: a library entry on the implementation methodology (generic, three years old, no outcomes), and a case study that gives [Customer A]'s go-live date but no results. A past response to a similar buyer mentions a phased rollout with no figures. Status: Thin. Gap types: Outcome, Evidence. Subject: delivery and implementation. Who could know: the author of the methodology entry and the project owner on the [Customer A] case study (High: both named in the sources).

Weak question: "Do we do phased rollouts?" (closed, asks for confirmation, invites a feature description.)

Better question: "The case study shows [Customer A] went live on [date], but not what changed for their team. What did you do differently on that rollout, and what did it change for them?"
- Known so far: go-live date (case study, [year]); phased rollout (past response, no results).
- Listening for: a specific change in how the work was run, and its effect on the client.
- If they drift: "I will take the spec from the library. What did that change for the client?"

**Example 2: health and safety**

RFP question 5.4 (10% weight): "Explain how you manage health and safety on site."

Research found: a current policy and a valid certificate, but no incident data or examples. Status: Thin. Gap types: Evidence, Limits and risks. Subject: health and safety. Who could know: the person named as health and safety lead in the last two relevant responses (High).

Question: "What is the worst safety incident or near miss you have handled on a site like this, and what changed afterwards?"
- Known so far: policy and certificate (library, valid to [date]).
- Listening for: a real event, the change it caused, and where the record is kept.
- If they drift: "I will take the policy wording from the library. What did you actually change on site?"