Case study · Systems · Operating model design
The tools existed. The workflows didn’t.
Designing the systems behind the work.
A company that had grown quickly. Plenty of capable software, plenty of capable people, and an operational layer that hadn’t caught up with either.
Completing individual requests.Every application did its own job correctly, and every team knew its own part of the work.
Nobody owned the space between the tools.Requests were completed and handoffs were not. The coordination that held it together lived in people’s memory, which meant it worked exactly as long as the right person was available.
Who decides, and what the requester sees while they wait.Not the tool. The request model came first — what gets asked, who is responsible at each handoff, what happens next — and the platform was configured to serve it.
One requirement, rebuilt three times.External sharing access went from four human steps, to two, to a single decision — with the security control untouched throughout. The same move appears a decade earlier on a different stack, which is the part that makes it a method rather than an episode.
Everyone knew how to do their job. Nobody could tell you where a request went.
Every application worked. Licences were paid, systems were up, teams were competent. And the ordinary business of asking for something and receiving it ran on memory and goodwill.
- 01Knowing where a request went was tribal knowledge, not documented.
- 02Approvals were coordinated by hand, person to person.
- 03Small requests generated conversations instead of resolving.
- 04The systems worked individually. They didn’t work as one.
A ticketing platform was the visible project. An operating model was the actual one.
Replacing one tool with another moves the same problems into a newer interface. The work was deciding how requests should behave — what gets asked, who decides, what happens next, and what the requester sees while they wait.
Recreate the existing queues in a new tool. Import the fields. Keep the habits, change the logo.
A request model built from how people actually ask for things — then the tool configured to serve it.
Owned end to end — business requirements · request types · form and field design · workflow logic · approval paths · notification design · automation · systems integration
Connected surface — ticketing platform · asset management · identity and directory · workspace and collaboration
Status — designed and running in a controlled environment; production migration in preparation, not yet live
External sharing access, in three versions.
Sharing a folder outside the company requires approval. That control is correct and was never in question. The workflow holding it up was the problem — it depended on a person being available.
What follows is the same requirement, redesigned twice. Read the left edge of each step: red is a human doing it by hand.
Human steps — four · waits on someone being available
Human steps — two · the adding stopped being a task
Human steps — one decision · nothing is coordinated by hand
Manual action became automation. Automation became a system. The security control never changed — only the experience around it did.
A CRM that people were told to use, made into one that helped them work.
Years before any of the above, in a different company and a different stack. The pattern is the point — this is not a thing he started doing recently.
- Custom fields shaped to the actual work
- Workflows matched to how requests really moved
- Dashboards for the people making decisions
- Reporting that answered standing questions
- Data cleanup so the system could be trusted
The goal was never to make people use the tool. It was to make the tool work the way people already did.
The tools changed. The pattern didn’t.
Different companies, different stacks, more than a decade apart. The work was the same each time: find where people, process, and software are rubbing against each other, and design the thing that removes the friction.
That work is not administration. Administering software keeps it running. This decides how the work should move — and then builds it.
Employer and product names withheld · systems described by function · no confidential interface, data, or architecture shown · no metrics claimed