Enterprise Intelligence Group

The Decision Interview Question Bank

Eight sets of questions for buyers, planners, category and supply chain leads, plus a 45-minute interview protocol and a one-page capture template.

You cannot automate a decision nobody has been asked to explain.

Eight sets of questions for buyers, planners, category and supply chain leads, plus a 45-minute interview protocol and a one-page capture template.

Your systems record what was decided. They are not built to carry why: the evidence that was trusted, the exception that applied, the constraint that ruled an option out. This is the question bank for extracting that reasoning from the people who hold it, one decision at a time, in a structure an AI team can build on.

The principle

Ask for the last time it happened, not the general rule. A specific instance carries the reasoning; a general rule carries only the summary.

What this is

A question bank for the conversation nobody schedules: the one where you ask the person who makes a decision why they make it the way they do.

Your systems record what was decided: the range, the price, the order quantity, the delist. What they are not built to carry is the reasoning: the evidence that was trusted, the exception that applied, the constraint that ruled an option out, the thing that was tried two years ago and quietly reversed. That reasoning is what we call the Unwritten Knowns, and it is what an AI agent needs before it can make a commercially sound recommendation in your business rather than a generically plausible one.

This is the extraction instrument. Eight sections, organized by what you are trying to get out, not by job title, system or department. Every question is one you could ask a buyer, planner, category manager, supply chain lead or account manager tomorrow morning.

Use it for one decision at a time. A question bank aimed at "how does merchandising work" produces a tour. Aimed at "how do we decide to delist a SKU", it produces a decision you can actually operationalize.

What you'll learn

• The eight kinds of knowledge that have to be extracted before a decision can be automated, and the questions that get each one out.
• How to tell a good answer from a weak one in the room, while you can still follow up.
• How to run a 45-minute decision interview: who to invite, what to bring, what to record, and the traps that quietly ruin the transcript.
• The five follow-up questions that do most of the work.
• A one-page capture template you fill in per decision, structured so the output is usable by an AI team rather than filed as meeting notes.

How to read the notes under each section

Every section closes with two short notes. What a good answer sounds like is the signal that you have reached the reasoning layer. What a weak answer tells you is not a failure. A weak answer is a finding. It tells you where the intelligence is undocumented, unowned, or sitting in one person's head, which is exactly what you came to learn.

1. The decision itself

You are establishing what is actually being decided, how often, by whom, and what a wrong call costs. Nothing else in this bank works until this is nailed down.

• Walk me through the last time you made this call. What was in front of you when you started?
• What exactly is being decided? What are the options on the table, including doing nothing?
• How often does this come up? Does it arrive on a calendar, or does something trigger it?
• When this decision goes wrong, whose name is on it?
• What does a wrong version of this cost, and how long before anyone notices it went wrong?
• What has to be true before you are allowed to make this call at all?
• Who else in the business is making a version of this same decision somewhere else?
• If you were away for three weeks, who would make it, and what would they get wrong?

What a good answer sounds like. A specific instance with a date attached, a named supplier, SKU, store or account, the options that were genuinely considered, and a cost of error expressed in something the business measures: lost margin, availability, service level, a customer conversation, hours of rework. The person distinguishes between the decision and the paperwork that follows it.

What a weak answer tells you. If the answer describes a screen ("I run the report and follow the recommendation") you are talking to the executor, not the decision-maker, and the decision sits upstream of this conversation. If the answer is a job description rather than a decision, the decision has not been isolated yet. Both are worth knowing before you build anything: an agent pointed at a task will automate keystrokes and leave the judgment untouched.

2. The evidence actually used

The gap between what the systems hold and what the person actually looks at is where an agent's recommendations go wrong. You are after the real evidence set, in the real order, including the parts that never touch a system.

• Which numbers did you actually look at before you decided, in the order you looked at them?
• Which report or screen do you open first, and what do you check in it before you trust it?
• What did you look at outside the system? A spreadsheet, an email, a photo, a phone call?
• When two sources disagree (the system and the supplier, the forecast and the store), which one wins, and why?
• Which number in the system do you know to be wrong or stale, and how do you correct for it in your head?
• What did you check that is not in any system at all? A store visit, a competitor's shelf, something a rep told you?
• How recent does the data have to be before it stops being useful for this decision?
• What evidence would have changed your mind?
• What do you only go and look at when something feels off?

What a good answer sounds like. Named reports and named fields, in a stated order, with a clear precedence rule for conflicts: "the supplier's confirmation beats our lead time, because ours is a default we have never maintained". Known data-quality problems are stated openly, along with the correction the person applies mentally. The out-of-system evidence is named specifically enough that you could go and find it yourself.

