Evidence-Based Recommendation Writing Working Skill

What this skill is for

This skill helps you write recommendations that decision-makers can approve or reject with confidence. It separates evidence from opinion, states what was considered and rejected, and makes the risks of the chosen path visible. The output is a Recommendation Note that tells the reader: what the situation is, what options were evaluated, what evidence supports each option, which option is recommended, why it is recommended, what the risks are, and what must happen next.

When to use this skill

• A steering committee needs a one-page recommendation with supporting evidence for a major investment decision.
• An architecture board must choose between competing integration patterns and needs a documented rationale.
• A change advisory board needs to approve or reject an emergency patch deployment with evidence of risk and benefit.
• A project manager must recommend a scope reduction to meet a deadline, with evidence of what is lost and what is preserved.
• A business analyst must recommend a process change, with evidence from system logs, stakeholder interviews, and pilot results.

Real work situations

Steering committee: recommend SAP S/4 migration approach

A steering committee must decide whether to migrate to SAP S/4HANA through a greenfield implementation, a brownfield conversion, or a selective data transition. The evidence-based recommendation presents: (1) situation — current ECC system has 150 custom objects, 8 of which are critical; (2) options considered — greenfield (cleanest but longest), brownfield (fastest but carries custom debt), selective (balanced but complex); (3) evidence — greenfield pilot showed 6-month delay due to data model redesign; brownfield assessment showed 40% of custom objects are redundant; selective data transition reference from a peer company showed 18% cost overrun but on-time delivery; (4) recommendation — selective data transition with a parallel clean-core extension track; (5) risks — cost overrun if data archiving is not completed on schedule; (6) next steps — approve budget, begin data archiving sprint, select implementation partner by July 30.

Architecture board: recommend API strategy for customer integration

The architecture board must choose how to integrate a new customer portal with SAP. The recommendation presents: (1) situation — current customer master is maintained in SAP ECC via XD01; portal requires real-time validation; (2) options — direct RFC calls, OData API via SAP Gateway, middleware with event bus; (3) evidence — load test showing RFC calls fail at 500 concurrent users; OData reference showing 2,000-user capacity; middleware cost estimate from vendor; (4) recommendation — OData API with a middleware fallback for peak events; (5) risks — middleware fallback requires new operational runbook; (6) next steps — approve API contract, build load test environment, draft runbook.

Change advisory board: recommend emergency patch deployment

A critical IDoc interface failure is blocking goods receipts. The CAB must decide whether to approve an emergency patch outside the normal release window. The recommendation presents: (1) situation — IDoc status 51 errors since 02:00, affecting 12 purchase orders, blocking warehouse operations; (2) options — wait for standard release window (Monday), deploy emergency patch now (Friday), apply temporary workaround (manual posting); (3) evidence — system logs showing error pattern matches known bug SAP Note 1234567; manual posting took 4 hours for 3 orders yesterday; weekend warehouse schedule has 40 receipts planned; (4) recommendation — deploy emergency patch now with rollback plan; (5) risks — patch may affect other IDoc types; (6) next steps — CAB approval, deployment in 2 hours with monitoring, post-deployment validation of 5 IDoc types.

Inputs required

• A clear situation statement: what is happening, who is affected, and what the deadline is.
• A list of options that were seriously considered, including the "do nothing" or "status quo" option.
• Evidence for each option: system logs, data samples, benchmark results, stakeholder input, vendor quotes, pilot results, or precedent from similar decisions.
• Constraints: budget, timeline, compliance, or resource limits that eliminate some options.
• A risk assessment for the recommended option: what could go wrong and how it would be detected.
• The decision-maker's authority level and what they need to know to decide.
• A Trade-Off Analysis or Option Comparison Matrix if the recommendation follows a structured comparison.

Questions to ask

• What should be done, in one sentence?
• Why should it be done, and what is the cost of not doing it?
• What evidence supports this recommendation, and where did the evidence come from?
• What other options were considered, and why were they rejected?
• Is this recommendation based on evidence, or on opinion, or on precedent? Label it.
• What are the risks of following this recommendation, and how will we know if they materialize?
• What must happen next, who must do it, and by when?
• What would make us reconsider this recommendation after it is approved?

Working method

