Which records convert, and why that one.
Conversion scoring trains on the conversions your own CRM already recorded, then scores every record from 0 to 100 with the fields that moved it. It is the family your agents call over MCP today.
In the product and live on the MCP surface today.
A conversion likelihood per record, on a scale you can rank.
The score is a number from 0 to 100: the model’s estimated conversion likelihood for that specific record. It is not a grade, and it is not a statement about how sure the model is of itself. A record at 84 is one the model places high in the ranking, based on how records with a similar profile behaved in your own history.
Bands sit on top of the number so a rep can read it at a glance: hot at 80 and above, warm from 50 to 79, cold below 50. You set the thresholds you route on.
Under the surface it is one model per objective, kept readable by its factors. Right company, right person, right time is how the features are built, not a promise of three separate answers: you get one score and the breakdown behind it.
Your conversions define the label. Nobody else’s.
You name the object that records a conversion, the criteria that have to be true on it, and the date field that says when it happened. That definition is the label the model learns, so the model learns your funnel rather than an industry average.
The quieter half is the non-success cutoff: for a record that never converted, where does the observation stop? Without a boundary, a record that sat in the CRM for two years contributes two years of silence and the model learns that silence is a signal. ax1om asks for that boundary instead of guessing it.
Training is first-party only. No third-party enrichment, no purchased intent, no pooling across customers. A first model can train on as few as 50 conversions.
The checks that run before a model becomes a score.
Leakage detection flags fields that give away the answer before training, because a field populated only after a record converts will produce a model that looks excellent and predicts nothing. Label-maturity handling catches outcomes too recent to learn from.
Validation gates every model, and the readout names what it found in plain terms: which fields were flagged, what the data supports, and where the model is thin. You approve a model before it becomes a running score, so the decision to trust it is yours and it is made with the findings in front of you.
Feature stability tracks whether the fields the model leans on are still behaving the way they did at training time, so a model that quietly stops matching your data shows it.
Every score arrives with the fields that moved it.
A score without a reason gets ignored. Score factors are the per-record answer to "why this one": a short list of the fields that pushed this record up or down the most, in your own field names, with the direction shown.
They are per record, not per model. The model-level view tells you which fields matter across the whole population; factors tell a rep why the lead in front of them landed where it did, including the reasons it is not higher.
The same factors ride the API response and the CRM writeback, so an agent acting on a score has the reasoning available in the same call a human would read on the record.
Consumed by your team
Scores land in the systems your team already works, not in a dashboard they have to remember to open.
The score writes to one field and the ranked factors to another, as a single line of text a rep reads on the record itself. A date field says how fresh the score is. Writeback needs a connected CRM.
A versioned live scoring API scores a record the moment it arrives instead of waiting for the next run: a batch endpoint for arrays and a single-record webhook endpoint that suits form handlers and automation tools. You mint keys in the product and enable API access per scoring route.
Export the scored population, or work it in the app: score detail, the ranked list, the factors view, and the model readout that says what the run actually found.
Consumed by your agents
Conversion scoring is live on ax1om’s MCP surface. An agent can check whether your data is ready, prepare a scrubbed export without anything leaving your org, train a model on your own conversion history, read the model quality in plain terms, and score records live with the factors behind each score on the response.
Agents authorize in the browser with per-user OAuth. You approve exactly what an agent may do, and you can revoke a grant at any time under Settings · Connected agents.
What operators ask about conversion scoring
How much history do I need before a model is worth training?
A first model trains on as few as 50 conversions. Whether that model is worth acting on is a separate question, and it is one ax1om answers by inspection rather than by a published floor: the readout reports what the run found on your data, and you approve the model before it becomes a running score.
What stops the model from learning a field that gives away the answer?
Leakage detection runs before training and flags fields that encode the outcome, which is the failure that makes a scoring model look excellent and predict nothing. The readout names what it flagged, so you see the finding rather than a silent pass.
Can my reps see why a record scored where it did?
Yes, on the record itself. The ranked factors write back alongside the score in your own field names, with the direction each one pushed, including the reasons a score is not higher. That is the difference between a score that gets worked and a score that gets ignored.
Does my data train anybody else’s model?
No. ax1om trains a dedicated model per customer on that customer’s own history: first-party data only, no third-party enrichment, no cross-customer pooling. Your models are yours.
How do scores stay current?
Activation turns a configured score into a standing job. ax1om recomputes it on the cadence you set and, where you have pointed it at a CRM field, writes the result back. The live API covers the records that cannot wait for the next scheduled run.
Train a scoring model on your own history.
Connect Salesforce, HubSpot, or a CSV, define what a conversion means in your CRM, and read the model’s findings before anything routes.