How The Auckland Project discovered its volunteers were an asset it had taken for granted.

The Sunday volunteer shift is approaching, and your team is happy because it appears that you have swerved all the headlines stating that volunteer numbers are down. Your rota is full. But something is nagging you about your last one-to-one with your volunteer coordinator.

The same faces are not coming back. 

That lovely, helpful volunteer who everyone relied on who did three shifts last season is ghosting your team. 

And that new recruit who came once, full of enthusiasm, and then disappeared.

At the last board meeting, it was brushed off as some version of post-pandemic choosiness, busy lives, or the cost-of-living crisis. These things might be true. But they are explanations for a pattern that no one has stopped to examine. 

But it still nags you because, despite your team’s happiness, something is afoot. You do not know why retention is dropping, and you realise it is because the system you have was never designed to tell you.

Auckland Project is a cultural heritage and regeneration charity in Bishop Auckland, County Durham. Its flagship programme, Kynren - An Epic Tale of England -  is an annual summer spectacular performed every Saturday by over 1,000 local volunteers known as Archers. The Archers are aged from five to eighty-eight and fill roles across performance, backstage, cavalry, visitor experience, and site operations, performing in front of 8,000 spectators per night over a ten-week season.

Michele Armstrong was the organisation's volunteer coordinator. She managed scheduling through a bespoke spreadsheet with pivot tables, whilst paper forms captured intake. And the completion of the rota depended on Armstrong’s personal knowledge of who was available and when.

Once The Auckland Project migrated to a volunteer management platform, Armstrong had a simple way of describing what changed. She was, as she put it, “more than just a spreadsheet guardian now.” 

For the first time, the data about who Armstrong knew was available to everyone in the organisation, and not just to Armstrong.

NCVO's most recent data shows that formal volunteering in England has fallen to its lowest level since records began. The proportion of adults volunteering at least once a month dropped from 27% in 2013/14 to 16% in 2023/24. In more deprived areas, including County Durham, where The Auckland Project operates, volunteers are significantly more likely to report having skills they would like to use in their volunteering but have not been offered the opportunity to do so: 18% in the most deprived areas, compared to 11% in the least deprived.

In a competitive volunteering market, organisations that retain volunteers will be those that can provide role fit, meaning work that uses the skills and experiences volunteers bring, rather than merely filling rota slots.

The Auckland Project's issue was an operational risk: a single person held all scheduling knowledge. If Armstrong was unavailable, the rota was in trouble, and the migration to the volunteer management software resolved that issue.

But there was a more significant problem underlying this. 

The spreadsheet was built to answer one question: Who is available this week? However, it was not built to answer a plethora of questions that elevate volunteer management from rota filling to a strategic volunteer programme, such as how many volunteers do we have across all roles? Which roles are chronically under-resourced? Which volunteers have skills the organisation has never used? Who has stepped back, and when and why? What do our volunteers want from this role, and are we offering it?

In a robust volunteer strategy, these are the sorts of questions that determine whether volunteers stay, and set up the environment that enables a charity to intervene before they leave. 

An organisation that can only answer 'who is on the rota' is flying blind on everything that retention depends on and is not generating intelligence about anything else.

Do you know enough about your volunteers to know whether you are wasting them?

Most volunteer coordinators address this problem by getting to know their people personally. And this becomes part of the charity's identity: volunteers are drawn to them, and that person becomes invaluable. 

But that is not a system. 

It is a dependency on one person's memory, and no matter the charity's size, it creates a blind spot. 

And this is a recognisable pattern throughout the charity sector, where charities have built volunteer programmes around one person’s memory, mistaking a functioning rota for a functioning volunteer strategy.

Auckland Project replaced paper intake forms with digital registration through its new volunteer management software. Existing volunteer records were migrated from the spreadsheet to the platform, and volunteers were granted self-service access to manage their availability and preferences. Scheduling moved from a manual, knowledge-dependent process to a system-supported one.

Armstrong's role moved from rota administration to strategic volunteer coordination.

The Auckland Project used software to achieve its goals, but the toolkit below does not rely on software, so it is applicable to both small and large budgets. A well-designed spreadsheet will be sufficient.

The volunteer register.

This is a record of who you have on your volunteer list, what they can do, when they were last active, and what they want from the role. This differs from the rota because it addresses questions about the volunteer population and requires effort to build and maintain it separately from the operational record.

The volunteer intake form.

Every field on the form is a question the organisation can rely on to build its volunteer strategy, as it captures skills, professional background, the type of role the volunteer wants, and what they hope to get from volunteering.

The quarterly population review.

A recurring fifteen-minute task, four times a year, where you look at the register and ask: Who has gone quiet? Which roles are undersubscribed? Which volunteers are being asked too often? What does the profile of the volunteers you have tell you about what you can offer?

The Auckland Project moved from a system that could answer 'who is on the rota this week?' to one that could begin to address 'what is the state of our volunteer programme?'

For the first time, the organisation could analyse its volunteer population using data. It could determine which roles were consistently under-resourced, identify volunteers whose skills had never been matched to suitable positions, and track those who had become inactive and when.

Efficient scheduling was what the migration promised. But what it produced was something more significant, because a trustee asking 'how healthy is our volunteer programme?' could, for the first time, receive an answer based on data rather than the coordinator's recollection. 

What remains unaddressed is more challenging: knowing who you have is not the same as understanding whether you are using them effectively.

The migration worked because it focused on changing the nature of what was captured during volunteer recruitment, not just a move from spreadsheets to more advanced software. 

The second factor was the separation of the rota from the register. Originally, they both sat within the same single spreadsheet created by Armstrong, which meant it was more challenging to draw out strategic conclusions from the data - the operational data crowded it out. In other words, the needs of this week’s scheduling were always more urgent than understanding more about who the volunteers were and what they needed.

For The Auckland Project, they decided that new software was right for them, but the same conclusions do not have to arrive for every charity. The fundamental learning from Auckland is less about the platform, but more about the questions. If the questions have not changed, neither has the system.

The most frequent failure of this kind of implementation occurs when organisations import their old data model into a new tool - carrying over the same intake logic, which in this case would have been only availability and emergency contacts. As a result, the new system may look different but cost more, and, worse still, it produces no new or useful intelligence about the volunteers. 

The second breaking point is the absence of a review habit. In the rush to implement, the habit of asking strategic questions gets designed out rather than in. The database needs someone to interrogate it on a schedule, or it remains an expensive record. 

The third concern is specific to organisations scaling their volunteer operation, because data problems do not disappear with growth. The Auckland Project is about to test this directly: Kynren: The Storied Lands, a daytime theme park on the same site, opens in summer 2026. The organisations best placed for that kind of growth are those that already know what skills exist in their volunteer population, which roles are under-resourced, and what their existing volunteers can absorb.

Most charities have not decided what they want to know about their volunteers because their systems reflect instead who was willing to organise and hold the knowledge. In The Auckland Project’s case, it was the coordinator with the spreadsheet. In yours, it might be the ops manager who can tell you off the top of her head which roles are always hard to fill. 

But that is not a system. It is a dependency, and it is fragile. 

The more challenging realisation is this: if retention rates are declining and the coordinator cannot identify the reasons for it, the organisation has been asking the wrong question. Instead of asking, "Who is available?" they should be asking, "Are we providing people with a reason to return?" These are two distinct questions that require different types of data. 

When retention decreases in your organisation, and someone asks why, what will your system be able to tell you?

Every week, a real ops problem from a real charity:
What they did, what it reveals, and what you can take back to your desk.
Sign up to get it in your inbox.