A small admin workflow for a charity or volunteer group

A volunteer is about to hand over the equipment list for a week away. They know which entries need chasing and which apparent mistakes have perfectly sensible explanations. The spreadsheet does not.

Start an admin automation by sitting down with that person. In this worked example, the job is to prepare an equipment reminder for review. We use fictitious records and keep the first trial small enough to inspect together. Nobody needs to copy a real service user’s information into a demonstration to work out whether the idea helps.

Choose a job the volunteer can check

Start with something a volunteer can explain and check. This example prepares reminders for shared equipment checks. It is a planning exercise, not a report from a named charity. It does not assess service users, decide eligibility or handle safeguarding decisions.

Write down who currently prepares the list and where the due dates live. If there is no reliable register yet, agree the fields before connecting software. Automating an incomplete list makes omissions quicker, not easier to notice.

Use an equipment ID, description, next-check date and responsible role. Keep personal contact details in the system already approved for them, rather than copying them into every tool. A public demonstration should use invented sample records.

The trigger is a weekly schedule. Checks identify due items, missing dates and entries already included in this week’s draft. The action creates a reminder draft for the coordinator; a person decides whether and where to send it.

A named role owns failures and keeps the manual procedure. Document how another authorised volunteer can pause the workflow and prepare the list. Set a review date for access and remove access when responsibilities change.

For a missing owner, stop and ask the coordinator to correct the record. For an unavailable message service, keep the draft visibly unsent. Do not label it delivered because a backup was saved.

Use the Workflow Planner’s equipment-reminder example as a starting point. Replace its assumptions with your group’s decisions and export a copy for review. Avoid entering confidential information into a shared browser.

Test one item due now, one not due, a missing date, a repeated item and a service failure. Ask another volunteer to read the summary and explain the manual fallback. If they cannot, clarify the plan before building.

Ask the person doing the admin to draw it

Sit with the volunteer who prepares the equipment list and ask them to work through one ordinary week. Where do the dates come from? Which entries do they check by hand? What do they do when the responsible person is away? Write down the actual sequence, including the unofficial notes that make the current process work.

The aim is to reduce an agreed piece of effort. A volunteer may care more about remembering the right items than about saving a few minutes. Someone covering the task may need a clearer list of who to ask. Those are useful goals, and they lead to different outputs. Agree what would make the job easier before deciding whether a script, a spreadsheet rule or an existing reminder feature is the best fit.

Keep the first experiment within ordinary equipment admin. A group can learn about triggers and reminders without using service-user records or automating decisions about support. If the conversation moves into eligibility, safeguarding or other consequential judgements, separate that work and involve the people responsible for it. A successful reminder prototype does not establish that a different process is suitable.

Try five fictitious rows together

Make a sample register with five entries. One item is due this week, one is due next month, one has no date, one appears twice and one has no responsible role. Use invented descriptions and role names. Ask the volunteer to mark the expected outcome before you build anything. This small exercise often reveals what the words due and missing mean in practice.

For this example, the first item belongs in the draft reminder. The future item stays out. The missing date and missing role belong in a correction list. The repeated equipment ID should be flagged for review rather than creating two reminders. If the two repeated rows disagree, preserve both for the coordinator to resolve. Choosing whichever row happened to arrive last could hide a problem.

Now add an item that was checked yesterday but whose next date has not been updated. That is a process gap the software cannot infer away. Decide who records completion and who sets the next date. The automation can highlight the inconsistency, but the group still needs an agreed way to maintain the register.

Make the draft easy to act on

Group the output by responsible role, with the equipment ID, plain description and due date. Keep a separate section for corrections. The coordinator should be able to see what needs attention without opening every row in the original register. Include the period the draft covers so an old printout is recognisable.

A weekly draft may be all the automation needs to produce. The coordinator can choose an appropriate message and check whether someone has already dealt with the item. If you later add sending, retain a review step and distinguish a saved draft from a message accepted by the delivery service. Microsoft documents an approval step with a response check, but the group must still define who can approve and what they are agreeing to.

Use one stable item-and-period reference for each reminder. Running the process twice for the same week should find the existing draft. A separate run for the next period should create a new one only when it is due. Those rules keep a simple retry from turning into a burst of messages to the same volunteer.

Sources: Microsoft: create and test an approval workflow.

Keep access manageable when people change roles

Put the workflow under the group's agreed account arrangements, with another authorised person able to maintain it. Avoid a situation where the only working connection belongs to someone who has left. Record which services are involved and where credentials are managed, but never put passwords into the shared handover document.

The handover should explain how to pause the schedule, locate the source register, prepare the draft manually and identify the last completed period. Ask someone else to follow it while the builder watches. If they need an unwritten instruction, add that instruction before the trial is considered ready. This is a practical test of whether the automation belongs to the group rather than to one helpful individual.

Review access when responsibilities change. A person who helps edit a public guide may not need access to the contact register. Keep each part of the process small enough that these permissions remain understandable. Fewer copied lists also mean fewer places that need correction when somebody's contact details change.

Judge the trial against the job you wanted to improve

For a short observed trial, keep the normal process available and compare the draft against the manually prepared list. Record omitted items, unnecessary reminders and time spent correcting the register. Include setup and maintenance when discussing time savings. If the new process causes more checking than it removes, simplify it or leave the useful part as a manual template.

Ask the volunteers whether the output helped them act. A tidy file that nobody uses has not solved the problem. They might prefer one weekly checklist to separate messages, or need a clearer correction section. Make that adjustment before connecting another service. The people carrying out the work are the best source of the next improvement.

Bring the fictitious sample and the planning sheet to an Automation Clinic if you want help. You can explain the whole problem without exposing anybody's personal information. Leave with a smaller next step, an owner and a way to tell whether it worked. That is enough progress for a first community automation project.

Sources and further reading

• Microsoft: create and test an approval workflow. Primary documentation showing an explicit approval step and its outcomes.

Continue with

• Workflow automation: start with the job nobody wants to do twice
• Task automation: start with the small job you keep putting off