An operator whose platform needed two people to operate it
Programme building, member progress and billing, operated by coaches rather than admins
The operator had bought a capable platform and then hired two administrators to operate it, because no coach could. Every programme change, every billing question and every new member passed through those two people, who became the bottleneck and the single point of failure at once. We rebuilt the parts coaches touch so that a coach is the operator, and the administrative layer stopped being necessary rather than being made more efficient.
The Client
An operator whose platform needed two people to operate it
Anonymised · NDA- Fitness · 12k members
- Egypt · United Arab Emirates
Coaches knew exactly what a programme should contain and could not enter one without help. The platform modelled a programme as a configuration object with forty fields, most of them irrelevant to any given coach, so the only people fluent in it were the two who used it all day.
Diagnosis
What was broken
- [01]
A programme was forty configuration fields, of which a given coach needed about six.
- [02]
Member progress lived in the coach notebooks, so it left when the coach did.
- [03]
Billing questions reached an administrator because no coach could see a member ledger.
- [04]
A paused membership was a manual process, so pauses were recorded late or not at all.
- [05]
Two administrators held the operating knowledge and neither could take leave at once.
- [06]
Nothing recorded how long a change took, so the bottleneck was argued about, not measured.
Business Impact
A programme change took three days on average, almost all of it waiting for an administrator rather than making the change. Coaches stopped asking for small adjustments, which is the expensive part: the product quietly became less personal than the business believed it was.
Why previous attempts failed
Previous work added training and documentation for the existing screens. The screens were not confusing; they asked for information a coach does not have, which no amount of training supplies.
Our Approach
How we solved it
Phase 01 of 04 · Time the bottleneck
01
Time the bottleneck
We instrumented the existing flow before changing it, timestamping each request from the moment a coach asked to the moment the member saw the change. The median was three days and the working time inside it was eleven minutes, which settled an argument that had run for a year.
Deliverables
- Request timing across the existing flow
- Median wait against median working time
- The six fields coaches actually set
02
Make the coach into the operator
A programme stopped being forty fields and became a template plus the six things a coach varies. The other thirty-four became defaults owned by the operator rather than decisions pushed onto whoever happened to be filling the form, which is what made the screen usable without training.
Deliverables
- Programme templates owned by the operator
- Six coach-facing fields, the rest defaulted
- Member ledger visible to the assigned coach
03
Put progress in the system
Member progress moved out of notebooks and into records attached to the member, so a handover between coaches stopped losing history. Pauses, restarts and plan changes became events with dates rather than states someone remembered to update, which is also what made billing agree with reality.
Deliverables
- Progress records attached to the member
- Pause and restart as dated events
- Coach handover that keeps the history
04
Retire the middle layer
Both administrators moved to member-facing work rather than being replaced, which was the point: the role existed to translate between coaches and a system, and the translation was no longer needed. Coach setup now takes under ten minutes with no one else involved.
Deliverables
- Coach onboarding with no administrator
- Runbooks and an on-call path they own
- Cloud and repository accounts in their name
End of approach
Scroll on for the results →
Scroll · 4 phases · pinned
Tech Stack
Tools & technologies
TypeScript · Node
Language
PostgreSQL · Drizzle
Data
Next.js App Router
Interface
Terraform · Actions
Infrastructure
Results
Quantified outcomes
< 10 min
Coach setup, unaided
Down from a three-day median, almost all of which was spent waiting
12k
Members on the platform
Each with a progress record that survives a coach handover
0
Administrators needed
Both moved to member-facing work rather than being replaced
6
Fields a coach sets
The other thirty-four became operator-owned defaults
Key Takeaways
What we learned
01
Training cannot supply missing information
The screens were not confusing. They asked a coach for thirty-four decisions a coach has no basis to make, and no amount of documentation changes that. The fix was moving those decisions to whoever actually owns them.
Useful when: Whenever a usability problem has survived two rounds of training.
02
Measure the waiting, not the working time
Three days of elapsed time contained eleven minutes of work. Optimising the eleven minutes was the obvious project and would have been worthless; the whole of the cost was in the queue, and the queue existed because of who had to be involved.
Useful when: Any process complained about as slow where the work itself is quick.
03
A default is a decision with an owner
Thirty-four fields did not disappear; they became defaults the operator sets once and changes deliberately. That is a stronger position than the original, because the decision is now made by someone qualified instead of by whoever opened the form.
Useful when: Simplifying any form that grew a field per edge case over time.
04
Removing a role is not removing the people
Both administrators moved to member-facing work. Saying so at the start is what made them willing to describe the job precisely, and their description is where the six-field model came from. A hostile source would have produced a worse product.
Useful when: Automating work whose current owners you still need to learn from.
FAQ
Frequently asked
01What happens when a coach genuinely needs a non-default field?
02How was the three-day median actually established?
03Did the two administrators lose their jobs in this project?
04Why rebuild rather than configure the platform they had?
05Why is this case study anonymised rather than named?
The closing thought
Ready to write yours?
Every project on this site started as an operational problem somebody had stopped expecting to fix. If one of yours sounds like this, that is the conversation to have.
Let's write yours.
Book a call- < 10 min Coach setup, unaided
- 12k Active members on the platform
- SiaSol · siasol.ai
Software products built in Egypt, Saudi Arabia and the UAE.