What a weak answer tells you. "I look at the data", or a list of every system the person has access to, means the evidence hierarchy has never been made explicit. That matters more than it sounds: an agent given all your sources with equal standing will confidently weight the one your operators have quietly distrusted for years. Source precedence is not a technical detail. It is the first thing you have to capture and the first thing to validate.

3. The exceptions and overrides

The rule is the easy part. The boundary of the rule is the valuable part, and it is not always volunteered, because to the person answering it is not an exception. It is just how you do it.

• When does the normal rule not apply?
• Tell me about the last time you overrode a system recommendation. What did you change it to, and why?
• Which products, suppliers, stores or customers are always treated differently, and who decided that?
• What would the rule tell you to do that you would never actually do?
• Which exceptions have an expiry date, and which ones have quietly become permanent?
• Who is allowed to grant an exception, and who can only ask for one?
• What is the exception you have to explain to every new starter in their first month?
• When you override something, where does the reason get written down, if anywhere?
• Which exception would you defend to a director, and which one are you not sure still holds?

What a good answer sounds like. The exception is named, the trigger condition is stated ("anything on the seasonal calendar between week 38 and week 2"), the authorizing person or forum is identified, and the person can say whether it still applies and who would know. The best answers include an exception the speaker thinks is out of date: that is someone reasoning about the rule, not reciting it.

What a weak answer tells you. "We don't really have exceptions" is rarely the end of the story; follow it with "what would the rule tell you to do that you would never actually do?", which asks the same thing from the other side. "It depends" is the beginning of an answer. The follow-up is "depends on what? Give me the last time it depended." Unrecorded overrides are the highest-risk category you will find, because an agent will apply the base rule at full confidence in precisely the cases where an experienced person would not.

4. The constraints nobody wrote down

Constraints are what make a recommendation executable. A recommendation that is commercially sensible and operationally impossible costs you more credibility than a mediocre one, because it proves the system does not understand the business.

• What can you not do, no matter what the numbers say?
• What supplier minimums, order multiples or lead-time floors shape this decision?
• What is promised contractually? Facings, share of shelf, promotional slots, exclusivity windows, listing commitments?
• What physical limits apply? Fixture size, bay count, cube, cold chain, backroom space, pallet configuration, delivery windows?
• What commitments has someone else already made that you inherit? A promo calendar, a volume commitment, a range review cycle, an allocation?
• Which of these constraints would you have to phone someone to confirm, and who?
• Which constraint have you seen someone break, and what happened?
• Which of these will change this year, and who will know first?

What a good answer sounds like. Each constraint comes with three things: what it is, where it comes from (a contract, a supplier agreement, a physical fact, a policy with an owner), and when it expires or gets renegotiated. The person can distinguish a hard constraint from a habit.

What a weak answer tells you. Constraints described as "policy" with no source document and no owner are constraints living in a person rather than in a governed record. Note them as exactly that, and mark which ones need confirming with a named person before an agent is allowed to treat them as hard. A constraint you cannot trace is a constraint you cannot safely encode.

5. The history and reversals

This is the section people enjoy, and the one easiest to skip. Decision history is the cheapest source of judgment you will ever capture, and it decays fastest. It leaves when the person does.

• What have you already tried here that did not work?
• What decision was reversed, and what triggered the reversal?
• Which SKU, supplier, store or customer came back after being exited, and why?
• What did the last review of this decision conclude, and what changed as a result?
• What do you know now that you wish you had known the first time you made this call?
• What is the thing new people always propose, that the team has already tried?
• Where would I find the record of that, or does it only exist in this conversation?
• What went right that you still cannot fully explain?

What a good answer sounds like. A named instance with a rough date, the trigger for the reversal, and the lesson stated as something close to a rule: "we no longer delist an own-label line in the same period we change the planogram, because we cannot read the result". The person can point at where the evidence lives, even if the answer is "a folder in my mailbox".

What a weak answer tells you. "That was before my time" is a finding, not a dead end: the memory left with someone, and the gap should be recorded explicitly rather than left for an agent to interpret as "this was never tried". Capture what remains, name the person who would have known, and mark the history as incomplete. An agent that does not know what has already failed will propose it again with confidence.

6. The trade-offs

Every consequential decision sacrifices something. If the sacrifice is never stated, an agent will optimize whichever measure it was handed and look wrong to everyone whose number it damaged.

• When you make this call well, what are you deliberately giving up?
• Which two things pull against each other here? Margin and availability, range breadth and inventory, speed and accuracy, service and cost?
• How do you choose between them when both matter in the same week?
• Whose number gets worse when yours gets better?
• Who arbitrates when you and that function disagree, and how long does it take to get a ruling?
• What is the tie-breaker when the numbers are close?
• What would you do differently in the last week of the quarter than in the first?
• Which trade-off has changed direction in the last year, and who decided that?

