How to reduce duplicated admin in a charity

Start with a process that people recognise: a room enquiry, a meeting action or a routine activity update. Agree where it begins and what counts as finished. ‘Manage bookings’ may be too broad; ‘respond to an initial room enquiry’ gives you a clearer boundary.

Ask the people doing the work to describe what actually happens. A written procedure and the everyday process may differ. The aim is to understand the work and its constraints, including the informal steps people use to keep it moving.

For each step, record who acts, what information they need, where they find it and who receives the result. Include waiting, requests for clarification and corrections. Those steps are part of the process even when they do not appear in a formal checklist.

• Trigger: what starts the work?
• Owner: who acts at this step?
• Information: what is needed and where is it recorded?
• Handover: what tells the next person they can proceed?
• Completion: how does everyone know this piece of work is finished?

Repeated entry may be avoidable copying, but it can also support an independent check or a different reporting purpose. Understand the reason before removing it. Preserve necessary approvals, access limits and review responsibilities.

Look for repeated status questions, different versions of the same information and tasks that return because a key detail was missing. Choose one point of friction to investigate before trying to change the whole process.

This example is fictional and does not describe a Charity Egg client or measured result. A volunteer copies a room enquiry into a diary and a spreadsheet, then emails another person to ask whether it has been answered.

A useful first change could be agreeing where the current response status is recorded and who updates it. Test whether that removes the repeated status question before replacing the booking process. A reliable working record does not mean placing all information in one unrestricted system.

The change might be clearer information at the start, an agreed set of status labels or a named owner for the next action. State what the change is intended to improve, who will try it and when the team will review it.

Compare a small set of completed examples before and during the trial. Useful observations could include repeated entries, clarification loops, waiting time and corrections. Consider differences in the work itself before attributing a change to the new process. Do not claim a time or cost saving until there is evidence for it.

Ask the people involved whether the process is clearer and whether necessary checks still work. Record what to keep, what needs adjustment and who owns the updated way of working. If the trial creates a new problem, pause it and agree the next step.

Choose one repeated task this week. Write down where it starts, where it finishes and one avoidable repeat to investigate. A software decision, if needed, can follow an understanding of the process rather than becoming the starting assumption.