Sales, Marketing & Ad Tech
Lead Scoring API
The scoring model in most CRMs is a points table somebody configured once. It ranks leads, but nobody can say whether a score of 80 means anything.
- CRM vendors
- Sales engagement platforms
- Marketing automation software
- Revenue operations teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Lead scoring in practice is a rules engine: ten points for a demo request, five for a target industry, minus ten for a free email domain. It was set up by whoever owned marketing operations two years ago, it has never been validated against outcomes, and the weights reflect a theory of the buyer rather than a measurement of one. The result ranks leads in roughly the right order and conveys no information about probability.
That matters because the decisions downstream are threshold decisions. Which leads get a call today, which go to a nurture sequence, which get routed to an enterprise rep. Making those with an uncalibrated score means either working too many leads or missing good ones, and nobody can tell which, because there is no measured baseline to compare against.
A proper model is not difficult, with one condition: it has to be trained on your outcomes. Conversion drivers differ sharply by market, price point and sales motion, and a vendor's pre-trained cross-customer model mostly learns the average of other people's funnels. The engineering challenges here are the familiar ones for this problem class — label leakage from fields filled in after the outcome, survivorship in the training set, feedback loops where the model's own prioritisation determines which leads get worked and therefore which convert.
Who buys this
CRM vendors, Sales engagement platforms, Marketing automation software, Revenue operations teams
What the API returns
What comes back
- Calibrated conversion probability per lead, not an uninterpretable points total
- Expected value where deal size is predictable, so a high-probability small deal does not outrank a likely large one
- Per-lead factor contributions, phrased for a sales rep rather than a data scientist
- Recommended action tier with the threshold and its expected precision
- Time-to-conversion estimates where the history supports them
- Score change events as new activity arrives
- Segment-level calibration reporting, so a model that works overall but fails for one segment is visible
- A holdout-based lift report comparing the model against your existing rules
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/leads/score | Score one or many leads |
| GET | /v1/leads/{id}/factors | Factor contributions for one lead |
| POST | /v1/opportunities/score | Win probability for open opportunities |
| GET | /v1/thresholds | Action tiers with expected precision and recall |
| POST | /v1/outcomes/ingest | Closed outcomes for retraining and calibration |
| GET | /v1/evaluation | Calibration and lift reporting by segment |
Request and response
illustrativeRequest
{
"leads": [
{
"lead_id": "lead_771204",
"created_at": "2026-10-20T14:02:00Z",
"source": "demo_request",
"company_id": "cmp_0441209",
"self_reported_role": "Director of Engineering",
"activity": { "pages_viewed": 11, "docs_read": 3, "emails_opened": 2 }
}
],
"include_factors": true,
"model": "inbound_mid_market"
}Response
{
"model": "inbound_mid_market",
"model_version": "2026.09",
"trained_on": { "leads": 184203, "period": "2024-01 to 2026-08" },
"leads": [
{
"lead_id": "lead_771204",
"conversion_probability": 0.23,
"calibration": "within 0.02 of observed on holdout decile",
"expected_value_usd": 4120,
"tier": "call_today",
"tier_threshold": 0.18,
"tier_precision": 0.31,
"estimated_days_to_close": 46,
"factors": [
{ "factor": "Requested a demo rather than downloading content", "contribution": "+0.09" },
{ "factor": "Three documentation pages read in one session", "contribution": "+0.05" },
{ "factor": "Company headcount in best-converting band", "contribution": "+0.03" },
{ "factor": "No named competitor in the account", "contribution": "-0.01" }
]
}
],
"baseline_comparison": { "existing_rules_precision": 0.19, "model_precision": 0.31,
"measured_on": "holdout_2026Q2" }
}Where the data comes from
| Your closed outcomes | Won, lost and disqualified records with dates — the labels, without which there is no model, only a rules table with extra steps |
| Your lead and activity history | Form fills, page views, email engagement and product trial events as they existed at the time of scoring |
| CRM field history | Needed to reconstruct what was actually known when a lead was new, which is the only honest way to avoid leakage |
| Firmographic enrichment | Industry, size and location attributes, either from your existing provider or from an enrichment layer |
| Sales activity logs | Calls, meetings and sequence steps — both as features and, critically, to model which leads were worked at all |
| Deal size history | Required for expected-value ranking; without it the model can only rank probability |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Point-in-time feature construction from field history, because scoring on fields populated after the outcome is the most common way these models look excellent and perform badly
- Explicit leakage audit on every feature, with a documented reason for each exclusion
- Gradient-boosted trees as the default, because the data is tabular, mixed-type and modest in volume — this is not a problem that rewards a neural network
- Probability calibration with isotonic or Platt scaling, validated per decile, since ranking without calibration cannot support a threshold decision
- Correction for worked-lead bias, modelling which leads were contacted so the training set is not just the ones the old rules liked
- Thresholds expressed as precision and recall trade-offs for the customer to choose, rather than a tier boundary we pick for them
- Segment-level calibration reporting across source, size and region, so aggregate performance does not hide a broken segment
- Scheduled retraining with drift monitoring on both inputs and outcome rates, plus an explicit check for feedback loops from the model's own prioritisation
What it changes for the business
Threshold decisions with numbers
Tiers defined by measured precision let a team decide how many leads to work rather than guessing at a cutoff.
Replacement of unvalidated rules
A measured comparison against the existing points table makes the case or kills it on evidence.
Reps who trust the score
Factor contributions written in sales language reduce the usual response of ignoring the number entirely.
Prioritisation by value
Expected value ranking stops cheap easy conversions crowding out larger slower ones.
How it fits into your product
How it embeds
- Synchronous scoring fast enough for lead routing at form submission
- Batch rescoring across the database after retraining or on a schedule
- Score-change webhooks into routing, sequencing and alerting
- Model-per-segment support, since inbound and outbound rarely share a model honestly
- Deployment inside your environment where CRM data cannot leave it
- Multi-tenant design for CRM vendors, with a separate model per customer rather than one pooled model pretending to be general
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you use a pre-trained model so we skip the data work?
We can, and it will be worse — usually enough worse to matter. Conversion drivers vary with price point, sales motion and market, so a cross-customer model learns an average funnel rather than yours. If you genuinely lack outcome history we would start with a transparent heuristic and collect labels deliberately, rather than ship a pooled model and present its score as if it were calibrated to you.
How much outcome data is needed?
A few thousand leads with at least a few hundred conversions is where a model starts beating a sensible rules table. Below that, variance dominates and you get a model that looks precise on a small holdout and does not hold up. We measure this on your data in the prototype phase and will recommend against the full build if the volume is not there.
Does a high score mean we will win the deal?
No. It means that among historically similar leads, roughly that proportion converted. A 0.23 lead loses more often than it wins. Calibration is what makes that statement meaningful, and we report calibration error per decile so the number can be checked rather than trusted.
What about the feedback loop problem?
It is real and most deployments ignore it. If the model prioritises a lead type, those leads get worked harder, convert more, and the next training run concludes the model was right. We correct for worked-lead bias in training and keep a small randomised holdout that is worked independently of score, specifically so the loop can be detected.
Will this tell us a lead is not worth contacting?
It will tell you the probability is low. We would be careful about building hard suppression on top of that, particularly where the low score is driven by firmographic attributes rather than behaviour — that is how a scoring model quietly becomes a policy of not selling to certain kinds of companies. Tiering plus a randomised sample of low scorers is a safer design and keeps the model honest.
Related blueprints
Company Enrichment API
Industry, size, locations, technology and firmographic attributes resolved from a domain or company name, with change detection.
Customer Segmentation API
Behavioural segments, propensity scores and audience classification computed from first-party customer data inside your own environment.
Buying Intent Intelligence API
Account-level signals that a company may be researching a category, with each signal's strength and basis stated rather than blended into a score.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.