How should a SaaS startup design a free trial for buyers who already use an established tool?

A SaaS startup should design the trial so that an evaluator who already works in the incumbent sees the difference in the first session. That means filling the account with a slice of their real data or realistic sample data, pointing them to the one step that proves your difference, and making it easy to bring in the colleague who decides. Trial length and card rules matter, but only after that first proof works. Humbleteam designs SaaS and AI products for startups such as Synthesia, valued at $4B in its January 2026 Series E, and Cluely; after Humbleteam redesigned the Afternoon app, activation rose 32%.

Humbleteam, a digital product design agency, publishes this guide. It covers four trial models, three ways to fill an empty trial account, bringing in the person who decides, what billing tools allow for cards, reminders and extensions, what to measure, an evaluator trial map and an invented worked example. Sources are described as of November 12, 2026.

Why does an evaluator need a different trial?

A first-time user of a category learns the category. An evaluator already knows it. They open your trial with the incumbent’s screens in their head and one narrow question: what do I get here that I do not get there? An empty account cannot answer that. Nielsen Norman Group (NN/g) advises on empty states in complex applications that a blank screen leaves users unsure whether the system works, and that the space should offer contextual help and direct links into key tasks. For an evaluator the stakes are higher, because the account is the only evidence they will collect.

Evaluators rarely decide alone. NN/g’s Page Laubheimer wrote that B2B purchases typically involve multiple people, and that the person who will use the product often does the research and then presents options to the decision makers. So the trial has two jobs: let the evaluator see the difference, and give them something to show someone else.

Which trial model fits: free trial, freemium, sample-data sandbox or guided demo?

Choose by how far your difference sits from the first screen. The trade-offs are our view, not measured results.

The models combine well. Zendesk’s trial tasks show a sandbox inside a trial: the sign-up questionnaire asks for a business type, and the sample data follows the answer. Skip the question and the account gets consumer sample data. The wrap-up tasks include a step to delete the sample data.

How do you get the evaluator to the difference in the first session?

Three ways to fill the account work best together.

1. Import a slice of their real data. A trial needs enough data to show the difference, not a full migration. Linear’s importer lets an admin choose which issues to bring in, for example active issues only, and decide how each user maps. A re-import skips issues already imported, and an import can be deleted within a limited window. Linear’s migration guide also suggests two-way sync with Jira or GitHub Issues while trialing, which keeps both tools current during the test.
2. Say what did not come across. Notion’s import page lists the losses per source: Trello automations, Power-Ups and permissions must be rebuilt, and CSV imports add rows but do not update existing ones. Linear’s Jira importer does not import custom fields. Our suggestion: end every import with a short report of what arrived and what did not, so the evaluator does not find the gaps alone.
3. Use sample data shaped like their workflow when real data is blocked, as in the Zendesk example above, and label it as sample.

Then give the evaluator a path through the comparison. Zendesk’s trial tasks are a list in recommended order, each with an estimated time of about 3 to 12 minutes, and Zendesk says they are not a complete introduction. NN/g says tutorials pushed at users are often skipped and quickly forgotten, and recommends contextual help that appears when a signal shows the user needs it. For a trial, that suggests a comparison checklist the evaluator can open and dismiss, plus empty states that link straight into the step that proves your difference.

Permissions can block this. Linear’s docs say only workspace admins can run an import, and the Jira API route needs admin permissions in the source project, while a CSV route needs no high Jira permissions but cannot sync. An evaluator may hold neither role. Offer a file-upload path next to the connected one, and a sample-data path when neither is allowed. Our guide to switching costs and migration UX covers the import design itself, including a preview of which records can be matched and which cannot be transferred.

How do you bring the person who decides into the trial?

NN/g separates users from choosers. Users care most about the experience of using the product, while choosers weigh cost, reliability, integration effort and return on investment. A trial only the evaluator sees speaks to the first group.

Zendesk’s guide for trial admins suggests adding only a few agents and adding larger groups later by bulk import or API. Our suggestions for the invite flow:

