How to Prepare a Findings-to-Recommendations Matrix

What a findings-to-recommendations matrix is

A findings-to-recommendations matrix is a structured table that connects:

1. evidence
2. finding
3. implication
4. recommendation
5. owner
6. action

It helps a report team show how recommendations were developed, which findings they respond to, and what evidence supports the logic.

It is not just a list of recommendations. It is the working table behind the recommendation section.

A good matrix helps the team answer:

• What finding supports this recommendation?
• What evidence supports that finding?
• What problem, gap, or risk does the finding point to?
• Who needs to act?
• What should change?
• How practical is the recommendation?
• Has the recommendation been reviewed?

The matrix sits between synthesis and writing. It helps turn analysis into report-ready recommendations without losing the route back to the source material.

When a report needs this matrix

A findings-to-recommendations matrix is useful when a report needs to move beyond description.

It is especially useful when:

• the report has many findings
• findings cut across themes, locations, groups, or source types
• recommendations need to be justified
• the report will go through donor, technical, public-sector, or client review
• the team needs to prioritise recommendations
• recommendations need owners or timeframes
• the report links to an action plan or implementation process
• reviewers may challenge the link between findings and recommendations

Common use cases include:

• evaluation reports
• UNICEF or donor-funded reports
• situation analyses
• policy reviews
• public consultation reports
• theory of change reviews
• programme reviews
• impact reports
• M&E reports
• strategy reviews
• organisational assessments

The matrix is most useful when the report has to support decisions. It gives reviewers and decision-makers a clearer view of how the evidence led to the proposed actions.

How it differs from an evidence table, quote bank, source register, and action plan

A findings-to-recommendations matrix works best when it is part of a wider evidence workflow. But it has a different job from the other tools in that workflow.

The source register tells the team what evidence exists.

The evidence table shows what the evidence says.

The quote bank stores selected excerpts that may support findings or report sections.

The findings-to-recommendations matrix asks a different question: what should happen because of these findings?

It is not the final implementation plan. It is the reasoning layer between evidence and action.

What should go into the matrix

The best matrix is simple enough for the team to use and detailed enough to support review.

A smaller report may only need finding, evidence, implication, recommendation, owner, priority, and review status. A donor-funded, public-sector, policy, or evaluation report may need a fuller version.

Here are the main fields to consider.

The field list should fit the project. Do not add columns nobody will maintain. But do include enough structure to make the recommendation traceable and reviewable.

Start with findings, not recommendations

A recommendations matrix should not start with the question, “What do we want to recommend?”

It should start with, “What has the evidence shown?”

A better sequence is:

1. Confirm the report questions. 2. Review the evidence table or synthesis outputs. 3. Write clear finding statements. 4. Check the source support for each finding. 5. Identify the implication of each finding. 6. Draft the recommendation. 7. Test whether the recommendation is specific, realistic, and linked to the finding.

This keeps the recommendations grounded.

It also helps avoid a common problem: recommendations that sound reasonable but do not clearly respond to the evidence. In a reviewed report, that gap matters. A donor, client, technical reviewer, or policy team may ask why a recommendation appears, why it has priority, or why a certain actor is named.

The matrix gives the report team a way to answer those questions before the report is finalised.

Turn findings into implications before recommendations

The implication step is where much of the real judgement happens.

A finding describes what the evidence shows.

An implication explains why it matters.

A recommendation says what should happen next.

This step prevents the report from jumping too quickly from evidence to action.

Without the implication, the recommendation can feel abrupt. The reader sees what the team wants to do, but not why that action follows from the finding.

The implication also helps the team choose the right recommendation. The same finding could lead to different actions depending on what the real issue is.

For example, inconsistent referral pathways could point to:

• unclear guidance
• weak district-level coordination
• poor staff induction
• missing service maps
• fragmented case management systems
• lack of monitoring data

Each implication leads to a different recommendation. The matrix helps the team make that reasoning visible.

Use evidence strength before making recommendations

Not all findings should produce the same kind of recommendation.

Some findings are strongly supported across several sources. Others are based on limited evidence, mixed views, or a small number of cases. The matrix should help the team adjust the recommendation accordingly.

This helps prevent overclaiming.

For example, if several interviews, field notes, and programme records all point to the same implementation gap, the team may be able to make a direct recommendation.

If one stakeholder raises a concern that is not supported elsewhere, the recommendation may need to be softer. It may be better to recommend further review rather than a major change.

The matrix gives the team a place to make those distinctions before recommendations reach the final report.

Separate recommendation types

Recommendation types make the matrix easier to filter, review, and prioritise.

Common categories include:

• policy recommendation
• programme recommendation
• service delivery recommendation
• coordination recommendation
• data and monitoring recommendation
• funding recommendation
• staffing or capacity recommendation
• communication recommendation
• safeguarding or risk recommendation
• implementation recommendation
• further research recommendation

This is useful because different people may need to review different types of recommendations.

A policy lead may need to review policy recommendations. A programme manager may need to review service delivery recommendations. An M&E team may need to review data and monitoring recommendations. A donor or senior leadership team may focus on funding, governance, and priority actions.

Recommendation types also help the team spot imbalance. If every recommendation is about coordination, but the findings point to staffing, data, and implementation issues as well, the matrix makes that gap easier to see.

Add owners, timeframes, and feasibility

A recommendation is weak if nobody can see who should act or how realistic the action is.

The matrix should help the team clarify:

• responsible actor
• level of action: local, district, national, organisational, donor, or programme
• timeframe
• feasibility
• dependencies
• risks
• resources required, where known

