Case study · Operations

One person, three roles' work

From 2020 to 2022 I ran support, maintenance intake, inspections, turnovers and bills alongside marketing, while volume tripled. I kept it running with documentation and automation, then made the case to split it, and trained the people who took it over. Having my hands in all of it also gave me something lasting: a clear picture of how the whole operation fits together.

RoleOperations and support lead
When2020 – 2024
ToolsPhone system, Slack, property system, Front, Zapier
ScaleGrowing portfolio, small team
1,316
requests where I responded first
3×
task volume, 2020 to 2022
3
roles that later shared the work

The problem

Requests came by phone, email and Slack, with no single queue. Volume roughly tripled with no one added.

Constraints

No extra headcount

For three years the answer was to absorb it.

Many channels

Calls, inbox, Slack and the property system.

Seasonal peaks

August turnover months brought the heaviest volume of the year.

Key decisions

1

Document while doing.

Writing guides as I handled each process meant the next person wouldn't need me.

2

Automate the repeats.

Forms, reminders and notifications took routine follow-ups off the queue.

3

Make the case with data.

Response times stretched as volume tripled, and that evidence supported splitting the role.

Once the role was split, response times came back down sharply.
4

Train the successor properly.

A written training plan, live training and a help channel.

He passed my volume in his second month.

How it works

Requestsphone, email, Slack
→
Intakeforms + routing
→
Guidesso anyone can act
→
Split rolessupport, maintenance, accounts
→
Escalationme, on-call rotation
From one person absorbing everything to a team with a process.

Outcome

What it gave me

Running support, maintenance intake, inspections, turnovers and bills at the same time meant I saw how every part of the work connected. I knew where a request started, who it passed through, and where it tended to get stuck.

That context shaped everything I built afterwards. The core database, the automations and the internal tools were all designed around how work actually moves between people and departments, not how it looks on an org chart.

What I'd do differently