Predictive analytics that changes a decision, not just a slide
A prediction is only worth building if somebody will do something different because of it. We start from the decision and work backwards, and we say no when the honest answer is that a simple report would do the job.
What is predictive analytics?
Predictive Analytics is the practice of using historical business data to estimate future outcomes such as demand, customer churn or lifetime value, then feeding those estimates into an operational decision. It suits Australian organisations with several years of clean transaction history and a specific recurring decision, such as what to reorder or which accounts to call this week.
Get a fixed written quote- Typical timeline
- 10 to 20 weeks
- What drives cost
- The state of your data, the number of source systems that must be joined, whether the model needs to run continuously or monthly.
- Best for
- Recurring decisions with history behind them and a measurable cost of being wrong
- You own
- The models, the training code, the data and the deployment pipeline
- Built with
- Forecasting models, churn and propensity scoring, lifetime value estimation
Your handover
Three predictions that usually earn their keep
Demand forecasting is the most common. If you hold stock, every week you are implicitly forecasting, usually in a spreadsheet informed by memory. A model that reads several years of sales by product and location, accounts for seasonality, promotions, price changes and the school holiday patterns that differ by state, will typically beat that spreadsheet. The value is not the forecast itself. It is fewer stockouts on lines that sell and less capital sitting in lines that do not.
- 01Data readiness assessment with a plain recommendation
- 02Documented baseline the model must beat
- 03Trained models with validation against held out periods
- 04Evaluation stated in commercial terms
- 05Scoring pipeline running on a schedule
- 06Drift monitoring and alerting
- Retraining plan and documented model versions
- Explainability notes for scores affecting individuals
- Handover of code, data and deployment documentation
Churn prediction suits subscription and service businesses where retention drives profit
Churn prediction suits subscription and service businesses where retention drives profit. The model scores accounts by their likelihood of leaving in the next period, based on usage patterns, support history and payment behaviour, so a small team can call the twenty accounts most worth saving instead of the twenty that happened to complain. Lifetime value estimation, the third, tells you what a newly acquired customer from a given channel is likely to be worth, which changes what you are willing to pay to acquire the next one.
- Demand and inventory forecasting by product, location and season
- Churn and retention scoring for subscription or contract businesses
- Predicted lifetime value by acquisition channel and cohort
- Lead scoring so sales effort follows likelihood of closing
- Maintenance and failure prediction where sensor or service history exists
- Cash flow and revenue forecasting for planning cycles
The data you need before a model is worth building
This is the conversation that saves clients the most money, and it happens before any modelling is quoted. Forecasting seasonality honestly needs several years of history, because two years gives a model one repetition of the annual pattern and no way to distinguish a trend from a fluke. Churn modelling needs enough customers who have actually churned to learn from, and a clear definition of what churn means for your business, which is harder than it sounds for businesses without formal contracts.
Data quality matters more than volume
Data quality matters more than volume. If product codes were restructured in 2023 and history was not remapped, the model sees two unrelated products. If cancellations are recorded by deleting the record, there is nothing to learn from. We run a data readiness assessment first and give you a plain answer: build now, fix these three things and build in six months, or do not build this at all. Occasionally the assessment concludes that the real problem is upstream in how the CRM captures outcomes, and that is a cheaper thing to fix.
How the engagement runs
How a predictive analytics project runs
Every project starts with a baseline that is deliberately unflattering to us. What happens if you simply repeat last year plus a growth factor, or flag every customer whose usage dropped by half? Those naive rules are often surprisingly good, and any model we build has to beat them by a margin that justifies its cost and its maintenance.
- 01Frame the decisionWho decides, how often, what it costs to be wrong in each direction
- 02Data readiness assessmentHistory, quality, labels and the gaps that must be closed first
- 03BaselineThe simple rule or existing process the model has to beat, measured honestly
- 04Feature work and modellingBuild candidates, validate against held out periods rather than random splits
- 05Evaluation in business termsDollars of avoided stockout or accounts retained, not accuracy percentages alone
- 06PilotRun alongside the current process for a defined period and compare outcomes
- 07Deploy and monitorScheduled scoring, drift alerts, a retraining schedule and a documented rollback
Two decisions on your side that keep the project moving
We then work in short cycles with a genuine decision point at the end of the pilot. If the model does not clear the baseline by enough to matter, we stop and say so. That outcome is uncommon but it is not rare, and a project that ends early with a clear finding is a better result than one that ships a model quietly worse than the spreadsheet it replaced.
Accuracy, baselines and knowing when a model is good enough
Accuracy figures quoted without context are close to meaningless. A churn model that is ninety five percent accurate on a customer base with a five percent churn rate might be predicting that nobody ever leaves, which is accurate and useless. We evaluate against the decision instead: how many of the accounts flagged were genuinely at risk, how many at risk accounts were missed, and what each of those errors costs you.
More on accuracy, baselines and knowing when a model is good enough
That framing also tells you where to set the threshold. A retention team with capacity for thirty calls a week wants the thirty highest value at risk accounts, not every account above a statistical cutoff. A purchasing team facing long lead times from overseas suppliers may prefer to overstock, so the model should be tuned to be wrong in the cheaper direction. These are commercial choices, we make them with you explicitly, and they are written into the specification rather than left as a default.
Privacy, explainability and automated decisions
Predictive models built on customer data sit squarely inside the Privacy Act 1988 and the Australian Privacy Principles. Personal information collected for one purpose cannot be repurposed indefinitely without regard to what a person would reasonably expect, so we limit training data to what the decision needs and aggregate or pseudonymise wherever identity adds nothing to the prediction. Recent amendments to the Act also require organisations to be transparent in their privacy policies about automated decision-making that significantly affects individuals, with obligations taking effect from late 2026, so anything you deploy now should be documented with that in mind.
More on privacy, explainability and automated decisions
We also insist on explainability where a score touches a person. If a model deprioritises a customer or influences a credit related judgement, someone in your organisation must be able to describe why in plain language, and the score must never be the sole basis for a decision with a serious consequence. That means preferring models whose logic can be inspected, keeping a human in the loop, and recording which version of the model produced which score. Organisations in financial services carry additional obligations again and we scope those with your compliance team before building.
When predictive analytics is the wrong investment
If you cannot act on a prediction, do not buy one. Knowing which customers will churn is worthless without a team, a budget and an offer to retain them. Knowing demand will spike in November is worthless if your supplier needs five months of notice and you found out in October. We ask what the response will be before discussing models, and if there is no credible answer, the project should not proceed.
The other common case is skipping steps
The other common case is skipping steps. Plenty of organisations asking for prediction still cannot reliably report what happened last month, because the underlying data is inconsistent and nobody agrees on definitions. Prediction built on that foundation inherits every flaw and adds false confidence. Start with measurement and a reporting layer in Power BI or a similar tool, run it for a couple of quarters, and revisit prediction when the history is trustworthy. Businesses moving stock through warehouses and depots often find that the fix they needed was better inventory data, not a forecasting model, and that conclusion is the outcome of our assessment more often than you might expect.
How we scope it
Four ways to scope your Predictive Analytics project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Setup
Tracking that is correct, so the rest is worth reading
Fixed written quote, agreed before work starts
- Data readiness assessment with a plain recommendation
- Documented baseline the model must beat
- Trained models with validation against held out periods
Measurement build
The measurement your decisions actually depend on
Fixed written quote, agreed before work starts
- Everything in Setup
- Evaluation stated in commercial terms
- Scoring pipeline running on a schedule
- Drift monitoring and alerting
Full stack
Warehouse, pipelines and reporting across the business
Fixed written quote, agreed before work starts
- Everything in Measurement build
- Retraining plan and documented model versions
- Explainability notes for scores affecting individuals
- Handover of code, data and deployment documentation
Ongoing
Keeping it accurate as the site and the tools change
Rolling monthly, quoted in writing
- Tracking checked after every site or tool change
- A named person who knows the account
- Reports maintained as the questions change
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Working with us
Who owns the models and the training data?
You do. Training code sits in a repository your organisation owns, models are deployed into your cloud environment, and your data never becomes part of anything we reuse elsewhere. We document the model well enough that another data team can retrain and extend it. There is no proprietary layer of ours that has to keep running for the system to work.
Can you forecast demand for a seasonal business?
Yes, and seasonality is usually the easiest signal to model, provided you have several years of history covering it. The complications in Australia are worth naming: school holiday dates differ by state, public holidays move, and weather driven categories respond to conditions that vary across the country. We model location by location rather than nationally when your sales patterns justify the extra work.
Detail and edge cases
How long before we see a usable prediction?
Ten to twenty weeks for a first model in production, and roughly a third of that is data preparation rather than modelling. A pilot producing scores you can evaluate typically arrives around the halfway mark. Timelines stretch when history has to be reconstructed from multiple systems or when the definition of the outcome being predicted has to be agreed across departments first.
What makes one predictive project cost more than another?
The state of your data, the number of source systems that must be joined, whether the model needs to run continuously or monthly, and how much integration into existing workflows is required. Delivering scores into a spreadsheet is cheap. Delivering them into a CRM where sales staff act on them daily is a different scope. We quote in writing after the readiness assessment.
What happens when the model gets worse over time?
It will, and planning for that is part of the build. Customer behaviour shifts, product ranges change and an unusual year distorts the patterns learned from a normal one. We monitor prediction drift against actual outcomes, alert when performance falls below the agreed threshold, and set a retraining schedule. Most models need retraining periodically rather than continuously, and we tell you which yours is.
Do we need a data scientist on staff to keep this running?
Not for a well built scoring pipeline that runs on a schedule and alerts when something breaks. You do need someone accountable for acting on the outputs and for calling us when the alerts fire. Organisations planning several models over time usually benefit from an internal analyst, and we are happy to work alongside one, including handing over the parts we would otherwise maintain.
Related services
Start with a data readiness assessment
Describe the decision you make repeatedly and the data you hold behind it. We reply within one business day and tell you honestly whether a model will help.