A digital work package in an Erasmus+ cooperation project names what the consortium will build and run online, who builds it, who operates it, and how use will be proven. To convince an evaluator it needs four things: deliverables with clear acceptance criteria, milestones that show progress before the final months, a named partner behind each deliverable, and indicators that measure use by the target group rather than raw traffic. Below is a worked structure, plus the two lines applicants systematically forget: who operates the platform during the project, and what happens after the grant ends.
In most cooperation partnerships, the digital work package carries three jobs at once: it produces project results (a platform, a knowledge base, a catalogue), it provides the infrastructure dissemination depends on, and it is the concrete answer to the sustainability question, because whatever survives after funding ends survives on this infrastructure or not at all.
Because it does triple duty, the WP has to cover the full life of the digital result, not just the build: specification, development, content production, operation, handover. Applications that describe only the build leave evaluators to assume the rest is unplanned, and they usually assume correctly.
Each term signals a different level of ambition, cost and risk to an evaluator.
Mislabelling cuts both ways: calling a few static pages a "platform" reads as inflation, and calling a system with accounts and workflows a "website" undersells the work and makes the budget look padded.
The example is a mid-size partnership whose main digital result is a knowledge base with a member area; adapt the numbering to your proposal.
Milestones worth writing in: specification approved, first release live, pilot cohort onboarded, knowledge base complete before the final reporting period, handover plan accepted by all partners. Each is checkable by an evaluator without interpretation.
One structural rule holds the WP together: every deliverable has exactly one named responsible partner. A WP whose deliverables all say "all partners" has no owner, and evaluators know what happens to unowned deliverables.
A usable indicator has three properties: it measures use by the named target group, it is attributable to the project, and it can be exported from the system as evidence. Indicators that pass this test:
Metrics that weaken the application: pageviews, impressions, "reach", social media followers, cumulative visit counts. They are not attributable, and they do not distinguish the target group from bots. If a number cannot be exported with a straight face at final reporting, do not promise it. Set per-indicator targets you can defend and state how each was estimated.
Between first release and the final report, someone has to run the thing: hosting and domain renewal, security and dependency updates, backups, uptime monitoring, content moderation, editorial upkeep, user support.
The fix is one explicit line in the WP description: the named technical partner operates the platform from first release to project end, covering updates, backups, monitoring and moderation, with effort allocated in that partner's budget. Its absence is visible to any evaluator who has watched a project platform go stale and insecure mid-project.
The dissemination section should point at the digital WP, not float beside it. Newsletters, multiplier events and social posts all need a destination that persists, and that destination is the platform or knowledge base this WP builds. Write the dependency explicitly: dissemination drives the target group to the digital result, whose indicators are how dissemination is measured.
Sustainability is the same move in the other direction. The standard weak answer, "results will remain available online", commits nobody to anything. The strong answer cites the handover deliverable: who takes ownership, the minimal operating arrangement, what stays live and what gets archived.
A work package that passes this list reads as written by a consortium that has operated a platform before. If yours lacks a partner willing to take both the build and the operating duty, that role is what we do.
StrandsUnited builds and operates this kind of infrastructure for EU projects and communities, including Impactful, a live community impact platform for the Founders community in Cyprus. We also maintain a consortium graph built from CORDIS and Erasmus+ open data for 2014-2027, covering 114,731 organisations and 83,490 projects; reading how funded projects describe their digital results is where these patterns come from.