A stakeholder keeps using a term you have never heard. What do you do in the meeting?

Decide whether it blocks the decision

You cannot ask about every unfamiliar word, because a meeting where you interrupt eight times stops being a meeting about the business and becomes a tutorial for you. So triage in real time on one criterion: does not knowing this term prevent me from understanding the decision being made right now?

If it does, ask immediately — a requirement written around a word you do not understand is a defect with a long fuse, and a few seconds of asking is cheap against building the wrong thing. If it does not, because the term is context or belongs to a part of the process outside your scope, write it down for afterwards. Most terms fall into the second category, which is why a running list is the main tool here.

Ask for the instance, not the definition

The phrasing matters more than people expect, because two questions that look equivalent produce completely different answers. "What does a chargeback mean?" invites a textbook sentence that you could have found yourself and that leaves you no better able to reason about it. "Can you walk me through the last one you dealt with?" produces the actual behaviour: who raised it, what evidence was needed, what the deadline was, what happens when it is missed, and which system was involved. You learn the term and its consequences in one answer, and the stakeholder gets to talk about their work, which they generally enjoy.

Three variants do most of the work.

Instead of	Ask	Because it gives you
"What is a settlement break?"	"Can you walk me through the most recent one?"	The lifecycle, the actors and the timings, not a sentence
"What counts as a qualifying account?"	"What's an example of something that looks like one but isn't?"	The boundary, which is where the rules live
"What does the reserve do?"	"What goes wrong downstream if it's set wrong?"	Why the concept exists and who depends on it

Ask cleanly, with no apology. "Say more about what a settlement break is in your world" gets you a good answer. "Sorry, I'm new, apologies for the basic question" costs you standing and trains the room to stop explaining things properly. Asking about the substance of someone's job is normal professional behaviour; performing embarrassment about it is what makes it awkward.

Play it back before the meeting ends

The step that converts a question into a contribution is the playback. Restate the term in your own words, in the context of the decision, and invite correction: "So a settlement break is a trade where the cash and the securities didn't move on the intended date, and if it's unresolved past a certain point there's a penalty. If that's right, then the retry logic we were about to build needs to know the intended date, not just the failure." You have made your understanding visible, and if it is wrong the stakeholder corrects you in eight seconds — in the meeting, at zero cost, instead of in a schema six weeks later.

Playback is also what stops bluffing, the real risk here. Nodding along and looking the word up later feels efficient and usually is not, because the definition you find online is the industry's general one while the business is using it with a local narrowing you will not discover. Meanwhile the bluff propagates into the minutes, the ticket title and eventually a column name, where a term you guessed at will outlive everyone's memory of the meeting.

Afterwards, batch the remaining list and take it to one person — often not the most senior, since a support lead or operations analyst will happily spend twenty minutes on ten terms and be pleased to be asked. Write the answers into a shared glossary with an example beside each entry and treat it as a deliverable. It is the cheapest artefact you will produce and the one the next joiner will actually use.

The term you did not notice was ambiguous

An unknown word is a small problem, because you know that you do not know it and the mechanism for fixing it is a question. The expensive case is the word you are certain you understand and which two parts of the business use differently, because nobody asks a question and both sides leave the room satisfied.

"Customer" is the classic: to sales it is the contracting entity, to support it is the person who calls, to billing it is the account that pays, and to a warehouse it is the delivery address. "Order" may mean the thing a customer placed or the thing a fulfilment centre works from, and those diverge the first time a single order ships in three parcels from two sites. "Booked", "reserve", "position", "active", "closed" and "unit" all carry this hazard. Each one is a place where a system silently models one department's meaning and then produces numbers the other department declares wrong, and the argument that follows is never framed as a vocabulary problem.

So the habit to build is listening for the same word used with different scope by different people, and naming it when you hear it. Ask whose definition a given requirement uses. If both are legitimate — and they usually are, because each is correct inside its own part of the business — resist the urge to arbitrate and pick one true meaning; that is how you produce a model that serves neither. The right move is to qualify the terms in writing, ContractingCustomer and Payer and Recipient, and to accept that the boundary between the two usages is a real seam in the business that your design should follow rather than paper over.

Unknown terminology is a question you can ask in eight seconds; shared terminology with two meanings is a defect that ships, so listen for the word everyone thinks they agree on.