Free trial lead routing for a sales-led team should combine company fit with product activity and the remaining trial window. Give the trial workflow explicit states, ownership, and response rules. Enrich supported identifiers in the background, keep unknown company fit separate from low fit, and let the product remain usable while context is pending.
Why do trials need a distinct review policy?
A trial creates a product context and a decision window that a generic lead queue may not capture.
Your existing sales rules may rely on information a minimal trial form never requested. Missing inputs can then produce a low score even when the account fits. A trial can also show meaningful first-party activity after signup, changing what help would be useful.
Keep the account in your CRM, but define how trial events change its next action. You do not need a separate product or duplicate lead record to create a clear trial workflow.
Which facts should you keep separate?
Store fit, product activity, and ownership as separate states.
| State | Example values | Evidence |
|---|---|---|
| Company fit | Target, outside target, unknown | Verified company fields and your versioned ICP rule |
| Product activity | Pending, activation milestone reached, request for help | Events and direct requests in your product |
| Enrichment status | Pending, complete, incomplete, unmatched | Completed task and required-field checks |
| Trial owner | Existing account owner, named review queue, self-serve path | Your account association and team policy |
| Trial clock | Start, scheduled review, end | Your product's actual trial terms |
A missing headcount is unknown fit. A successful person lookup does not automatically identify a full company record. A title does not establish purchasing authority.
What company and person information can you add?
Use the identifiers you hold and enrich only what the review needs.
A company domain or LinkedIn company URL supports company enrichment. A work email or LinkedIn profile URL supports known-person enrichment. Full company and person records use separate requests.
At documented rates, company enrichment uses one credit on success, a work-email person lookup uses three, and a profile-URL person lookup uses one. A person result's company object or employer domain can be missing. See the people scope and task/credit rules.
If your routing decision needs only company context, start there. Add a person operation when it answers a specific review question. Keep personal-email trials eligible for first-party qualification instead of defining them as poor leads.
Which trial accounts should reach a person?
Use a small decision table and explain each handoff.
This is a proposed starting policy. Adapt the milestones and timing to your product and team.
| Fit | Activity | Next action |
|---|---|---|
| Verified target | Reached the relevant activation milestone or asked for help | Existing owner reviews the account, or the named trial queue assigns one. |
| Verified target | No relevant activity yet | Continue activation support and reevaluate on the meaningful event. |
| Unknown | Meaningful activity or direct request | Review available first-party context; do not suppress solely because enrichment is missing. |
| Verified outside target | Any activity | Follow your standard product track, unless a request merits review. |
| Any fit state | Existing customer or open opportunity | Apply the established account-owner rule first. |
Product use can explain a helpful conversation. It does not automatically replace your qualification process. Decide which person owns the next action rather than universally routing every active trial to an account executive.
What should the trial queue show?
Make the next action readable without reconstructing a score.
Include account ID and link, trial dates, fit state, product milestone, qualifying reason, owner, missing context, and next review time. Record when enrichment is still pending.
In a fictional example, Northwind Logistics begins a trial and completes shared setup with two accepted members. The company result passes the team's logistics/size rule. The existing account owner receives a review with the setup evidence and a suggested offer of implementation help.
A similar account with no completed milestone stays on activation support under this example policy. An unknown company that directly asks for help still reaches the designated reviewer.
How should you budget the trial workflow?
Count successful operations and deliberately reused company results.
The following is illustrative, not a forecast of match rate. It starts with 400 trial signups and a selected work-email person lookup path.
| Work | Submitted inputs | Successful operations | Net credits |
|---|---|---|---|
| Person by work email | 270 supported work-email inputs | 180 | 180 × 3 = 540 |
| Company lookup | 200 distinct confirmed company identifiers | 190 | 190 × 1 = 190 |
| Other trial accounts | No supported identifier selected for this example | No request | 0 |
| Total | 730 |
The selected successful counts are assumptions. Failed tasks are refunded. Some completed person results may still lack required context. Other trial accounts keep a product path; the example does not classify them as unqualified.
Reusing saved company results can reduce requests. Submitting new successful repeats costs credits, so budget them explicitly instead of treating a second signup from one domain as free.
What should you test before rollout?
Replay trial states and confirm ownership, timing, and fallback behavior.
Test a target active account, a target inactive account, an unknown active account, a current customer, and a repeated activity event. Add a company result that arrives after a human has changed ownership.
Confirm the account stays usable, each review has a named owner, and delayed or missing enrichment never silently removes it from the workflow. Set a measurable business-hours review policy that fits your trial terms, then inspect actual queue outcomes.
Evaluate a small trial-account sample, then replay the decision table before connecting it to the live queue.