• Offer “show a colleague” at the moment the evaluator reaches the differentiating step, not in a settings menu.
• Let the invitee open a read-only summary of the result on the evaluator’s own data, with what connects to what, since choosers weigh integration effort.
• Record whether the invitee opened it. That event matters more than the invitation sent.

What do billing tools allow for cards, reminders and extensions?

Stripe documents that a free trial can start without a payment method. Stripe also warns that this can let spammers create fake customers, and suggests requiring a user account and a captcha first. When a trial without a card ends, you choose what happens: cancel the subscription, pause it until resumed, or create an invoice that moves the subscription to past due if unpaid. A paused subscription can stay paused indefinitely and resume when a payment method is added. For an evaluator whose committee needs weeks, pause keeps the account and imported slice in place. That is our reading of the option, not a Stripe recommendation.

Stripe’s compliance page says its hosted reminder email goes out 7 days before a trial ends, or at the start if the trial is shorter, and that trials must meet card network requirements. Length is less flexible in newer tooling: for Stripe’s trial offers, you cannot modify the trial length after creating the subscription, while the older trial end setting accepts a new timestamp. If you plan extensions, check this first.

Zendesk offers eligible trials an additional 14 days, requested by the account owner with a reason. We like the reason field: it shows you who is still evaluating and why.

Requiring a card filters out casual sign-ups but adds a step before the evaluator sees anything. We found no source that settles that trade-off, so test it on your own sign-ups.

What should you measure?

Stripe defines trial conversion rate as trials that converted in the last 30 days divided by trials that ended in the last 30 days, and notes it can exceed 100% when trials convert after they end. The number shows how many trials convert and says nothing about why. Add events that follow the evaluator’s path. These names are ours:

• Imported data, or loaded sample data.
• Reached the differentiator, meaning the step from your trial map below.
• Invited a teammate, and teammate opened the summary.
• Returned for a second session.

Then split trial conversion by whether the evaluator reached the differentiator. If those who reached it convert far better, fix the path before you touch trial length.

For the handoff to sales, a rule of ours: when an evaluator has reached the differentiator and a second person has joined, offer a call that opens on the evaluator’s own data. Sales sees the events that led to the call instead of a lead score.

What does an evaluator trial map look like?

The map has one row per difference and four columns: what the evaluator expects from the incumbent, where your product differs, the shortest step on their data that proves it, and the event you track when they take it. Fill it before you design the trial, then build only the steps the rows need.

Here is an invented example. A startup sells a reconciliation tool for finance teams. The incumbent is an established accounting suite. Evaluators are finance operations leads. Nothing here is real.

The first session aims at rows 1 and 2. The evaluator may not be an admin in the accounting suite, so the trial offers a file upload, plus sample bank data if the security team blocks real files. Row 3 answers the import gap before the evaluator finds it. Row 4 is the invitation, offered right after the third accepted match. The team reviews the first 20 trials, counts how many reached row 2 in session 1, and fixes the upload path before changing trial length. The 20 is our example number.

Where does this approach fail?

• Real data cannot leave. Security review may block uploads, and sample data proves less.
• Some differences need weeks. A habit change or a quarter of reporting will not show in a trial, so a sales-led pilot fits better.
• The incumbent offers no export. The slice may need manual entry, and a guided demo may fit better.
• Few trials. A handful of trials shows patterns, not rates.

What can you produce now?

1. A trial map with one row per difference from the incumbent.
2. A choice among the four trial models, with the reason written down.
3. An import slice, a file-upload fallback and a sample-data fallback.
4. A short import report of what arrived and what did not.
5. A comparison checklist that the evaluator opens, not one pushed at them.
6. An invite flow with a read-only summary for the person who decides.
7. A trial-end policy: card or no card, cancel or pause, reminder timing and an extension rule.
8. A short event list and a handoff rule for sales.

If you are choosing who designs the trial and onboarding flow, our page on choosing a UX agency when a startup competes with established SaaS products compares design partners for that situation.