Its spreadsheets ran out at 100 members. One system took it to A$885K a year.
A members’ platform we ran turned over A$885K in its first full year. Two manual processes held it back: the admin, kept on spreadsheets, and the daily work, done by hand in every account. We rebuilt both as one system, connected to its CRM and accounting software. It saved more than 60 hours a week of admin, an estimated A$140K a year, and members on it made about twice as much as those working by hand.
- Business
- A members’ platform for bookmaker promotions, run by us: more than 400 members, each with accounts to fund and pay out.
- Before
- Spreadsheets, a weekly form and messages: every member’s money worked out by hand, and the daily work done by hand in every account.
- What we built
- A portal for every account and payout, connected to Zoho CRM, PandaDoc and Xero, and an engine and an app that automated the daily work, all custom and on AWS.
- Figures
- In Australian dollars, from the business’s own accounts and systems.
The short version
Every member’s balances and payouts were done by hand, and at about 100 members that became the bottleneck, because the back office had to grow with every member.
We moved the admin into a portal, later connected to the CRM, e‑signing and the accounting software, and the business grew past 400 members and A$885K of revenue in its first full year. Then we automated the daily work. By hand, some of it was missed and some was done late. An engine and an app then did it in every account, on time and within set limits, and members on it made about twice what members working by hand did.
- Revenue in its first full year
- A$885K
- Reaching more than 400 members
- Admin saved a year, at 400 members
- A$140K
- More than 60 hours a week, our estimate
- Profit per member, automated
- About 2×
- Against members working by hand
Bottleneck one
The admin couldn’t keep up
Every member was run by hand. Setting one up meant an agreement, bookmaker accounts and a spreadsheet, and every week their balances had to be collected and turned into a payout. That was about 10 minutes a member, every week.
By about 100 members it took two days a week, and the only way to keep up was to keep hiring. At 400, it would have been more than 60 hours a week: close to two full-time jobs, about A$140K a year.
So we moved the admin into a portal. Members updated their own balances, and the portal worked out every profit figure and payout and sent them to the accounting software. Later, the CRM took over onboarding and agreements.
The admin stopped growing with the members, and the business grew past 400 without hiring for those 60 hours. Reconciliations and payments took about an hour a week.
Members who had joined, running total
Bottleneck two
The work was done by hand
The portal made each member quick to run, but it didn’t change what each member made. That still came down to the daily work, done by hand: every member acting on a list sent out in advance, in every one of their accounts. Some of it was missed, some was done too late, and results varied with each member’s speed and care. That left money on the table in every account.
So we built software to do the work. An engine on AWS worked out what each account should do from live data, and an app on each member’s computer did it straight away. Every action carried its own limits, the app logged anything it skipped and why, and one change reached every member at once.
| By hand | By the system |
|---|---|
| Some of it missed, or done differently from the list | Done every time, as worked out |
| Done late, after the price had moved | Done on time, while the price held |
| One list, written in advance | Worked out for each account, from live data |
| Varied with each member’s speed and care | Checked against limits, with every miss logged |
Members on the system made about twice what members working by hand did, for about 20 minutes a week of their time, and nearly every member moved across.
The system
How the parts fit
Both fixes ran as one system, so a change in one place reached everything it touched.
Every part shown ran in production: the portal first, then the CRM, the engine and the app, and the new source of bets last.
How it was built
We designed and built it with a small team of developers. Most of the work went into the parts members never saw.
-
Custom software on AWS
The engine, written in Python, and the services behind the app ran on AWS. The app ran on each member’s computer, on Windows and Mac, and kept their logins on their own machine.
-
Built for deadlines
The work ran against a hard deadline every few minutes, so the engine recalculated on live data just before each one and the app acted straight away, sizing each action to its account.
-
Guardrails and logs
Every action carried its own rules: a floor, a limit and an expiry. If the data had moved past them, the app skipped it rather than act on bad data and logged why, so every result could be checked against what the engine expected.
-
Connected
The portal produced each round’s statements and payouts for Xero, and the CRM ran onboarding and follow-ups, with each agreement sent through PandaDoc and filed against the member.
Each tool did one job, and connecting them turned live data into work done in every account, through to each member’s statement and payout. We still work this way: we connect the tools that fit and build only where nothing does.
When the market changed, the same engine and app took on a new source of bets without a rebuild.
The result
What changed for operations
With the system in, the business grew past 400 members and about 2,000 accounts, and turned over A$885K in its first full year.
Its whole back office was budgeted at about 16.5 hours a week, and most of those hours went on members: answering their questions and bringing new ones on.
What it taught us
-
Build for change
The bookmakers kept moving, so every rule lived in one engine, and a change reached every member at once.
-
Own the code
The app’s code sat with one outside developer, so every change waited on one person. Everything we build now lives in the client’s own accounts, documented.
-
Reconcile from the start
The portal, the CRM and the accounts disagreed for months after launch. Now the numbers are reconciled from the first day.
-
Switch in waves
Members moved to the app in waves, starting with those doing worst by hand, with the old way running alongside until the new one had proven itself.
None of these lessons is about betting. They apply to any business that has outgrown its spreadsheets, and each part of the platform has a counterpart in a typical operations team:
| At the platform | In a typical operations team |
|---|---|
| More than 400 members’ balances, profit and payouts, kept in spreadsheets | Client accounts, commissions or job costs, kept in spreadsheets |
| A weekly form to collect every member’s balances | Figures chased by email, forms or a weekly reminder |
| Payouts worked out and reconciled by hand, every round | Billing, payouts and month-end reconciliation done by hand |
| Each round’s work sent as messages and done by hand in every account | Repetitive work done by people, one account or job at a time |
| A portal for every account, connected to the CRM, e‑signing and Xero | One source of truth from onboarding to payment, synced to the books |
| An engine and an app doing the work on deadline, with limits and logs | Rules-based automation with guardrails and an audit trail |
That’s what the process review is for: where the work waits in your business, what it costs and what to change first.
Apply for a process reviewNotes on the numbers
All figures are in Australian dollars, from the business’s accounts and its own systems.
- Revenue in its first full year
- A$884,705
- From the company’s profit and loss statement for its first full financial year.
- Members
- 436
- Member records on the platform at the peak, about 211 funded at once, across 24 bookmakers.
- Accounts
- About 2,000
- Member accounts listed on the platform around the peak: between 1,968 and 2,290.
- The portal
- At about 100 members
- The founders’ account of when the admin moved into the portal. The records show the weekly form still in use at about 60 members, the portal in use by about 400, and a new version of it later.
- Admin by hand
- About 10 minutes a member a week
- Our own estimate from running it, not a measured figure: about 30 minutes to onboard a member, one spreadsheet per member, and about 10 minutes a member each week to work through their balances. That is about 8 hours a week at 50 members, about 17 at 100 and about 67 at 400, close to two full-time jobs of 38 hours. At about A$40 an hour, wages and on-costs, the 67 hours come to about A$140K a year.
- Back office, on the system
- About 16.5 hours a week
- The business’s operations time budget once the portal and the CRM were running: the member chat 7.5 hours, onboarding and the sign-up pipeline 5, reconciliations 0.8 and payments 0.2, among others.
- The automated way
- About 2×
- Profit for members on the app against members working by hand, from the business’s own review a few months after the switch.
- On the app
- 119 of 128
- Members running the app at the last count.
- A member’s time
- About 20 minutes a week
- The business’s own estimate, on the app.
Apply
Start with a process review.
Tell us about the department, and we’ll start with a free call. If it’s a fit, we map how it runs with your own data, then show you, on a map and in writing, where the work waits, what each problem costs, what fixing it is worth and what to change first. Then we talk it through, and you decide. If you already have a plan or a prototype, say so, and we’ll start by checking it.