Onboarding emails for a software free trial

Short answer: Plan trial emails around one behaviour that shows a user has reached value, and let what people do decide which message they get. This article is a proposed workflow. It does not claim measured results, and the example triggers are editorial suggestions you should adapt to your own product.

Step 1: Name the key action

Customer.io's onboarding recipe begins by asking you to choose one specific behavioural goal that matters to your onboarding, and to focus each automation on nudging people towards it. Examples of what that might be, purely as illustrations: a first booking received in scheduling software, a first invoice sent in an invoicing tool, a second teammate invited in a team tool, or data arriving in an analytics product. If you cannot name the action yet, do that before writing any email.

Step 2: Decide who enters and what counts as success

The same recipe describes a segment-triggered automation: the trigger defines who enters, such as people who signed up but have not yet done the key action. It also describes setting a conversion goal, defined as the behaviour you chose at the start, and notes that conversions can be a more reliable way to judge success than opens and clicks. In the recipe, the goal is a way to understand whether messages have their desired effect. It is a measurement step, and the recipe does not describe it as stopping the automation or removing people who convert. By default, automations look forward, so people who match later receive them. You can choose to include existing matches, so decide that deliberately. If you use another tool, look for equivalent building blocks and check its documentation, because this article does not describe other products.

Step 3: Sketch the messages

The following is a conditional outline. Adjust the timing to how quickly your product delivers value. Branches such as "started but not finished" or "completed" need to be configured in your own tool, using whatever branching or exit options it offers.

Welcome, sent at sign-up. One sentence on what the trial lets them do, one clear step towards the key action, how to reach a real person, and the trial end date stated plainly.
Reminder to those who have not logged in. Short, specific, with a direct link to the first step.
Guided nudge to those who started but have not finished the key action. Address the blocker you most often see in support conversations, with a short guide or recording.
Next step for those who completed it. Confirm what they achieved in their own words and suggest one sensible follow-up.
Plain-text personal note for accounts you consider promising. Decide the criteria in advance, and make sure it is truly written and monitored by a person.
Trial ending reminder. Say the end date, what happens to the account and data, and how to choose a plan. Only state what your product actually does.
After the trial. Explain what happens to their data, how to restart, and optionally ask one question about what stopped them.

The recipe's own example uses a delay between emails and a final email with a different angle, so allow time between messages rather than sending a burst.

Step 4: Handle language and timing

If your users work in more than one language, choose the email language from the preference the user gave you, not from a guess about their location. Have a human who reads each language review the copy. For timing, the Customer.io recipe describes adding a time window so messages go out at a chosen time. If you use that feature, pick windows that suit your users' working week and time zone, and test them. Do not message people by WhatsApp or any other channel unless they agreed to that.

Step 5: Be honest about limits and cost

Do not promote features that are not in the user's plan without saying so.
Do not let a trial end silently before a charge. If a card is on file, say clearly when it will be used.
Stop nudging people who have completed the action. Detecting the conversion and stopping messages are separate things: the recipe's conversion goal measures success, and it does not say it removes anyone from the automation. To stop messages, set up an exit or branch yourself in your tool, and check its documentation for how that works.
Keep to a volume of messages you would be comfortable receiving yourself.

Step 6: Review what happens

Track how many trial users complete the key action, how long they take, and how many choose a plan. Compare groups over a period you set in advance, and change one email at a time. Do not borrow benchmark figures from articles. Your product, audience and pricing differ, and this article provides none.

Questions

How many emails should a trial have?

Plan the branches first and count afterwards. The right number depends on your product and the paths people take.

Should emails come from a person or the company?

Try a named sender with a monitored reply address, and compare it with a company sender if you want evidence. It is an option to test, not a rule.

Do I need a developer?

To trigger messages from product behaviour, your email tool has to receive that behaviour somehow. Whether that takes developer work depends on how your tool collects events and what your product already sends, so check your tool's documentation before assuming either way.

Is in-app messaging a replacement for email?

They reach people in different situations. Decide which fits each message, and avoid duplicating the same text everywhere.

Sources

Customer.io, Onboarding automation recipe: https://docs.customer.io/messaging/send/recipes/onboarding-automation/