Cutting Customer Onboarding from Most of a Working Day to 10–20 Minutes
Stack
- React
- Node.js
- Express
On this page
Key results
- Customer onboarding, down from most of a day
- 10–20 min
- Routine customer operations
- Self-service
- Common admin requests, down from hours or days
- Minutes
Problem
Better Coaching is a multi-tenant SaaS platform that football clubs and academies use to manage coaching, players and training content.
As the number of customers grew, customer administration became the part of the platform that didn’t scale, because it depended on developers. Adding a new club meant a developer creating and preparing the tenant database, configuring the customer, setting up users and content, and making other platform-level changes. Onboarding one customer could take several hours or most of a working day.
The owners also needed a developer for recurring tasks such as:
- creating users and sending invitations;
- copying content between customer platforms;
- enabling or disabling modules for specific customers;
- publishing content shared across all customers;
- sending announcements and emails;
- making customer-specific platform changes.
None of these were hard to build. The problem was that every one of them needed a developer. With several new customers a month and steady requests from existing ones, both the owners and the team spent significant time on repetitive admin, and the business couldn’t run routine operations on its own.
The goal was to turn those technical procedures into safe, repeatable workflows the owners could run themselves, without anyone working directly with databases or production infrastructure.
My role
I was the team lead on this project. I set the direction for a dedicated internal admin platform and led the team through turning onboarding, and then a growing list of routine operations, into self-service workflows.
A key part of the role was recognizing that onboarding was only the most visible case of a wider pattern, and widening the platform’s scope to match.
Technical approach
A dedicated internal admin platform
We built a separate administration application with a React frontend, a Node.js/Express backend and its own authentication, apart from the customer-facing app. Access is restricted to Better Coaching’s owners, which keeps powerful platform-level operations away from normal customer functionality.
Instead of asking a developer to run a database operation or change configuration by hand, the owners do it through a controlled interface.
An informal developer process becomes a product workflow
Automating onboarding looked simple at first: the developers already knew the steps, so put them behind an admin UI. In practice, much of the onboarding knowledge lived with the developers, not in the product. Creating a customer touched tenant configuration, databases, users, content and platform setup, and the manual process worked partly because a developer could spot when something was off and adjust.
Once non-developers were running it, that judgement had to be built into the workflow itself.
The challenge wasn’t building an admin dashboard. It was turning developer knowledge into software.
Automating onboarding
At the time, each customer ran on its own branded platform with a dedicated database. The admin platform turned provisioning into a guided workflow where the owners can:
- create a new club;
- provision its tenant database;
- configure its platform subdomain;
- copy existing or predefined content;
- import users in bulk;
- invite users to the new platform.
Wildcard tenant routing meant a new club didn’t need its own DNS record, and bulk imports are validated so bad spreadsheet data doesn’t get written straight into the platform.
Content, modules and announcements
The same platform now covers routine customer administration. The owners can:
- create and manage users;
- send invitations;
- send announcements and emails;
- copy content from one customer platform to another;
- lock or unlock modules for individual customers;
- manage platform-specific functionality;
- publish content shared across all customers.
Decisions & trade-offs
The problem was bigger than onboarding
Once onboarding was self-service, the same dependency showed up everywhere: a user to create, a module to enable, content to copy, an announcement to send. Each request was small, but most still followed the same path:
- Owner identifies need
- Contacts developer
- Developer makes change
- Owner verifies result
The change itself was often quick. The communication, context switching and waiting took far longer. The bottleneck wasn’t one hard task but dozens of small ones repeatedly crossing the boundary between the business and the development team.
So instead of treating onboarding as an isolated feature, we widened the admin platform to cover recurring support tasks as well.
Results
Onboarding in minutes
A process that needed a developer and could take most of a working day is now usually done by the owners in about 10–20 minutes. New customers no longer wait for a developer to be available before their platform is ready.
Self-service operations
Routine customer management no longer goes through the development team. The owners spend less time explaining requests and waiting, and developers spend less time switching away from product work for repetitive admin.
Requests in minutes, not days
For most admin requests, the delay was never the technical change but the process around it: reaching a developer, context switching, making the change and reporting back. Depending on availability that took hours or days. As self-service operations, many now take minutes.
Operational independence
Developers are no longer a required step between a business decision and its execution. Instead of:
- Customer request
- Owner
- Developer
- Database or system change
many workflows are now:
- Customer request
- Owner
- Admin platform
That means faster customer operations, less production access, and room to support more customers without a matching increase in technical administration.