1. State the situation. Write one paragraph: what is happening, who is affected, what the business impact is, and what the deadline is. Attach evidence (logs, data, tickets).
2. Define the decision required. One sentence: "We need a decision on X by Y because Z." Name the decision-maker and the authority.
3. List options considered. Describe 2–4 options that were seriously evaluated. Include the status quo or "do nothing" option. For each option, state the key advantage and disadvantage.
4. Present evidence for each option. For each option, list the evidence that supports or contradicts it. Evidence types: system data (logs, metrics), stakeholder input (interviews, surveys), precedent (past similar decisions), vendor documentation, pilot or test results. Label each piece of evidence with its source and date.
5. State the recommendation. One sentence: "We recommend [Option X] because [primary reason]." The recommendation must be explicit, not implied.
6. Provide the rationale. Explain why the recommended option is better than the runner-up. Reference specific evidence. Address the runner-up's strengths and explain why they are insufficient in this situation.
7. List the risks of the recommendation. What could go wrong if the recommendation is followed? Include probability, impact, and detection method. Do not hide risks to make the recommendation look better.
8. Define next steps. What must happen if the recommendation is approved? List actions, owners, and deadlines. Also state what happens if the recommendation is rejected.
9. Append the evidence. Include or reference the raw data, logs, or documents that support the evidence claims. A recommendation without appendices is a claim without proof.
10. Review for opinion leakage. Read the recommendation and highlight every sentence that is not backed by evidence. Rewrite or label those sentences as "judgment — not evidence-based."

Decision rules

• If the evidence for a critical claim is weaker than the opinion behind it, flag the claim as judgment and separate it from the evidence-based recommendation.
• If the recommendation is not the highest-scoring option from a prior analysis, explain why the highest-scoring option was rejected with evidence.
• If no evidence exists for a critical claim, do not make the claim — or state it as a hypothesis with a validation plan.
• If the "do nothing" option is not included, the recommendation may be solving the wrong problem. Always include it.
• If the risk section is shorter than the benefit section, the writer is hiding something. Lengthen the risk section.
• If the next steps have no owner or deadline, the recommendation is not actionable. Add owners and dates.
• If the decision-maker needs less detail, produce a summary page with appendices. Do not remove the evidence — move it.

Deliverables

• Recommendation Note — the primary artifact with situation, options, evidence, recommendation, rationale, risks, and next steps. See template below.
• Evidence Appendix — raw data, system logs, screenshots, reference call summaries, or vendor quotes that support the evidence claims.
• Executive Summary — one page for decision-makers who need the bottom line without the full analysis.
• Decision Record — what was decided, by whom, on what date, with what conditions or contingencies.

Templates

Recommendation Note

---
artifact: Recommendation Note
id: REC-001
date: YYYY-MM-DD
authority: "Who decides"
decision_deadline: YYYY-MM-DD
---

## Situation



## Decision Required


## Options Considered

### Option 1: [Name]
- Key advantage: 
- Key disadvantage: 
- Evidence: 

### Option 2: [Name]
- Key advantage: 
- Key disadvantage: 
- Evidence: 

### Option 3: [Name] (Status Quo / Do Nothing)
- Key advantage: 
- Key disadvantage: 
- Evidence: 

## Evidence Summary
| Option | Evidence Type | Source | Date | Finding |
|--------|---------------|--------|------|---------|
| Option 1 | System log |  | YYYY-MM-DD |  |
| Option 2 | Stakeholder interview |  | YYYY-MM-DD |  |
| Option 3 | Precedent |  | YYYY-MM-DD |  |

## Recommendation


## Rationale


## Risks of the Recommendation
| Risk | Probability | Impact | Detection Method | Mitigation |
|------|-------------|--------|------------------|------------|
|  | L/M/H | L/M/H |  |  |
|  | L/M/H | L/M/H |  |  |

## Next Steps (If Approved)
| Action | Owner | Deadline | Success Criterion |
|--------|-------|----------|-------------------|
|  |  | YYYY-MM-DD |  |
|  |  | YYYY-MM-DD |  |

## Next Steps (If Rejected)


## Evidence Appendix

Quality checklist

• The situation is stated with evidence, not just narrative.
• The decision required is explicit, with named authority and deadline.
• At least two options were seriously considered, including status quo.
• Every option has evidence with a source and date.
• The recommendation is stated in one explicit sentence.
• The rationale references specific evidence and addresses the runner-up's strengths.
• Risks are listed with probability, impact, and detection method.
• Next steps have named owners, deadlines, and success criteria.
• Opinion is labeled as judgment and separated from evidence.
• The evidence appendix is present or referenced.

Common mistakes

• Hiding the risks to make the recommendation look better. Consequence: the decision-maker approves without understanding the downside. When the risk materializes, the decision-maker feels deceived and trust is damaged.
• Confusing opinion with evidence. Consequence: the recommendation is challenged on grounds that cannot be defended. The writer retreats to "in my experience" instead of data.
• Not including the status quo option. Consequence: the project may be solving the wrong problem. The decision-maker cannot compare the cost of action against the cost of inaction.
• Omitting the runner-up's strengths. Consequence: the recommendation looks biased. A decision-maker who knows the runner-up's advantages will distrust the writer.
• Writing next steps without owners or deadlines. Consequence: the recommendation is approved but never executed. The note becomes a document, not a decision tool.
• Attaching evidence that does not match the claim. Consequence: a careful reviewer discovers the disconnect. The writer's credibility is damaged for future recommendations.

