A trial-to-paid model is not a dashboard chart and it is not a sales dashboard filter. It is a predictive signal that scores every active trial on the probability it converts, and it is the operating layer that decides which trials get a sales touch, which get a nurture email, and which get left alone to self-serve. Teams that build this well compress their sales cycle and raise their trial-to-paid rate without raising headcount, because they stop guessing which trial is hot. This guide walks the full arc of building the model: defining the events, pulling the cohort history, segmenting by signup source, fitting a signal, scoring trials daily, triggering sales on the hot ones, nurturing the cold ones with product-led content, and iterating monthly.
Time: 2-3 weeks setup, ongoing
Before you fit any model, write down the two outcomes it is trying to predict and the signals it is allowed to use. The conversion event is the clean one: a trial converts to paid when the billing system records a successful first charge or an executed order form against the trial account. Write it down as a boolean on the trial record, not as a derived field in a dashboard, because the model will join against it dozens of times. The activation event is the leading indicator and it is the richest input the model will have. Pick two or three in-product events that pattern-match to what paid customers do in their first session, and instrument them cleanly in the analytics tool. OpenView PLG and ProductLed research both land on the same point: products that explicitly define activation and conversion as named events outperform products that leave them implicit, because the model is only as good as the labels it learns from.
The model learns against history, so the next step is to build a clean cohort table that joins every trial from the last ninety days to its final paid outcome. One row per trial, with the signup timestamp, the signup source, firmographic fields from your enrichment provider, every activation event with its timestamp relative to signup, and the paid-conversion boolean. Ninety days is the minimum because shorter windows do not give the slow-converting trials time to resolve, and because the signal you want to find is the difference between a seven-day converter and a thirty-day converter. Appcues trial research and Reforge PLG research both call out the same discipline here: the cohort table is the artifact the whole program depends on, and teams that build it as a view in the warehouse rather than as a one-off query ship a durable model, while teams that pull it ad hoc find themselves rebuilding it every month.
Before you fit a model, segment the cohort by signup source and look at the base-rate conversion for each. Organic signups, paid signups, referral signups, and existing-list signups usually convert at wildly different rates, and a single global model will quietly bias toward whichever source dominates volume. The segmentation step is the one most teams skip and the one that pays off the most, because it tells you whether you need one model or several, whether paid acquisition is converting below its channel baseline, and whether a specific referral source is doing the work the sales team thinks the product is doing. OpenView PLG benchmarks are consistent that trial-to-paid rates vary by source by multiples, not by percentage points, and that any model fit without the segmentation is modeling the channel mix as much as the user behavior.
The first version of the model should fit on an index card and should combine three families of inputs: fit, activation, and engagement. Fit is the firmographic layer: company size, industry, geography, and ICP match from your enrichment provider. Activation is the event layer: whether each activation event fired, how fast, and in what order. Engagement is the depth layer: sessions per week, seats invited, data imported, and the volume of core-workflow runs. Fit a logistic regression or a gradient-boosted tree against the paid-conversion label, and keep the feature set small enough that every input is explainable in a sentence. Reforge PLG research is clear that the first version of a PQL or trial score should be interpretable, because the sales team has to trust it to act on it, and a model that cannot be explained to a rep will be routed around no matter how accurate it is.
A model that runs once a week is a report. A model that runs every day and writes a score to the CRM is an operating layer. Set up the scoring job to run every twenty-four hours against the full set of active trials, write the score to a stand-alone field on the trial or lead object in the CRM, and attach the top contributing features so the rep can see why. The frequency matters because trials are a time-boxed asset: a trial that becomes hot on day five of a fourteen-day window needs a sales touch within hours, and a weekly batch loses half the window to lag. Appcues trial research and ProductLed benchmarks both call this out: the lift from a daily scoring cadence over a weekly one is larger than the lift from most model-quality improvements, because latency compounds inside a short trial window.
Once the score lives in the CRM, the next job is to wire the triggers. Define the hot threshold against the validation holdout, usually the top ten to twenty percent of active trials by score, and route those trials to a named rep rather than a round-robin queue. Agree on an SLA for first touch, typically under two business hours during business days for a hot trial, and track SLA adherence weekly for the first ninety days. The point of the sales touch is not to sell at the user; it is to show up with context, because the model has already told you which activation events fired, which friction points are showing up in the session data, and which firmographic signals matter. OpenView PLG and Reforge both call out the same discipline: a product qualified lead program dies when sales treats a PQL like a cold inbound, and it compounds when sales treats a PQL as a warm conversation that the product has already opened.
The majority of trials will never be hot, and that is correct. The job for the low-scoring segment is to run a product-led nurture program that keeps the activation events in reach and that surfaces upgrade triggers at the moments the user is near the ceiling. Build the nurture against the same activation events the model learned on, so a user who has not reached activation at day three gets a message that drives at that specific event, and a user who has activated but not expanded gets a message that drives at the next workflow. Keep the content short, action-oriented, and tied to in-product state rather than to calendar days. ProductLed and Appcues both show the same pattern: nurture that is sequenced against user state converts materially better than nurture sequenced against the signup date, because state-based sequencing meets the user where they actually are rather than where the lifecycle tool thinks they should be.
Once the model has thirty days of production data, run a formal review every month for the first two quarters and quarterly thereafter. Lead with four numbers: trial-to-paid conversion on the hot cohort versus the base rate, accepted rate on the hot cohort inside the sales team, activation lift on the nurture program, and model calibration on the last thirty days of trials. The calibration number is the one most teams miss and the one that most tells you when to retrain: if trials scored at a seventy percent probability are converting at fifty, the model is drifting and the features are stale. Retrain on a rolling ninety-day window every month, keep the feature set stable unless a review decision changes it, and version the deployed model with a dated name so you can roll back cleanly. Reforge research is consistent that durable PQL and trial-score programs are retrained on a cadence and tuned one lever at a time, and that teams that leave the model static for a quarter watch its lift decay without seeing it until the sales team stops acting on the score.
Plan for two to three weeks of setup if the activation events, billing join, and ninety-day cohort history are already in place, then an ongoing monthly cadence to retrain and tune. Most of the setup is data plumbing rather than modeling, because the first version of the model is a logistic regression that fits on an index card.
Combine three families of inputs: fit features from your enrichment provider, activation features from the in-product events you defined, and engagement features from product telemetry. Keep the first version small enough that every feature is explainable in one sentence, because the sales team has to trust the score to act on it.
Score every active trial daily. Trials are a time-boxed asset, and a weekly batch loses half the window to lag on a fourteen-day trial. The lift from a daily cadence over a weekly one is larger than the lift from most model-quality improvements, because the sales touch has to arrive while the signal is still fresh.
Set the hot threshold against the validation holdout and against the number of trials the sales team can realistically touch at the agreed SLA, usually the top ten to twenty percent of active trials by score. Tune the threshold on accepted rate rather than on volume, and tighten it before you widen it.
Run a product-led nurture program that sequences against in-product state rather than calendar days. Pair each activation event with the specific email and in-app message that drives at it, suppress messages for users who have already completed the event, and add upgrade triggers at the free-tier ceiling or the trial expiration.
Retrain monthly on a rolling ninety-day window, hold out the most recent two weeks for validation, and compare calibration against the previous deployed version. Document the training window, the feature list, and the holdout calibration every time, so the next person to touch the model has a clean trail.
Strkr gives product, marketing, and sales a shared view of signups, activation events, PQL triggers, and daily trial-to-paid scores, so the model lives on the record the whole team already works from and the hot trials route themselves to the right rep.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
