Skip to main content

Case study · Web application build

One portal, every venue: decentralising print ordering across a national estate

Powerleague runs a national estate of sports and leisure venues — and behind every venue sat the same small process, print ordering, routed through an external provider whose experience was clunky enough that a central team ended up handling orders for the whole estate. Veda Software designed, built and rolled out a self-serve portal that put ordering back where it belongs: at the venues.

Sector
National sports & leisure venues
Engagement
Portal design, build and estate-wide rollout
The system
A decentralised self-serve print ordering portal
In production
Venues order directly; the centre supervises without touching each order
Five-a-side football at a Powerleague venue

01

A national estate, a single point of friction

Powerleague's venues all need printed materials, and for years the route to getting them ran through an external print provider whose ordering experience was hard for venue teams to use well. The practical consequence was predictable: orders drifted back to the centre, where a small team checked, corrected and pushed them through on everyone's behalf.

Multiply that by a national estate and a weekly rhythm, and a minor process becomes a standing operational cost. Every order carried a manual step. Every manual step lived with the same few people.

Aerial view of a multi-pitch Powerleague venue
The multi-site sporting operation behind the ordering requirement.

02

Why the fix had to be built, not bought

There was no configuration of the existing route that solved this. The provider's front end was not designed around an estate: it had no concept of venue-level accounts, no permissions that mirrored how Powerleague actually delegates responsibility, and no workflow that let a non-specialist at a venue order confidently without the centre standing behind them.

That is the situation bespoke work exists for — not novelty, but fit. The requirement was specific, the operating model was specific, and the software had to be built around both.

03

Architecture before implementation

We started with the workflow rather than the interface. Before anything was built, we mapped how an order should travel through the estate: raised at a venue, correct by construction, visible to the centre, and flowing to the supplier without a manual relay in the middle.

That mapping settled the questions that decide whether a portal works in practice — who can order, what each venue can order, what the centre needs to see, and where fulfilment picks the order up. Only once that operating model was agreed did implementation begin.

Published comparison of Powerleague’s print-ordering workflow before and after the portal
The published workflow comparison: site access, ordering, proofing and fulfilment.

04

What we built

The result is a decentralised self-serve ordering portal, shaped by the estate's structure rather than a generic e-commerce template.

  • Multi-site accounts, roles and permissionseach venue orders under its own identity, seeing only what is relevant to it
  • An ordering workflow designed for venue teamsorders are placed correctly first time, without specialist knowledge or central rework
  • A supplier-facing floworders move from venue to fulfilment along one clean order-to-fulfilment path
  • An oversight layer for the centreestate-wide visibility and control without touching every individual order
Powerleague location access management
Published product artwork showing location-based access to the portal.
Branded print proofs prepared for Powerleague orders
Published product artwork showing branded proof generation.

05

Rolling it out across the estate

A portal only counts as delivered when the estate actually uses it. Rollout was treated as part of the engineering brief: the ordering experience had to be simple enough for busy venue staff to adopt without training overhead, and the centre kept its oversight role throughout the transition rather than losing visibility overnight.

Decentralising a process is as much an organisational change as a technical one — so the system was designed so that the safe path and the easy path are the same path.

06

What runs differently now

Venues order directly. The centre now supervises an order flow it no longer has to touch, and the order-to-fulfilment path runs cleaner, with fewer manual checks and relays between a venue needing something and the supplier producing it.

We publish outcomes on honest terms, so here is the honest version: conservatively, hours of repetitive weekly admin taken out of the centre. No invented percentages — just a system in production carrying the routine load that used to be handled by hand, and a portal that will take on new venues without taking on new admin.

What this proves

What the Powerleague build demonstrates

This is Veda Software's core pattern in one engagement: a specific operational requirement, an architecture designed around a real multi-site operating model, and a production system delivered through to estate-wide adoption.

  • Portal architecture shaped by a real multi-site operating model
  • Roles and permissions engineered for estate-wide self-service
  • An order-to-fulfilment workflow spanning venues, centre and supplier
  • Delivery through to rollout and adoption, not just release

Have a process that needs a system built around it?

If a routine workflow leans on one team to hold it together, the answer is usually architectural, not administrative. Tell us how the work flows today and we will show you how we would engineer it.