ATPL

AI · See and predict

Models trained on your data, for your decision.

For companies with a decision made thousands of times from their records: which lead to call, which order to check, which customer is about to leave. A model learns the pattern and scores each case.

Describe the problemAll AI capabilities

Rules ran out

When if-then rules ran out

Models trained on your records to make one repeated decision better.

Describe the problem

  • Rule

    You have years of records and a decision still made by gut feel, differently by each person.

  • Score

    Off-the-shelf AI does not know your products, your customers or your definition of a good outcome.

  • Drift

    You were sold a model once; it was never measured and quietly stopped being used.

How it ships

Define, train, monitor

  1. ml/01

    Understand

    We pull a sample of your records and check, before any modelling, that the outcome you care about is actually recorded.

  2. ml/02

    Design

    We write down the decision, the features allowed, the baseline and the acceptance measure, and only then choose the algorithm.

  3. ml/03

    Build

    The model scores cases in shadow mode for one business cycle; a person keeps deciding, and we compare the two.

  4. ml/04

    Stay

    Monthly accuracy reports from stored predictions and outcomes, with retraining when drift appears rather than on a fixed calendar alone.

A measured decision

Scores inside your workflow

  1. 01

    A defined decision and a measure

    One decision, one definition of success, and the number that tells us the model is better than what you do now.

  2. 02

    Training data from your records

    Features built from your database with leakage checked, so the model does not learn from something it would not know at decision time.

  3. 03

    A model with a baseline

    We start with the simplest method that works and only go further when the measure says so; the model file and the training code are yours.

  4. 04

    Scores inside your workflow

    The output is a score or a flag in the screen, sheet or report where the decision is taken, not a separate tool.

  5. 05

    Monitoring

    Predictions are stored with the eventual outcome, so accuracy is tracked over time and retraining happens on evidence.

Model or rule

Where it fits, where it doesn’t

Saying when this is the wrong tool is the fastest way to be believed about when it is the right one.

Fits when

  • A decision made many times, with the outcome recorded in your systems.
  • Enough history: thousands of past cases, not dozens.
  • A business measure you can state in one sentence: fewer returns, more conversions, less fraud.

Doesn’t fit when

  • Decisions with no recorded outcome; the model has nothing to learn from.
  • Rules you can already write down. If an if-then statement works, a model is slower and less clear.
  • Decisions that must be explained to a regulator case by case, unless the model is kept simple enough to explain.

Your data

Training runs on your data inside your infrastructure or a cloud account in your name; the trained model, the features and the code are handed over as yours. No records go to an outside model provider. Predictions and outcomes are stored so accuracy can be audited later.

Feature to score

Features become a score

The decision fields, the threshold and what a person sees when the score is unsure.

What a client typed

We get around two thousand enquiries a month from our website and trade portals and the sales team cannot call all of them, so they pick by instinct, and I would like to know which ones are likely to buy so we call those first.

Brief ready

What it becomes

Problem
More enquiries than the sales team can call, chosen by instinct.
Scale
Around two thousand enquiries a month; several years of enquiry and order history.
Systems
The website forms, trade portal exports, the CRM where outcomes are recorded.
First step
A lead score trained on past enquiries and their outcomes, shown in the CRM beside each new lead in shadow mode for one quarter.

How we work

ATPL builds machine learning the way it builds the rest of its software: a defined measure, a baseline, shadow mode, then ownership handed over. ATPL will confirm which models in production may be named.

    Chosen for the job

    Python · Node.js

    Decide the shape

    Before you start

    Plain answers on scope, data and what a first proof usually takes.

    Machine learning is the part of AI where a model learns patterns from your past records to score new cases, such as which lead will buy or which order will be returned. Generative AI, by contrast, uses large pre-trained models to produce text. ATPL offers both and chooses by the decision at hand.

    Thousands of past cases with a recorded outcome, as a rule of thumb; a few hundred is rarely enough to beat a simple rule. ATPL checks your records first and says plainly when there is not enough history, in which case the better step is to start recording the outcome now.

    Yes, if you record enough about customers over time: purchase frequency, support contacts, payment delays. ATPL trains a churn model on that history, scores customers monthly inside your CRM, and measures whether the people you then contact actually stay.

    The client does. ATPL hands over the training code, the feature definitions and the model file, trained on the client’s data in the client’s infrastructure, with documentation sufficient for another team to retrain it.

    Continue to