Weak output vs Strong output

Weak output

A paragraph stating: "We recommend Option B because it is the most robust and scalable solution. The team has extensive experience with this approach, and it aligns with our strategic direction. Option A was considered but does not meet our long-term needs. We should proceed with Option B as soon as possible."

Why it is weak: No evidence is cited. "Most robust and scalable" is unverifiable. "Extensive experience" is opinion, not data. "Aligns with strategic direction" is narrative bias. The runner-up is dismissed without addressing its strengths. There are no risks, no next steps, no owners, and no deadline. A decision-maker cannot approve this with confidence.

Strong output

A Recommendation Note with: (1) situation — "IDoc status 51 errors since 02:00 affecting 12 purchase orders, blocking warehouse operations; 40 receipts planned for weekend" with system log extract; (2) decision required — "CAB approval for emergency patch deployment outside standard release window by 14:00 today" ; (3) three options: emergency patch now (advantage: fixes root cause; disadvantage: non-standard window), wait for Monday release (advantage: standard process; disadvantage: 40 receipts blocked), manual workaround (advantage: no patch risk; disadvantage: 4 hours per 3 orders based on yesterday's data); (4) evidence: SAP Note 1234567 matches error pattern; manual posting took 4 hours; weekend schedule has 40 receipts; (5) recommendation — "Deploy emergency patch now with rollback plan" ; (6) rationale — "The root cause is identified and fixed by SAP Note 1234567. Waiting until Monday blocks 40 receipts at an estimated cost of €12,000. Manual workaround is not feasible at this volume. The patch has been tested in the QA environment." ; (7) risks: patch may affect other IDoc types (detection: post-deployment validation of 5 types; mitigation: rollback plan); (8) next steps: CAB approval by 14:00, deployment by 16:00, validation by 18:00, with named owners and deadlines.

Why it is strong: Every claim is backed by evidence with a source. The runner-up (wait for Monday) is treated fairly with its own evidence. The recommendation is explicit and actionable. Risks are visible and mitigated. A decision-maker can approve or reject with full information.

Agent instructions

AI Prompt Pattern

You are a recommendation writer. I will give you a situation, options, and evidence. Produce a Recommendation Note with: (1) situation with evidence, (2) decision required with authority and deadline, (3) options considered with evidence for each, (4) explicit recommendation, (5) rationale referencing specific evidence, (6) risks with probability, impact, and detection, (7) next steps with owners and deadlines. Do not use generic language like "robust," "scalable," or "strategic direction." Cite evidence for every claim. Label opinion as "judgment." Include the status quo option. State what happens if the recommendation is rejected.

• Separate evidence from opinion. Every sentence must be labeled as evidence (with source) or judgment (with owner). If it cannot be labeled, remove it.
• Always include the status quo option. The cost of inaction is a valid comparison point. Without it, the recommendation may be unjustified.
• Never hide risks. A recommendation with a short risk section looks suspicious. Lengthen it until it is honest.
• Address the runner-up's strengths. A recommendation that ignores the second-best option looks biased. Explain why its strengths are insufficient in this context.
• Never invent evidence. If data is missing, state "evidence not available — recommendation based on judgment and precedent" and flag it.
• Make next steps actionable. Every step needs a named owner, a deadline, and a success criterion. Vague next steps are not next steps.
• Link to Atlas diagnostics when the recommendation involves SAP processes or master data. For example, reference SAP Process Audit for evidence sources or Master Data Issues Blocking Sales Orders for situation context.

Related skills

• Trade-Off Analysis Working Skill
• Option Comparison Matrix Working Skill
• Architecture Decision Record Working Skill

Related Atlas pages

• SAP Process Audit — Source of evidence for process-related recommendations.
• Master Data Issues Blocking Sales Orders — Example situation with evidence and recommendation context.

Verification status and limitations

This skill is a public working interpretation of recommendation writing practices. It is not official BABOK, management consulting methodology, or SAP documentation. It focuses on practical recommendations in enterprise and SAP contexts.

Known limitations: the skill requires access to evidence, which may be scattered across system logs, stakeholder interviews, and vendor documentation. In environments with poor data availability, the recommendation will rely more on judgment and precedent — this must be labeled honestly. The skill does not cover formal decision theory, cost-benefit analysis, or investment appraisal methods (NPV, IRR). It assumes the decision-maker needs a structured narrative, not a financial model.