What a good answer sounds like. Both sides are named, the current tilt is stated along with the reason for it, and the arbiter is a role with a route to reach them. The person can describe a recent case where they chose the less obvious side, and explain why.

What a weak answer tells you. "We balance both" and "we optimize for the customer" mean the trade-off is being resolved implicitly, case by case, in someone's head. That is workable for a person and unworkable for an agent. If nobody will state the tilt, the trade-off needs a decision from the owner before automation, not after, and surfacing that is a legitimate outcome of the interview.

7. The decision rights

Who recommends, who approves, who can override, and what escalates. This is the section that turns captured knowledge into a policy an agent can operate inside.

• Who recommends, who approves, and who can overrule the approval?
• At what size, value or risk does this decision leave your desk?
• What can you do without telling anyone, and what needs a heads-up first?
• Who has to be consulted even though they cannot say no?
• What happens when you cannot reach the approver? Is there a default, or does it wait?
• How is the approval recorded? An email, a system step, a meeting minute, or nothing?
• Who found out about the last one after it was made, and would have preferred to know before?
• Which of these rights are actually written down, and where?
• What has someone done that they were not entitled to do, and how was it discovered?

What a good answer sounds like. Thresholds with numbers or values attached, roles rather than only names, a stated escalation path with a fallback, and a specific place approvals are recorded. The person knows the difference between who must be consulted and who must consent.

What a weak answer tells you. An org chart is not a set of decision rights. "Ask Dave" is not an escalation path. It is a single point of failure with a first name. Where rights are social rather than governed, an agent has no basis for knowing when to stop and ask, which is the single most important thing it will ever need to know.

8. The tells of leaking intelligence

Asking "what do you know that nobody else knows?" produces modesty, not intelligence. These questions get at the same thing sideways, through the evidence of a dependency rather than the claim of one.

• What do people phone you about that is not in your job description?
• What would break in the first month if you left tomorrow?
• What is in your own spreadsheet that is not in any system?
• Which mailbox folder, notebook or chat thread would someone need to do this job?
• What do you check that nobody ever asked you to check?
• Who is the only person who really knows that supplier, that store, that customer, that category?
• What question do you get asked repeatedly that you always answer from memory?
• What have you explained more than three times this year?
• What does a new starter get wrong for their first six months that nobody ever writes down?
• Which of your regular tasks would you be uncomfortable handing to a capable stranger with your access?

What a good answer sounds like. Concrete artifacts and recurring asks: a named spreadsheet, a maintained list, a weekly check nobody assigned, a supplier relationship that routes through one person. The person can name what they would have to explain, and to whom.

What a weak answer tells you. "It is all in the system", from someone making a consequential judgment call, is worth a gentle test: go back to "what do you check that nobody asked you to check?" and ask for the last example. If the operational tells come back empty as well, you may genuinely be looking at a decision that is already well governed, which is a good finding and worth recording as one. In other cases the person simply has not noticed what they know, and the tells surface it where the direct question could not.

The five follow-ups that do most of the work

The questions above open the door. These keep it open. Use them constantly, in any section.

• "When did that last happen?" Converts a general policy into a specific, checkable instance.
• "Who else was involved?" Surfaces decision rights, and the second interview you need to book.
• "What would have to be true for you to do the opposite?" Finds the boundary of a rule faster than asking for exceptions directly.
• "Where is that written down?" Separates governed knowledge from an Unwritten Known. Both are valuable; only one is safe to point an agent at today.
• "When does that stop being true?" Captures the expiry. A rule without an expiry becomes a defect the moment the business changes.

The interview protocol: running a 45-minute session

Who to invite

• The person who actually makes the call, not their manager. One operator per session.
• A second listener who takes the notes, so the interviewer can stay in the conversation and follow up.
• Not the approver, and not the operator's manager. Decision rights change what people are willing to say about exceptions and overrides. Interview the approver separately; section 7 becomes their session.
• If two people share the decision, interview them separately first, then together to resolve the differences. The differences are the finding.

Before the session

• Choose one decision and name it in the invitation: "how we decide seasonal buy quantities for category X", not "supply chain".
• Pull three real recent instances of that decision out of the systems beforehand and bring them. Real cases stop the conversation drifting into how things are supposed to work.
• Ask the person to have their normal screen and their normal spreadsheet available.
• Say plainly what this is for and what it is not: capturing how good decisions get made, not assessing the person. State it again at the start.

The 45 minutes

• 0–5 · Frame the session. Confirm what is being captured and ask permission to record.
• 5–15 · One real, recent instance, start to finish, in their words. Section 1.
• 15–25 · The evidence they actually used, and what wins when sources disagree. Section 2.
• 25–35 · Exceptions, overrides and the constraints that ruled options out. Sections 3 and 4.
• 35–40 · History, reversals and the trade-off they made. Sections 5 and 6.
• 40–45 · Decision rights, escalation and the closing question. Sections 7 and 8.