This does not mean the report team controls implementation. In policy, evaluation, public-sector, or donor-funded work, the team may only be able to suggest likely owners or actor types.

That is fine. The point is to make the recommendation more reviewable.

Compare these two recommendations:

The first version is broad. It does not say who should act, what should change, or how implementation might begin.

The second version is not perfect, but it is easier to review. The owner, action, level, and mechanism are clearer.

The matrix gives the team a place to test that clarity before the recommendation appears in the report.

Keep source traceability visible

A good findings-to-recommendations matrix should make it possible to move backwards:

1. recommendation
2. implication
3. finding
4. evidence summary
5. source IDs
6. source material

This matters because recommendations are often challenged during review.

A reviewer may ask:

• Which finding supports this recommendation?
• Which sources support that finding?
• Was the evidence strong enough?
• Were contradictory views considered?
• Why is this actor named?
• Why is this recommendation high priority?
• Why was this recommendation included instead of another one?

If the team cannot show where a recommendation came from, it may be weakened, removed, or rewritten without a clear basis.

This is where the matrix connects to the wider evidence system. It should use the same source IDs, finding IDs, theme labels, and report sections as the source register, evidence table, and quote bank.

The aim is not to make the workflow heavier. The aim is to stop recommendations drifting away from the evidence.

How this supports report review

A findings-to-recommendations matrix is useful before writing, but it becomes especially valuable during review.

It helps reviewers check whether:

• findings are supported
• recommendations respond to actual findings
• recommendations are duplicated
• recommendations contradict each other
• the right actor is named
• sensitive findings have been handled carefully
• recommendations are feasible
• recommendations are too broad or vague
• some findings have no recommendation
• some recommendations have no finding
• high-priority recommendations are justified

This is helpful for report leads, project directors, evaluation managers, and client teams.

It also reduces late-stage confusion. Instead of debating each recommendation only in the final report draft, the team can review the logic in the matrix first.

That makes the report easier to edit. It also makes it easier to prepare decision notes, recommendation summaries, validation workshop material, action-planning inputs, or implementation discussions.

Where AI can help

AI can support parts of the findings-to-recommendations workflow, but it should not replace the judgement behind it.

AI can help with:

• grouping findings by theme
• identifying repeated implications
• suggesting draft recommendation wording
• checking whether a recommendation is too vague
• comparing recommendations across themes
• finding overlap between recommendations
• turning matrix fields into draft report paragraphs
• preparing review questions
• checking whether every recommendation has a linked finding

AI should not:

• invent evidence
• create recommendations without source support
• decide final priorities
• ignore minority or contradictory evidence
• make political, legal, clinical, safeguarding, or technical judgements
• replace the evaluation lead, subject-matter lead, or report owner

The safest pattern is to use AI after the evidence base has been structured.

Give the tool clear inputs: findings, evidence summaries, source IDs, themes, evidence strength, and draft implications. Then use the output as a draft or review aid, not as the final recommendation logic.

People still need to decide whether each recommendation is valid, feasible, appropriate, and safe to include.

Quality checks before recommendations go into the report

Before recommendations are moved from the matrix into the report, run a QA check.

Use this checklist:

• Every recommendation links to at least one finding.
• Every finding links to evidence or source IDs.
• Recommendations are specific enough to act on.
• Recommendations do not overclaim beyond the evidence.
• High-priority recommendations have clear justification.
• Recommendations name a responsible actor or actor type.
• Timeframes are realistic.
• Dependencies are visible.
• Sensitive findings are handled carefully.
• Contradictory evidence has been considered.
• Duplicates are removed or merged.
• The report wording matches the matrix logic.
• Review status is up to date.

The check should be practical, not performative. If a recommendation cannot pass these questions, it may need to be rewritten, softened, merged, or removed.

Simple findings-to-recommendations matrix template

For a smaller report, start with this version:

For a larger report, use an expanded version:

Finding ID Theme Finding Evidence summary Source IDs Evidence strength Gap / risk Implication Draft recommendation Recommendation type Owner Timeframe Feasibility Dependencies Priority Report section Review status Notes

This larger version is useful when recommendations need to be filtered by theme, actor, priority, feasibility, or report section.

It also works well when the matrix feeds into a validation workshop, donor review, action plan, or implementation discussion.

What software can be used

For most teams, a spreadsheet is enough to start.

The tool matters less than the structure. The matrix needs stable IDs, clear fields, review status, and links back to the evidence.

Move to a database only when the matrix needs linked tables, filters, multiple reviewers, or integration with a larger evidence system.

For example, a larger project may have separate tables for:

• sources
• evidence extracts
• findings
• recommendations
• report sections
• review comments
• action-planning inputs

For a smaller report, that may be too much. A clean spreadsheet with consistent IDs may be the better choice.

Common mistakes to avoid

Most recommendation problems start earlier than the final report draft.

Here are the mistakes to watch for.

Need help linking findings to recommendations?

A findings-to-recommendations matrix is useful because it slows the team down at the right point.

Before recommendations go into the final report, the team has to check whether each one is linked to a finding, whether the finding is supported by evidence, and whether the proposed action is clear enough to review.

For evidence-heavy reports, that structure matters. It protects the report from vague recommendations, unsupported claims, and late-stage review confusion.

If your team has findings, source material, interview notes, submissions, case studies, or coded evidence but needs a clearer route into recommendations and report sections, I help build the evidence structure, findings tables, recommendation matrices, and reporting workflows behind the final output.