Consultant operating guide
Consultant Recommendation vs Client Decision
Give clear advice without pretending you own business context or authority that still belongs to the client.
The short answer
A consultant should own the quality of the analysis and the clarity of the recommendation. The client should own the business decision when it depends on internal priorities, risk tolerance, budget authority, or facts the consultant cannot verify.
Do not answer an under-specified decision with a softer opinion. Write a recommendation boundary record that separates what you know, what you recommend, what is missing, and who must decide.
First, identify what kind of problem you have
| Situation | Your responsibility | Client responsibility |
|---|---|---|
| The evidence supports one option | Recommend it and show the tradeoff | Accept, reject, or add context that changes it |
| A critical fact is missing | Name the fact and explain how it changes the recommendation | Supply the fact or accept a qualified decision |
| The choice depends on risk tolerance | Make the risks and reversibility visible | Choose the acceptable exposure |
| No one has authority to approve | Stop the decision from becoming an implied task | Name an accountable decision owner |
The recommendation boundary record
Use this record in the email, memo, or meeting note where the decision is requested. Keep it short enough that the client can answer it.
Decision needed: What we know: What we do not know: My recommendation: Why this recommendation is qualified: Options the client can choose: Decision owner: Decision needed by: What I will do after the decision:
The important line is not the recommendation. It is the boundary around the recommendation. If the missing context could reverse your advice, say so beside the advice, not in a disclaimer at the end.
Worked example
A consultant has compared two vendors. Vendor A is easier to implement. Vendor B has stronger controls but will take longer. The client asks, “Which one should we choose?” The consultant does not know whether the launch date or the control requirement has priority.
Decision needed: Choose the implementation partner. What we know: Vendor A can meet the current launch window. Vendor B meets the stronger control requirement. What we do not know: Whether the control requirement is mandatory for launch or can follow in phase two. My recommendation: Choose Vendor A only if the control owner confirms phase-two treatment is acceptable. Otherwise choose Vendor B and revise the launch plan. Decision owner: Client program sponsor, with control-owner input. Decision needed by: Thursday, before implementation dates are committed.
This is still a recommendation. It simply refuses to hide the client condition that decides whether the recommendation holds.
Three mistakes to avoid
Do not turn missing context into confidence language
“I am 70 percent confident” does not replace the missing fact. Name the fact and the branch it controls.
Do not assign authority silently
A project contact may coordinate the decision without having authority to make it. Ask who can accept the cost, risk, or priority tradeoff.
Do not let a recommendation become approval by silence
State what happens if no decision arrives. Pause the affected work, continue only the unaffected work, or move the date. Do not let the team infer approval.
When to escalate
Escalate when the decision changes scope, cost, legal or security exposure, a committed date, or another stakeholder's work. Escalation is not a threat. It is a route to the person who can accept the consequence.
If the client still cannot identify an owner, record the unresolved decision and the work it blocks. That is an honest no-decision state.
Related Qubit resources
Sources and operating boundary
This guide is operating guidance, not legal, financial, security, or domain-specific advice. Client governance and professional obligations still control the decision.