Tell a business story with a decision
Use a concrete example without treating one anecdote as proof.
You want leaders to fund a better onboarding process. One new colleague lost a day because access requests had no clear owner. You also have a small log of similar issues, but not a company-wide study.
1 · Notice the conversation
Stakeholder: One difficult first day does not justify a new process.
You: Agreed. The story explains the problem; it does not prove its frequency. The issue log supports testing a small change rather than a company-wide commitment now.
Stakeholder: Why should leaders care about an access form?
You: The consequence is time lost before a colleague can contribute, plus repeated work across teams. The trial would check whether clearer ownership reduces that delay.
Stakeholder: What would make the story persuasive without exaggeration?
You: Show the recent request volumes and delays beside the example, then make the proposed decision and its limits explicit.
2 · Understand what each phrase does
Make the recommendation
Put the decision where the listener can find it.
On her first Monday, a new colleague could not access the customer system, and three teams each thought another team owned the request.
Use the move when it serves this situation. This is not a phrase that must appear in every answer.Explain the consequence
Show what the proposal changes for people or work.
That example shows the handover problem more clearly than a list of tools.
Use the move when it serves this situation. This is not a phrase that must appear in every answer.Define the next move
Specify an action, condition or question that moves the discussion forward.
Our recent issue log suggests it is not unique, although the sample is small.
Use the move when it serves this situation. This is not a phrase that must appear in every answer.3 · Rehearse, then change the details
On her first Monday, a new colleague could not access the customer system, and three teams each thought another team owned the request.
That example shows the handover problem more clearly than a list of tools.
Our recent issue log suggests it is not unique, although the sample is small.
I propose a four-week ownership checklist trial, measured by time to access and unresolved requests.
Keep the purpose; change the person, document or time. A simple, accurate sentence is enough.
4 · Respond to your colleague
One difficult first day does not justify a new process.
Agree with the evidence limit and connect to the broader test.
See one possible reply
Agreed. The story explains the problem; it does not prove its frequency. The issue log supports testing a small change rather than a company-wide commitment now.
Why should leaders care about an access form?
Connect the example to work and responsibility.
See one possible reply
The consequence is time lost before a colleague can contribute, plus repeated work across teams. The trial would check whether clearer ownership reduces that delay.
What would make the story persuasive without exaggeration?
Name relevant evidence and retain the human example.
See one possible reply
Show the recent request volumes and delays beside the example, then make the proposed decision and its limits explicit.
5 · Try a different situation
Use a customer’s repeated support question to explain a proposed documentation change. Distinguish the individual experience from any evidence about how widespread the issue is.
What do you recommend, and what should we decide next?
Use the new facts. State the consequence or trade-off and one next action.
- I use a specific, relevant example.
- I do not turn an anecdote into a population claim.
- I connect the story to a bounded decision and a measure.
6 · Recall without the model tomorrow
Use a concrete example without treating one anecdote as proof.