Scoring answers who. Timing answers when.
Timing predicts which of the coming twelve months each account is most likely to enter a buying cycle, and surfaces the standout months as an in-market window. It is in beta, and the label in the product says so.
In the product, in beta. Not on the MCP surface today.
A month-by-month picture of when an account comes into market.
For each account, Timing predicts the coming twelve months one month at a time, and the months whose likelihood stands out above that account’s own average become its peak months. That is the in-market window.
It is a separate model type with its own configuration and its own runs, not a modifier applied to a score. Scoring ranks records; Timing describes an account’s calendar.
Timing is in beta. It has been validated on synthetic seasonal data so far, not yet on live customer history. Treat the ordering it gives you as a planning input, not as a settled forecast, and sanity-check a sample against what your team already knows before you build a quarter around it.
One survival model across your whole book.
Each account’s history is expanded into a month-by-month timeline, and the model learns a monthly likelihood: the chance an account enters market in a given month, given it has not already. Those monthly figures compose into the curve the peak months are read from.
It fits one model across the whole book rather than a model per account, which is why sparse accounts are still covered: the model generalized from every account’s history, not by matching a thin account to named neighbours.
Dormancy and re-engagement are first-class here. An account that goes quiet for a year and comes back is a sequence the model can read as a sequence, rather than a single snapshot that reads as merely recent.
Never reading forward, and never scored as a negative for being new.
Features for any month are drawn strictly from events before that month, and the training data asserts it: a panel that could read forward fails to build rather than trains quietly.
Accounts that never had the target event carry through as open cases rather than as negatives, so an account that simply has not bought yet is not taught to the model as an account that never will. Partial months are dropped for every account alike.
Validation is temporal rather than a random split: the model is held to the most recent periods, which is the only split that answers the question Timing is actually asked. Where the data carries no real cycle structure, the calibration gate suppresses confidence rather than reporting an ordering it cannot support.
Confidence comes from evidence, not from a different model.
Every account is scored by the same model. What changes is how much evidence stands behind it. Accounts with rich history, roughly six or more events and at least two completed cycles, come back at high confidence. Three or more events gets medium. Sparse accounts are still scored, at low confidence, and their far-horizon months are faded rather than presented at full strength.
That is honesty furniture, not a hedge: the alternative is a thin account whose peak month looks exactly as certain as a well-documented one.
Because Timing answers with a month rather than a rank, its explanation surface is the confidence tier and the shape of the account’s own curve rather than a factor list per record.
Consumed by your team
Timing writes a date, which is the format the rest of your stack already knows how to filter on.
The peak month writes back as a real date field, so filters like this month or the next 30 days work natively in views your team already uses. Sample data cannot be written back; writeback needs a connected CRM.
Timing refreshes on a dispatched run rather than per request. It is a planning cadence, not a real-time call, and it is dispatched the same way every other run in ax1om is.
The account view carries the predicted window and its confidence tier, with the beta label attached where the number is read.
Consumed by your agents
Not over MCP today. Timing ships in the product on the same contract as the rest of the engine: your outcomes in, validation gate, prediction out. What agents call over MCP today is conversion scoring, end to end.
We will say so here the day that changes.
What operators ask about timing
What does the beta label on Timing mean?
That the machinery is verified end to end and the predictive quality is not yet proven on a customer’s real book. Timing has been validated on synthetic seasonal data, so the ordering it produces is a planning input rather than a settled result. The label sits in the product next to the number, not only on this page.
Is Timing a third score on each record?
No. Timing is a separate model type with its own configuration and its own runs, and it answers with a month rather than a rank. Scoring answers who; Timing answers when. They are not two halves of one number.
What happens to accounts with almost no history?
They are still scored, by the same model, at low confidence, and their far-horizon months are faded rather than shown at full strength. The model generalized from your whole book, so a thin account is covered; the confidence tier is how you know how much to lean on it.
Can I call Timing from an agent or from the API?
Not today. Timing refreshes on a dispatched run rather than per request, and it is not on the MCP surface. Conversion scoring is the family agents call over MCP right now.
See when your book comes into market.
Connect the CRM that holds your account history, run Timing, and read the confidence tier before you plan a quarter on it.