Reading an Evaluation Summary Report: How to Turn Rejection Feedback Into a Resubmission

A rejected proposal can become a stronger resubmission if you treat the Evaluation Summary Report as evidence, not as a verdict on the idea. Start by separating score problems from design problems, then translate each evaluator comment into a concrete edit. If the gap is mostly clarity, evidence, partner roles, and work plan logic, resubmit. If the gap is purpose, fit, target group, or consortium credibility, redesign before you write again.

Read the ESR as a decision record, not as feedback in prose

An Evaluation Summary Report, often called an ESR, is a compressed record of how assessors applied the call rules to your proposal. It is not a coaching note. It may sound vague because evaluators write under strict templates, across many applications, and within the language of the programme guide.

For Erasmus+ and Horizon Europe, the first task is to read the ESR beside the call text, award criteria, and your submitted PDF. Do not read it alone. A phrase such as “limited European added value” only makes sense against the exact expected outcomes in the topic. A phrase such as “implementation risks are insufficiently addressed” points to the work plan, the risk register, partner capacity, and sometimes the budget narrative.

Use three labels when you mark comments:

• Clarity issue, the idea may be sound, but evaluators could not see it quickly enough.
• Evidence issue, the claim needs proof, source material, user insight, or partner track record.
• Design issue, the project logic, consortium, activities, or target group does not fit the call.

The resubmission decision starts here. Clarity and evidence issues are usually fixable. Design issues need more caution.

Understand scores and thresholds before choosing your response

Scores are a signal about where the proposal lost trust. Thresholds are the formal line the proposal had to cross, either overall, per criterion, or both, depending on the scheme. Always check the call document and evaluator guidance for the specific rule, because the same word can carry different weight across actions.

Do not only ask whether the total score was close. A proposal can be near the total threshold and still have a weak criterion that will fail again unless the design changes. A proposal can also miss by a small margin because one section was hard to follow, while the core idea remains competitive.

Read each criterion as a different question:

• Relevance or excellence, does this project answer the call with a clear need, method, and expected change?
• Impact, will the right groups use the results, and is the path to uptake credible?
• Quality of implementation, can this consortium deliver the work, manage risk, and report cleanly?

A spring resubmission plan should not spread effort evenly. Put the most senior attention on the lowest or most threshold-sensitive criterion first. Cosmetic edits come last. If the ESR says the proposal lacks focus, rewriting the summary will not fix a scattered intervention model.

Translate evaluator language into edits

Evaluator comments often hide practical instructions inside polite phrases. Build a translation sheet before opening the proposal file. For each comment, write the likely concern, the affected section, the edit owner, and the evidence needed. This prevents the team from arguing over tone and pushes the work toward decisions.

A short worked example:

• ESR phrase: “The needs analysis is not sufficiently substantiated.”
• Likely concern: the proposal states a problem, but does not prove its scale, urgency, or relevance to the target groups.
• Concrete edits: add fresh desk evidence from the call context, include partner observations from their communities, separate EU-level need from local need, and show how each activity responds to one identified need.

Another example:

• ESR phrase: “The roles of partners are described unevenly.”
• Likely concern: some partners look decorative, or the evaluator cannot see why this consortium is the right one.
• Concrete edits: rewrite partner role paragraphs around tasks, not biographies. Add named responsibilities in work packages. Connect each partner to a user group, dataset, method, country access, or dissemination channel.

One more common phrase needs care: “Impact measures are generic.” This is rarely fixed by adding more indicators. It usually means the proposal does not show who changes behaviour, how results travel after funding, and which partner keeps the outputs alive.

Decide whether to repair, reposition, or redesign

After translation, sort the proposal into one of three paths. Repair means the same concept, consortium, and work plan can return with stronger evidence and clearer writing. Reposition means the idea is valid, but the call fit, target group, expected outcomes, or main narrative must change. Redesign means the consortium or intervention model is not credible enough for the programme.

Repair when the ESR points to missing proof, unclear sequencing, weak definitions, or thin impact planning. These are serious, but they do not destroy the project logic. Reposition when assessors question relevance, European added value, innovation level, or policy fit. Here, the first rewrite task is not language. It is a new concept note that states the call fit in plain terms.

Redesign when comments repeat across criteria. For example, weak needs analysis, vague partner roles, and unclear impact may be one problem: the project has not chosen a precise beneficiary and route to change. Adding paragraphs will make it longer, not stronger.

For an autumn rejection and a spring resubmission, set a short sequence: decision workshop, revised concept note, consortium role check, evidence pack, section rewrite, external review. StrandsUnited can support this as a focused proposal recovery sprint, especially where the work also needs a stronger digital delivery model.

Turn the ESR into a resubmission backlog

A resubmission fails when everyone edits their own section without a shared change list. Convert the ESR into a backlog with named actions. Keep it small enough to manage, but specific enough that progress is visible.

Use these backlog fields:

• ESR comment, copied exactly.
• Interpretation, what the evaluator probably could not verify.
• Decision, repair, reposition, or redesign.
• Proposal change, the exact section, paragraph, diagram, work package, or annex to amend.
• Evidence, the source, partner input, user insight, or past result needed.
• Owner, one person who can finish the change.
• Review test, the sentence a future evaluator should be able to say after reading.

The review test is useful. For a weak impact section, the test might be: “I can see who will use the outputs, why they will trust them, and which partner maintains them after the project.” For implementation, it might be: “I can see that each partner has a job that matches its capacity.”

Before submission, run a cold read. Give the revised narrative to someone who has not lived inside the proposal. Ask them to find the project need, main result, partner logic, risk response, and user pathway without explanation from the team.

Where this comes from

This advice comes from our work with EU cooperation teams that need digital platforms, knowledge systems, and credible delivery plans, not only nicer proposal text. At StrandsUnited, we maintain our consortium graph and grant intelligence engine across 83,490 projects, 738 grant calls, and 461,953 participation links from CORDIS and Erasmus+ open data. We also operate community platforms such as Impactful and build source-grounded AI assistants, data graphs, and member systems through our platform work.