Lessons on uptake

Almost half the funded projects struggled to recruit rural participants. Here is what else slowed them down, what helped, and which survey figures to read with care.

Which barriers to engagement and uptake did the PoliRural+ open-call projects report, and what does D6.3 recommend for future calls?

The most common barrier was recruiting local partners and rural participants (47.6 %), followed by project windows of 3–9 months that were too short (42.9 %) and the administrative burden (23.8 %). D6.3 recommends consortium-backed stakeholder matchmaking, 9–12 month windows for Develop and Enhance, standard reporting templates from day one, and faster feedback channels to the core developers.

Barrier one: finding rural participants (10 of 21 respondents); trusted intermediaries such as LAGs and cooperatives help
3–9 month windows are too short for seasonal field tests; D6.3 recommends 9–12 months
100 % 'replicable' and 81 % 'will continue' are self-assessments, not proof
The stakeholder database is thin on infrastructure, digital-technology and finance actors

Open in the interactive book · missions, mini-games and memory cards there

Survey of 21 of the 26 funded open-call projects (D6.3): 47.6% struggled to find local partners and rural participants, 42.9% found 3-9 month durations too short and 23.8% cited administrative burden; low digital literacy and slow technical feedback were also named. Trusted local intermediaries and co-design with voice and chat AI worked; longer windows, standard templates and developer liaison are recommended. D5.1's change model adds that vision, skills, incentives, resources and an action plan must all be present.

What slowed uptake: lessons from 21 sub-grantees and nine stakeholder panels

main tellingdepth: standard3 min markdown

Paying for a tool does not mean people will use it. Two kinds of PoliRural+ evidence show where engagement and uptake ran into friction. The first is the beneficiary survey in D6.3 §4, answered by 21 of the 26 funded projects (80.8 %). The second is the stakeholder monitoring in D2.1 and D5.1. All survey figures are self-reported.

Four barriers named by the sub-grantees

Barrier	Respondents	What D6.3 recommends
Finding local partners and rural participants	47.6 % (10/21)	Allow lead time, work through trusted intermediaries (LAGs, farmer cooperatives), use offline formats; provide consortium-backed matchmaking and introductions to pilot partners
Windows of 3–9 months, too short for seasonal field tests and adoption	42.9 % (9/21)	Extend Develop and Enhance from 6–9 to 9–12 months
Reporting and administration	23.8 % (5/21)	Standard templates from day one, fewer intermediate deliverables, verification at milestones
Slow feedback loop with the JackDaw developers (Enhance call)	named, not counted	Liaison channels with the core developers: Code Camps, shared repositories, rapid issue-tracking sprints

Technical applicants also asked to be told, at application stage, how mature (at what technology readiness level) the core tools such as JackDaw were. Some wanted calls open beyond the nine pilot regions. D6.3 suggests keeping the pilot challenges but letting applicants from other regions with the same bottlenecks into the development calls.

What helped

Co-design reached across the digital divide. Conversational interfaces and voice input, combined with hands-on training such as product-photography and prompt workshops, reached older and non-technical producers. Every respondent formed new partnerships; 12 of 21 worked with more than five new organisations. Beneficiaries also asked for peer exchange between winners of different calls. D6.3 answers this with cross-call demo days and peer-learning webinars.

Reading the good news carefully

D6.3 marks the limits of its own numbers. All 21 respondents called their results replicable, but that is a self-assessment, not documented replication. 81 % (17 projects) intend to keep using their tools, which is a statement of intent, not evidence of lasting sustainability. D6.3 can show outputs and immediate outcomes; longer-term impact is left to D6.4.

The stakeholder side

D2.1 found a reasonable spread across stakeholder types, with three exceptions: infrastructure providers, digital technology companies and financial institutions. These are the groups that connect, build and finance tools, and the pilots are targeting them in the project’s second period. D5.1 adds a lesson from the Lippitt-Knoster change model: if incentives are missing, change meets resistance. Its Multi-Actor Approach Tool (MAATool) tracks KPIs and estimates how representative each pilot’s stakeholders are, so gaps like these show up.

For a future cascade-funding scheme, the first two fixes cost little: introduce sub-grantees to the Primary stakeholders of their pilot, and give field projects at least one full season.

Check yourself: Your region has €200,000 to pass on: how do you spend it?

A regional development agency outside the consortium has €200,000 of cascade funding. The goal is digital tools that local farmers, SMEs and municipalities actually use. It has one year and no existing tool of its own. Which design do you recommend?

A) “One big build” Give the whole sum to two or three development projects, so each team has enough money to deliver working software.

B) “A short ladder with support” Start with small outreach grants to map stakeholders and needs, then fund ideathons, then development grants. Introduce winners to the region’s key stakeholders and give field projects at least a full season.

C) “Open it to all of Europe” Publish one open theme with no regional challenge, to attract the most and best applicants.

D) “Test first” Fund several teams to validate and give feedback on a promising AI tool from elsewhere.

Each option has a defensible case. Choose one, then read why it works or where it breaks.

Feedback on each option

A) This puts the money where PoliRural+ spent most of its own (Develop took 67.8 %), but it skips the steps that found the users. Half the PoliRural+ sub-grantees said recruiting rural participants was their biggest problem, even with outreach and ideathons run first. A tool built without a mapped stakeholder base and agreed needs risks having nobody to use it.
B) The most defensible design. It copies the PoliRural+ ladder: cheap outreach grants build the stakeholder base and list of needs, ideathons turn them into concepts, and development builds against them. It also applies the fixes in D6.3: introductions to Primary stakeholders and windows of 9–12 months so field tests can cover a season. The cost is time, since the steps run in sequence.
C) More applicants is not the same as more uptake. D6.3 does suggest letting applicants from other regions with the same bottlenecks into development calls, but it keeps the regional challenge, because that challenge links each project to a Regional Action Plan. Without it, projects answer nobody's plan and leave no local network behind.
D) This works only if a mature tool already exists. PoliRural+ Enhance projects testing JackDaw asked for clearer statements of the tool's readiness level and for faster bug-fix channels to its developers. Testing also assumes local users are already lined up. With no tool and no stakeholder base, there is nothing to test and nobody to test it with.

Builds on: The open-call ladder
Builds on: The multi-actor approach