Do not attempt all eight sections at full depth in one sitting. Pick the two that matter most for the decision in front of you, run them properly, and book a second session. A thin pass over everything produces a document nobody can act on.

Close every session with the same question: "What should I have asked you that I didn't?" It reliably returns the thing the structure missed.

Recording and consent

• Ask for permission out loud, say who will see the recording, and say what it is used for. If the answer is no, take notes and read them back at the end.
• Record the reasoning, not the person's performance. Nothing captured here belongs in a review.
• Anything the person flags as sensitive (a supplier relationship, an internal disagreement) gets marked and handled deliberately, not quietly dropped into a shared drive.

The traps

• Leading questions. "So you'd use the forecast, right?" gets you your own answer back. Ask for the last instance instead of the general rule.
• Post-rationalization. People reconstruct a tidy reason for a messy call, in good faith. Anchor on a dated instance and the artifacts that existed at the time, and ask what they knew then rather than what they concluded later.
• Accepting the general answer. "It depends" is where the interview starts.
• The audience effect. A manager in the room turns exceptions into policy and overrides into best practice. Watch what disappears from the conversation when someone senior joins it.
• Interviewing at the wrong altitude. If the person is describing which button they press, the decision is being made somewhere else. Find out where, and book that session.
• Capturing the rule and not the boundary. Every rule you write down needs the "when does this stop being true?" question applied to it before the session ends.
• Treating the interview as sign-off. Everything captured is a draft until the operator has read it back and corrected it.
• Filling the template during the conversation. Take notes, ask better follow-ups, and fill the template afterwards. The template is the output, not the script.

After the session: within 48 hours

• Fill the capture template below for the decision. One page. Not a transcript.
• Send it back to the operator and ask for corrections in writing.
• Treat the corrections as the highest-value artifact of the whole exercise: they mark exactly where your understanding was wrong, and where the operator is precise.
• Log what you could not resolve as an open question, with a named person against it.
• Assign an owner to the captured decision, or it starts decaying the day you file it.

The capture template: one page per decision

Fill one of these per decision. The fields are deliberately the ones an AI team will ask you for; a transcript is not, and neither is a slide.

• Decision. One sentence: what is being decided, and for what scope.
• Owner (role). The role accountable for the outcome, not necessarily the interviewee.
• Captured from. Name, role, date. Second source if the decision is shared.
• Trigger and frequency. What starts it, how often, calendar-driven or event-driven.
• Options routinely considered. Including "do nothing" if that is a real option.
• Cost of a wrong call. In the unit the business measures, plus time-to-detect.
• Evidence, in precedence order. Source, report or field, known limitation. Numbered, highest authority first.
• Conflict rule. Which source wins when two disagree, and why.
• Rules as stated. If / then / because. The "because" is the part that survives a change in the business.
• Named exceptions. Exception, trigger condition, authorized by, expires or reviewed when.
• Hard constraints. Constraint, source, who confirms it, when it next changes.
• Trade-offs. A versus B, current tilt, reason, arbiter.
• Decision rights. Recommends, approves, can override, escalation trigger, where the approval is recorded.
• History and reversals. What was tried, what was reversed, what triggered it, the lesson as a rule.
• Single-person dependencies. What only this person knows, and what artifact holds it today.
• Open questions. Unresolved items, each with a named person and a date.
• Status. Draft, validated by operator (date), owner assigned (name, date).

Turning the capture into something an agent can use

Each field exists because something downstream needs it. That mapping is the whole reason to interview in this shape rather than freely.

• Evidence in precedence order, and the conflict rule. How retrieval ranks and reconciles sources.
• Rules as stated, with the "because". The decision logic, and the explanation attached to a recommendation.
• Named exceptions with triggers. Guardrails: where the base rule must not be applied.
• Hard constraints with sources. Filters applied before a recommendation is ever shown.
• Trade-offs with the current tilt. The objective the agent may optimize, and the one it must not damage.
• Decision rights and escalation triggers. When the agent stops and asks a person.
• History and reversals. What not to propose again, and what to watch for.
• Single-person dependencies. The capture backlog, and the risk register.

Then take one decision, not one platform. Map it properly, capture its knowledge with these questions, deploy one bounded assistant against it, and expand only when the evidence supports it. Autonomy is earned: an agent moves from recommending, to drafting, to acting as validation and measured performance justify it, never because the tool shipped with the capability.

Where to start

If you do not yet know which decision to interview first, the free five-minute AI Maturity Assessment scores your readiness across six dimensions, including knowledge readiness and governance, and points at where the intelligence gap is widest.

The EIG Library  ·  Insights  ·  AI Maturity Assessment  ·  Contact