How to give a clear recommendation at work

The listener needs more than “B seems best.” They need to know what you are proposing, how far that proposal goes and whether you want approval, investigation or discussion. A clear recommendation can be provisional without becoming vague.

Recommend a step you can actually justify

Consider this fictional situation. The facts and estimates are authored for practice, not observed Ptichi results:

• In a check of ten internal help links, two led to outdated instructions. The check did not cover the whole library.
• The team needs to address those known bad links this week.
• A: repair the two links on Tuesday, with an estimated two staff-hours of work.
• B: run a two-week trial of a new document index, with an estimated four staff-hours of setup. Whether it helps people find current instructions is unknown.
• Repairing two links will not establish that the rest of the library is current or easy to search.
• The manager can approve Tuesday's two hours. A broader trial needs a separate decision.

A recommendation buried in analysis

We have been looking at the library and there are a few different possibilities. An index could help, although it would take some setup, and we could also tidy up the links. It depends how much we want to change.

The listener must assemble the recommendation themselves. They may also mistake a possible benefit of the index for a result someone measured.

A bounded proposal

I recommend repairing the two known bad links on Tuesday. That fits this week's priority and should take about two staff-hours. It leaves the wider search problem unresolved. Can you approve those two hours? If people still cannot find the current instructions after the repair, I would bring back a separate proposal for the index trial.

This version is an authored example. It does not claim A is the best solution for every library. It says why A fits this decision, names what it leaves undone and gives the manager a specific response to make.

The reason needs a priority

“A takes less time” is a comparison. “A fits our priority of fixing the two known bad links this week” is the judgment behind this recommendation. Make that relationship explicit so the listener can disagree with the priority as well as the choice.

Keep four kinds of statement distinguishable:

• Evidence: two of the ten checked links led to outdated instructions. This does not describe every link.
• Estimate: the repair may take about two staff-hours. It is not a logged result or a guarantee.
• Judgment: the bounded repair fits the immediate task better than starting a wider trial.
• Revision condition: continued difficulty finding current instructions would justify reconsidering the scope. It would not, by itself, prove the proposed index works.

Use the strongest reason you can support. Do not add “everyone agrees,” “no risk” or a predicted saving just to make the sentence firmer. If the alternatives still need comparison, the tradeoff guide helps you prepare that part before choosing.

Ask for the right kind of response

Name the decision and check that you are asking someone who can make it.

What you need now	A useful finish
Approval for bounded work	“Can you approve the two hours for Tuesday's link repair?”
Permission to learn more	“Can we investigate the index with a four-hour setup limit before proposing a rollout?”
A choice between viable options	“Given this week's priority, I recommend A. Do you want to proceed with A or change the priority?”
Discussion of a current view	“This is my current recommendation. I am looking for objections before a decision is made.”

Approval for an investigation is not approval to roll out its result. If no decision is needed yet, say so. An artificial deadline or request does not make a recommendation more useful.

Practise one clearer decision request

Use the fictional link-repair facts or a real decision you are preparing. For your own task, first make a short factual note: the proposal, current priority, material cost, known limit and person who can decide.

Take A

Say your recommendation naturally, without polishing a script. Use a recorder you already have if you want playback; Ptichi's website does not record. Keep the factual note nearby so uncertainty does not disappear while you speak.

Listen

On playback, ask:

• Is the actual choice stated, or do I only describe the options?
• Is the reason tied to the listener's current decision?
• Is the cost or unresolved problem still present?
• Can I identify exactly what response I requested?

This is a review of your wording. Knowing your own intended answer makes self-listening weaker evidence of another person's understanding.

Change one thing

Replace a vague finish such as “What do you think?” with the specific response needed now. Keep the proposal, facts, reason and limits as they were. In this scenario, ask for Tuesday's two hours rather than approval for a whole new search system.

Take B

Give the same recommendation again, in your own words, with that one changed finish. A firmer request should not turn the two-hour estimate into a promise or imply the rest of the library has been checked.

Compare

Which take makes the requested decision easier to identify? Did the clearer finish preserve the limit on what you are proposing?

If a willing colleague listens, ask what action you recommend and what decision you need before showing your note. Keep their original answer, including missing or uncertain parts. Recovering the proposal does not mean they endorse it or have authority to approve it. A colleague who already knows the task or heard Take A may use that knowledge on Take B; a later correct answer does not isolate the effect of your edit.

Transfer: the priority changes

Now the manager says the immediate task is to learn whether staff can find current instructions across the library, not just to repair two links. Give a new recommendation. Explain what investigation you would propose and what it could establish before anyone decides on a rollout. Keep the trial's benefit unknown.

This is a changed practice situation, not evidence of lasting learning. You are trying to keep the reason aligned with the decision rather than memorize the earlier wording.

Our read of the decision guidance

NASA's Decision Analysis guidance connects recommendations to decision criteria and asks for assumptions, limitations and uncertainty that could affect the preferred option to be documented. This is engineering guidance, not evidence that a spoken formula improves decisions.

Our read: a recommendation should reveal enough reasoning for someone to challenge it. That is why this exercise keeps the proposal, its limit and the requested response together. It avoids treating confidence of delivery as confidence of evidence. We have not established that this practice improves approval rates or workplace outcomes.

When to bring more than a short answer

A consequential decision may need the analysis, alternative views, required reviews and affected people in the room. A clear opening gives that discussion a starting point. It cannot supply missing evidence, resolve conflicting priorities or grant authority you do not have.

For the real conversation, continue with the free Before Meeting rehearsal. Bring your own factual note and practise the exact response you need. The web exercise is available without an account; use your own recorder for optional playback.