Analyst Field Guide · Elicitation & Intake
Before you can fix an issue or reconstruct an incident, you need facts — and they usually arrive secondhand, from a client or user describing something you didn't see. People report conclusions, misremember, and leave out what embarrasses them. This guide is the discipline of getting accurate, relevant observations out of the person in front of you, without contaminating them in the process.
The account you're given is not what happened — it's the narrow end of a lossy funnel. An event occurred; the person noticed only part of it, remembers only part of that, tells you only part of what they remember, and you hear that through your own assumptions. Every stage sheds and distorts information. Elicitation is the skill of widening that funnel back out — recovering accurate, relevant observations — while adding as little of your own contamination as possible.
Human memory isn't a recording; it's a reconstruction, rebuilt (and quietly edited) each time it's recalled. By the time a report reaches you it has passed through several lossy stages, and knowing where the loss happens tells you where to push.
The practical consequence: treat the first thing you're told as a lead, not a fact. The rest of this guide is techniques for recovering more of what was lost — and for not adding new distortion of your own, which is the easiest mistake to make (§4).
The single highest-value habit: separate what the person observed from what they concluded. People almost always hand you the conclusion — it's more useful to them — but the conclusion is where their (fallible) reasoning has already been applied. You want the raw observation so you can do the reasoning yourself.
| What they say (conclusion) | What you need (observation) — how to pull it back |
|---|---|
| "The internet is down." | "What did you see when you tried? Which app, what on the screen?" (Maybe one site, maybe DNS, maybe Wi-Fi icon off.) |
| "Your update broke it." | "When did it last work, and what happened between then and now?" (Correlation isn't cause.) |
| "Nothing changed." | "Walk me through what you did this morning, step by step." (This rarely survives the walk-through.) |
| "It's really slow." | "Slow doing what, specifically — and how long versus normal?" (Quantify; compare to baseline.) |
| "I think I got hacked." | "What exactly did you see or receive that made you think so?" (Get the artifact, not the theory.) |
Whenever an artifact exists — the exact error text, a screenshot, the actual email, the timestamp — get that rather than the person's paraphrase of it. "It said something about a certificate" and the verbatim error string are not the same evidence. A paraphrase has already been through the funnel; the artifact hasn't.
Questions come in a rough order of how much they steer the answer. The technique is the funnel: start as wide as possible and narrow only once the free account is exhausted.
A few question shapes to avoid, especially early: compound questions (two at once — they answer one, usually the last), forced-choice ("was it slow or was it down?" — the truth may be neither), and anything that presupposes a fact not yet established ("when the server crashed, what were you doing?" assumes it crashed).
The interviewer is the biggest source of new distortion. A leading question smuggles the answer into the question, and because memory is reconstructive, the person can absorb your suggestion and later "remember" it as their own observation. This is the well-established misinformation effect: decades of eyewitness-memory research show that a single suggestive word can change what someone reports — and change what they genuinely believe they saw.
"Did you see a certificate warning?" tells the person the answer you expect; many will helpfully agree. Ask instead: "Was there anything on the screen before it failed? What did it say?" Keep your hypotheses to yourself until after the free account — voicing them ("sounds like a DNS issue") steers everything that follows. Watch order effects too: whatever you mention first anchors the rest of the conversation. The goal is to elicit their memory, not supply one. Once contaminated, an account can't be reliably cleaned — so prevention is the only real control.
This is not about interrogating or catching people out. Suggestive questioning contaminates cooperative, honest reporters just as easily as evasive ones — the fix is neutral, open phrasing, not suspicion.
For a support or troubleshooting ticket, a small set of questions recovers most of what you need. Ask them in roughly this order, open first, and capture the answers verbatim where you can.
Write the answers down as you go, in the reporter's own words, with timestamps — especially the verbatim error and the "last worked / first failed" times. Memory (yours now, too) is the funnel; the written intake is the artifact you and the next responder will actually reason from. If it might become an incident, this record is also the start of your evidence trail (§9).
Most faults are introduced by a change. Anchoring the report to a timeline turns a vague complaint into a bounded search: find "last known good," find symptom onset, and the cause almost always lives in the gap between them.
"What changed" is the highest-yield question in troubleshooting, but it's also the one most often answered "nothing" — not from dishonesty, but because routine actions don't feel like changes. Get there by walking the timeline concretely ("what did you do right before it stopped working?") rather than asking the abstract question.
People edit their account to protect themselves. If admitting what they did feels like confessing to a mistake — clicking the link, plugging in the drive, changing the setting they weren't supposed to — they'll soften it, omit it, or say "nothing changed." That omission is often the single fact you most need.
Lead with the shared goal — "I'm trying to get you working again, not find fault" — and mean it. Normalize the awkward answer ("lots of people click these, it's fine — can you forward me the email?"). Never react with alarm or judgment to what someone reveals, or the disclosures stop. This is the same blameless principle the Root Cause Analysis and Incident Response guides run on, and for the same reason: blame suppresses information, and you can't fix what you can't see. Rapport here isn't niceness for its own sake — it's an evidence-quality control.
Practical moves that build it fast: use their words, not jargon; reflect back what you heard ("so it worked until you got the new laptop — is that right?") to confirm and to show you're listening; give them room to talk without interrupting the free account. Silence is a tool — people fill it with detail if you don't rush to the next question.
Most difficulty is a predictable type, and each has a handling. None of these are bad people — they're normal responses to stress, embarrassment, or wanting to help.
| Type | Handling |
|---|---|
| The vague — "it's just broken" | Anchor to specifics and artifacts: one concrete instance, the exact screen, the last time it worked. Trade abstractions for a single walked-through example. |
| The over-confident — states theories as facts | Accept the theory as a lead, then quietly get the observations underneath it. Confidence is not evidence; separate what they saw from what they concluded (§2). |
| The embarrassed — hiding an action | Blameless framing (§7). Ask what happened, not who did what; make disclosure safe. |
| The frustrated / hostile | Acknowledge the impact first ("this is clearly costing you time"), then redirect to facts. Don't match the affect; give them a concrete next step. |
| The over-helpful — narrates a diagnosis | Thank them, then ask for raw observations. Well-meaning theorizing is still interpretation layered over the facts you need. |
The through-line: in every case you're steering from their interpretation back to their observation, and doing it in a way that keeps them willing to talk.
When the account might become evidence — a suspected compromise, a serious outage, anything that could end in an after-action or a legal process — the stakes on contamination rise, and a few extra disciplines apply.
This is the honest limit of the whole method: even a perfectly conducted interview yields a reconstructed, fallible memory, not a fact. A careful elicitation gives you a higher-quality account and a clear record of how you got it — it does not make the account true. Treat it as one input, hold it at the confidence its corroboration supports, and verify the load-bearing claims against artifacts — logs, timestamps, change records, the actual email — wherever they exist. This is the evidence discipline of the Incident Response and Critical Thinking guides, applied at the source.
| Belief | Reality |
|---|---|
| "If they were honest, the account is accurate" | Honesty and accuracy are different. A sincere reporter still forgets, misperceives, and reconstructs — memory is lossy regardless of intent. |
| "Specific questions get to the point faster" | Early closed questions plant answers and cut off the rich free account. Open first; narrow last. |
| "A confident, detailed account is a reliable one" | Confidence and detail don't track accuracy — and detail can be confabulated. Corroborate against artifacts. |
| "Asking 'did you see X?' just confirms it" | It can create X. Suggestion contaminates cooperative reporters, who then genuinely "remember" what you supplied. |
| "Pressing harder gets the truth" | Pressure and blame make people withhold and edit. Rapport and a blameless stance surface more. |
| "Once I've interviewed them, I have the facts" | You have an account — evidence to weigh, not truth to bank. Verify the load-bearing parts. |
The account is the narrow end of a lossy funnel (attention → memory → what they tell you → what you hear). Your job: widen it back out, add no contamination. A report is evidence, not fact.
People hand you conclusions ("the internet is down," "nothing changed"). Pull them back to what they actually saw and did. Ask for the artifact — verbatim error, screenshot, the real email — not the paraphrase.
Open ("tell me what happened") → probing ("what happened right before?") → closed ("was there an error code?") last. Never open with a closed or leading question. Avoid compound, forced-choice, and presupposing questions.
Trying to do what / saw what / when did it start & last work / what changed / reproducible / who else / impact. Anchor to time: last-known-good → change → onset. The cause lives in the gap. Capture it in writing, verbatim, timestamped.
Blameless — blame suppresses information; make the truth cheap to tell. Interview witnesses separately; separate firsthand from hearsay. Then verify the load-bearing claims against logs and artifacts — the interview gives a better account, not a true one.
This guide is method, drawn from established interviewing practice (the cognitive-interview tradition, and decades of eyewitness-memory research on the reconstructive, suggestible nature of recall); those findings are described in general terms rather than cited to a specific study, and no quotes are attributed to real individuals. Its honest limit is built in: a well-conducted interview yields a higher-quality, better-documented account — reconstructed, fallible memory — not ground truth, so load-bearing claims should be corroborated against artifacts (logs, timestamps, change records) wherever they exist. Companion to First-Principles Thinking (you can't reason soundly from a reporter's conclusions — get to observations), Troubleshooting (the diagnostic intake and "what changed"), Root Cause Analysis (the shared blameless stance and evidence discipline), Critical Thinking (weighing account reliability and competing accounts), and Incident Response (witness accounts as preserved, corroborated evidence).