How We Integrate ML Predictions Into Your Existing Software
Last updated:
A prediction nobody can see is worthless
The most common state of a business machine learning project that has stalled is a good model in a notebook. The data scientist is proud of it, the validation numbers are strong, and nobody in the business has ever seen a prediction. The last mile, getting the score into the screen where the decision is made, turned out to be a separate project nobody planned.
On SpiderHunts projects the destination is discussed in the first workshop, not the last sprint. Whether your CRM, ERP or order system can accept a new field, has a usable API or allows a custom screen affects the price and the design more than the choice of model does.
Three integration patterns
| Pattern | How it works | Best for | Trade-off |
|---|---|---|---|
| Batch scoring | A scheduled job scores all relevant records and writes results back | Daily or weekly decisions: chasing, reordering, retention lists | Predictions are hours old |
| Real-time API | Your application calls a prediction service and gets an answer in milliseconds | Decisions during a transaction: checkout risk, quote pricing | More to build, host and monitor |
| Event-driven | A new order, ticket or signup triggers scoring shortly after | Fast reaction without blocking the user | Needs a reliable event source |
Most business decisions do not need an answer in milliseconds. If the credit controller works through the list each morning, scores written overnight are exactly as useful as live ones and far cheaper to run. We explain the general trade-off in batch versus real-time AI integration.
Batch scoring: the unglamorous default
In a batch integration, a pipeline runs on a schedule, pulls the latest data, calculates the features the same way as in training, scores every relevant record and writes the results somewhere your existing software can read them.
- A custom field in your CRM, such as a churn-risk band with its top reasons
- A table in your database that your application or reports already query
- A column in the spreadsheet or BI tool people already open
- A daily list delivered to the right team in email, Slack or Teams
It is easy to test, easy to rerun if something fails and does not touch your application's performance at all. For a first model it is usually the right choice, even if real time is the eventual goal.
Real-time predictions, when they are worth it
When a decision must be made during a transaction, we package the model as a small prediction service, typically built with Python and FastAPI and containerised, which your application calls with the details of the case. It returns a score, a band and the main reasons.
The engineering that matters here is less about the model and more about behaviour under pressure. The service needs a strict time limit, so a slow response never holds up a customer. It needs the same feature calculations as training, which is where many real-time models silently go wrong. And it needs to scale with your busiest hour, not your average one.
The model is a component, not the centre of the system. Build it so your software carries on working the day it is switched off.
Fallbacks, boundaries and what the model may never do
- Always a fallback. If the prediction service is down or slow, your software uses the previous rule or a safe default and logs that it did.
- Recommend, then act. Predictions inform a person or a clearly bounded automated step; irreversible actions such as cancelling orders stay behind approval.
- A narrow interface. Your application sends the fields needed and receives a score; the model has no wider access to your systems.
- Replaceable by design. The model sits behind a service boundary, so a better one can be swapped in without touching your application code.
This is the same principle we apply to every AI feature, as set out in how we integrate AI into software you already have.
Log every prediction, with its version
Every prediction is logged with the inputs used, the score, the reasons, the time and the model version that produced it. Later, when outcomes arrive, they are joined back to those records.
That log is what makes the system supportable. It shows real accuracy over time, lets us answer “why did it flag this customer in March?” months later, provides training data for the next version and gives an audit trail for any decision that affects people. Without it, a model in production is a black box nobody can defend.
Integrating with systems that resist it
Not every system is friendly. Older ERPs with no API, hosted platforms that restrict custom fields, databases you are not allowed to write to. We have options for each: a scheduled import file the system already accepts, a side table your reports join to, a small companion screen linked from the main application, or integration through an automation platform you already pay for.
We find out which applies during scoping, because it changes the estimate. Integration work is often the largest single part of a machine learning build, and pricing it before looking would simply be guessing.
Frequently asked questions
Can machine learning predictions be added to our CRM?
Do we need real-time predictions?
What happens if the model service goes down?
Will integrating a model slow down our application?
Have a model that lives in a notebook?
Tell us where the predictions need to appear and what that system allows. We will tell you the simplest integration that would work, and what it would take.