Case study
A bookkeeping and payroll firm looking after about 1,800 small business clients in Ontario and Quebec now scores every account overnight, so a client manager opening a record sees the risk band and the three factors behind it without leaving the CRM.
Named only with client approval Figures marked are illustrative Reply within one business day
Forecast engine
Demand forecast - next 8 weeks
94.2%
Accuracy
+18%
Vs baseline
8w
Horizon
Retrained nightly on 14 months of order behaviour.
OlDevs built a client churn scoring system for a bookkeeping and payroll firm looking after about 1,800 small business clients in Ontario and Quebec.A model trained on billing history, support ticket patterns and client portal activity scores every client overnight, with monthly features assembled in a small Postgres feature store, and writes the score plus its three driving factors back into HubSpot as account properties. A daily view surfaces the twenty accounts worth a call, and what happens on those calls is logged and used to retrain the model each quarter. The firm reports −27% annual client churn and 2.4x retention call success, with 1,800 clients scored nightly.
Key facts
The challenge
Churn only became visible once a client stopped answering emails, which was usually a month after they had already decided to leave. Client managers had a shared spreadsheet of hunches and no way to rank 1,800 accounts by who needed a call this week. Two partners were effectively reviewing the book from memory.
A client going quiet was the first visible sign of churn, and by then the decision to leave had usually been made a month earlier. Every retention conversation started from behind, as a response to a departure rather than a reason to stay.
Risk lived in a spreadsheet of impressions that different client managers filled in differently and nobody maintained. It captured who had been thought about recently rather than who was actually at risk, and it went stale between updates.
With about 1,800 small business clients on the book, there was no way to order them by who needed a call this week. Attention went to the accounts that happened to be in front of someone, which is not the same as the accounts most likely to leave.
Two partners were effectively reviewing the whole book from memory, which does not scale and does not transfer. Their judgement was good and completely undocumented, so it could not be checked, shared with newer managers or applied consistently.
What we built
We trained a churn model on billing history, support ticket patterns and client portal activity, with monthly features assembled in a small Postgres feature store and every client scored overnight. The score and the three factors driving it are written back into HubSpot as account properties, so a manager opening a record sees the risk band and the reason without leaving the CRM. A daily view surfaces the twenty accounts worth a call, and what happens on those calls is logged and used to retrain the model each quarter.
The model was trained on billing history, support ticket patterns and client portal activity, all of it data the firm was already collecting. No new tracking was added and no client was asked to do anything differently for the system to work.
Monthly features are assembled in a small Postgres feature store, so training and nightly scoring read the same definitions. That keeps a score reproducible and makes it possible to explain later why an account looked risky in a particular month.
The risk band and the three factors driving it are written back into HubSpot as account properties. A client manager opening a record sees why an account is flagged without leaving the CRM, which is the difference between a score being used and being ignored.
A daily view surfaces the twenty accounts worth a call, so the working day starts from a list rather than a search. Call outcomes are logged against the account and used to retrain the model each quarter, so the list gets better with use.
Process
Defining churn
We started by agreeing with the partners what churn actually means for this book, since a client who pauses over a quiet season is not the same as one who has left.
Feature assembly
Billing history, support ticket patterns and client portal activity were shaped into monthly features in a small Postgres feature store used by both training and scoring.
Model build
The model was trained on those features and reviewed with the partners in a working demo each week, so the people who knew the book could see what it was picking up while it was still being built.
CRM write back
Scores, risk bands and the three driving factors were written into HubSpot as account properties, with a daily view surfacing the twenty accounts worth a call.
Feedback and retraining
Call outcomes are logged against the account and feed the quarterly retraining routine, which we documented and handed over with the code and the accounts.
Stack
Modelling
Data
CRM
Operations
−27%
Annual client churn
2.4x
Retention call success
1,800
Clients scored nightly
Outcomes
−27% annual client churn. Conversations now happen while a client is still deciding rather than a month after they have decided, which is the whole point of moving the signal earlier.
2.4x retention call success. Managers ring with a reason in front of them, so the call opens on something specific about that account instead of a general check in.
1,800 clients scored nightly means no account is out of view because nobody thought of it. Attention follows risk rather than following whichever client happened to be in front of someone that morning.
What two partners held in memory is now a score, a reason and a logged outcome that any client manager can act on. Newer managers work from the same signals rather than needing years to build the instinct.
In their words
Our client managers start the day with twenty names instead of a feeling about who has gone quiet.
Managing partner, small business accounting firm
Professional services
FAQ
They use this one because it appears where they already work. The risk band and the three factors driving it are written into HubSpot as account properties, so opening a client record shows the score and its reason without a second tool or a login. A score that lives in a separate dashboard is a score that gets checked once and then forgotten.
Because a number on its own does not tell a client manager what to say. Surfacing the three factors behind a score turns it into a call worth making, and it also lets an experienced manager overrule the model when they know something it does not. Explainability is what makes the score usable rather than merely correct.
No. This model was trained on billing history, support ticket patterns and client portal activity, all of which the firm was already collecting in the normal course of business. Nothing new was asked of clients, and the nine week timeline was possible partly because the data already existed and only had to be shaped.
Call outcomes are logged against the account and used to retrain the model each quarter, so what actually happened on a retention call becomes training data. Monthly features are assembled in a Postgres feature store shared by training and scoring, which keeps definitions consistent as the book grows and changes.
Access to the data, a working session to define what churn means for the book, and a few reviews with the people who will use the scores. We work in weekly demos, so partners and client managers see the model against real accounts as it develops rather than at the end, and the firm owns all code and accounts at handover.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.