Case study: unplanned leave for a 1,000-person care provider, built on Google Workspace

This is a case study from a live engagement. The client is an Australian disability services provider with more than 1,000 staff across many sites. We have left out the name and the exact locations, as we do with every client, and kept the shape of the problem and the system as they actually are. The finance lead who commissioned it reads this page too.

The problem, as the people doing it described it

When a support worker could not come in, the request travelled by phone call, text message, or email to whichever manager picked up. The manager then had to find the right person to approve it, tell rostering, and remember to tell payroll. On a busy morning the same request could be approved twice by 2 managers, or by nobody. Nothing was written down in one place, so the monthly leave picture was assembled by hand from inboxes.

The finance director wanted 3 things: every request captured once, every approval routed to the right person with a record, and no new subscription to buy or migrate to later. The organisation already ran on Google Workspace, and staff already had Google accounts. That constraint shaped the whole build.

What we built

A web application inside the client's own Google Workspace, written in Apps Script with a Google Sheet as the operational database and Google's own identity for sign-in. No external hosting, no third-party data processor, no monthly fee to us. Apps Script became a Workspace core service in June 2026 with enterprise-grade data protection, and in September Google made data regions generally available for it, so the compliance story for a health-adjacent organisation is now Google's story rather than ours.

• Staff lookup that searches across more than 1,000 employees as you type. Native drop-downs were unusable at that scale, so the lookup is a custom autocomplete that returns the right person in 3 keystrokes.
• Routed approvals: the request goes to the approver for that person's outlet, with a notification, a one-click decision, and an automatic escalation path when nobody responds.
• Roles: requesters, approvers, and system admins see different screens and can do different things. Admins manage the lists without touching code.
• An audit trail: every request, decision, and edit is written with who did it and when. The monthly picture is a filter, not a reconstruction.
• A design system shared with the client's other internal tools, so it looked like theirs on day 1.

The hard parts

The first hard part was not technical. An approval system encodes who is allowed to decide what, and in a 1,000-person organisation that map is never fully written down. We spent the first weeks with the people who handle leave today, drawing the routing on a whiteboard and finding the exceptions: the outlet with 2 managers, the region where the coordinator approves instead, the after-hours rule. Every one of those became a row in a configuration sheet the client can edit, not a branch in code.

The second was scale inside a spreadsheet-backed app. A thousand employees, thousands of requests a year, and managers opening the app on phones in the field. That meant caching the employee list, paginating the history, and keeping every screen under a second on a mobile connection. It is possible in Apps Script, but only if you design for it from the start rather than optimise later.

The third was rollout. We piloted at 1 site from July 2026 with the managers who had asked for the tool, fixed what they found, and only then widened it. The pilot surfaced 2 approval paths nobody had mentioned in scoping. That is what pilots are for.

The best sign a system works is that people stop talking about it. Requests go in, decisions come back, payroll has the record. Nobody chases anyone.

What the client owns now

The application, the code, and the data all live in the client's Google account. Their IT lead can publish a new version. The runbook explains what to do when something needs a decision, and the configuration sheets let the admin team change routing without us. A follow-on tool for roster optimisation was commissioned on the strength of it, which is the outcome we care about most: the first system earned the second.

If your organisation runs on Google Workspace and a recurring process still lives in phone calls and inboxes, this is the shape of the fix. Tell us the process in 2 lines and we will tell you honestly whether it wants a system like this or something simpler.