From CRM to score

What it represents

The rest of these articles come in two shapes. Some explain a single number or control: what AUC is, what the engagement panel does. Others walk you through setting up one kind of score, like won business or at-risk customers.

This one is the arc around both. Connecting a CRM through to a score landing in front of a rep, in the order you actually do it, so the other articles have somewhere to hang.

The path has three nouns and they are not interchangeable. A score is the business question you are asking, such as which accounts match your best customers. A model is one technical attempt at answering it. A run is one training execution of that model. One score can hold several models, which is how you give Enterprise and SMB their own model instead of one blurred average.

Everything downstream inherits from the score. Get the score’s definition right and a mediocre field selection still produces something useful. Get it wrong and no amount of field tuning rescues it.

How it’s calculated

Seven stages. The first four are yours, the fifth is ours, the last two are how the answer gets used.

1. Connect your CRM

   One authorization handshake with Salesforce or HubSpot, then a schema read. Credentials are encrypted at rest and the schema read catalogs your objects, fields, record counts, and how your data spreads across years.

   Nothing is copied into a warehouse. Every training run pulls fresh at run time, so there is no sync to keep in step and no second copy of your data to worry about.

2. Pick what you want to predict

   Four starting points on the Create a Score page, the rest behind one disclosure, plus a custom option. Each starting point fills in which object gets scored, where the outcome lives, and what counts as a win for that goal.

   Everything it fills in stays editable, and the form shows you the resolved definition before you save. What you read is what gets stored.

   Each of the four cards has its own guide covering that goal control by control, including the population it trains on and why. Read the one for the card you picked; this article stays at the level of the whole path.

3. Define what a win is

   Which stage or property marks a win, and which date field records when it happened. On an account score the win lives on the opportunity, so ax1om reads opportunities and labels each account by whether one of them converted.

   When an account has several opportunities, the earliest one matching your rule is the one that counts. Every linked opportunity is still counted for context, but a single match makes the account a success.

4. Decide how far back to look

   Records that converted are observed up to their own conversion. Records that did not need a boundary too, and picking a fair one is harder than it looks.

   Cutting every non-converter at today quietly breaks the model: converters get observed for however long they took, non-converters get observed for their whole lifetime, and anything shaped like tenure then separates the two by accident. ax1om instead draws a realistic time-to-convert from your own history for each non-converter, so both classes are observed for comparable stretches.

   Records that have not been around long enough to have converted yet are set aside rather than counted as failures. A young account that has not bought is not the same fact as an old account that declined.

5. Check the data before spending a run

   Saving the score starts a full data pull in the background, so dataset health is usually waiting by the time you open the model wizard. You get record and win counts, per-field fill rates, predictive strength per field, and duplicate-field warnings.

   The label to care about is Suspicious. A field marked suspicious predicts the answer almost perfectly, which nearly always means it records the answer rather than predicting it. Anything only filled in after a deal completes belongs out of the model.

6. Train and read the results

   A dedicated job pulls fresh, builds features, trains, and stores the artifacts. Progress shows in plain steps and finishes whether or not you keep the tab open.

   Read four things in order: how well the model separates wins from non-wins, how much better than random the top slice performs, how your records spread across the 0 to 100 range, and which fields drove the result. The first one that looks wrong is the one to chase.

7. Put the answer where the work happens

   Four ways out: written back onto the CRM record beside the reasons, refreshed on a schedule you set, called on demand from your own systems, or exported as a file.

   All four read the same explanation engine, so the reason a rep sees in the CRM and the reason the API returns are the same reason, computed the same way.

What the cutoff does to activity features

Stage four sets one date per record. That date is what every activity feature is measured against, and it is the reason those features describe the record as it was rather than as it is now.

Campaign and other engagement sources. Any touch dated after the record’s cutoff is removed before a single feature is computed, and the run logs how many were dropped. What survives becomes the counts you see:

• Total touches, and touches in the trailing 30, 60, and 90 day windows measured back from the cutoff, not from today.
• Days since first touch and days since last touch, both relative to the cutoff. A record whose last touch was the day before it converted reads as recent, even if that was three years ago.
• Response rates, where the numerator is pre-cutoff touches matching your filter and the denominator is that record’s total pre-cutoff touches of the same source. Both sides move together, so the rate cannot be distorted by activity the model should not see.
• Breakdowns by dimension, such as campaign type, over the same pre-cutoff windows.
• Recency weighting, where each touch is aged by its distance back from the cutoff.

The practical effect: a record with forty touches, thirty-five of them logged after it converted, trains as a five-touch record. That is correct. Those thirty-five touches are consequences of the outcome, not evidence for it.

Support cases and tickets. Case volume, case windows, and case recency are built by the same machinery as campaign activity, so every one of the count, window, and recency features above behaves identically for cases. A case filed after the record’s cutoff does not reach them.

Cases also carry measures the count features cannot express, because a case has a shape as well as a date: how long cases take to resolve, what share of them are still open, how often they escalate, and how they distribute across priority levels. Those describe the case history attached to the record rather than a trailing window of it.

Check your understanding

An account converted in March 2024. Since then your team ran it through an onboarding sequence of twelve emails, and support handled nine cases during the first year of the contract.

What does the model see? The campaign touches before March 2024, and nothing after. The twelve onboarding emails contribute nothing, because they happened because the account converted. Case counts follow the same boundary.

If that feels like throwing away good data, it is worth remembering what the model is for. It ranks accounts that have not converted yet, and none of them have an onboarding sequence or a support history. A model trained on post-conversion activity would look excellent in testing and would have nothing to read on a live record.

What it means for you

Spend your time on stage three, not stage five. Which records count as wins, and how far back you look, decide more about the result than any field you tick. Field selection is recoverable in an afternoon. A wrong definition of a win is not.

Filter the population, never the labels. If you want to focus on recent wins, narrow which records train, not which outcomes count. Narrowing the success rule does not remove your older customers from the model, it relabels them as failures, and the model then learns that accounts resembling your best long-standing customers are poor prospects. That is the opposite of what you asked for.

Treat suspiciously good results as a problem. A separation score above 0.95 on CRM data and a distribution piled into the top band are the same message twice: a field is telling the model the answer. Check the field diagnostics, find what got flagged, and check whether it made it into the model.

Building costs nothing. Training and every insight on the results page are available on every plan. You can define a score, train it, and see your own numbers before paying for anything. Delivery is the paid part.