Feature adoption starts with the work people already do

The old routine has a reason to survive

In an illustrative CRM, a sales manager opens a report every Friday, checks the figures, and emails it to the team. The job takes time, but the manual review gives them control over what colleagues will see. The product team adds scheduled delivery. On a design mockup, the path looks simple: choose a day, turn it on, save. The manager's real question is what happens when an email goes out without that final check.

This is why feature onboarding should begin with the existing job. A person who never sends reports has little reason to configure a schedule today. The manager who repeats the same send each week does. Introduce the option in reporting or just after a manual send, while the task is familiar. A prompt in the middle of editing a deal has no such context.

Check readiness before inviting the person in. The report needs data, the manager needs permission to send, and the recipients must be known. If any of these are missing, the announcement opens a setup path they cannot finish. More insistent copy will not solve that.

Show what will happen next Friday

The announcement does not need to recount the release. It can connect the familiar action to the new one and give the manager a safe way into setup. Beside the manual send, the sample copy might read:

• Heading: “Send this report on a schedule.”
• Text: “Choose a day and recipients. Check a test email before the first scheduled send.”
• Button: “Set up delivery.”

Let the manager check before committing

Open setup with the current report selected rather than an empty form full of every available option. The manager checks the data range and recipients, then previews an email using current figures. If Monday's message will contain last week's deals, show the exact dates. A field labelled Date range alone leaves the important question unanswered.

A test send can catch a wrong address or surprising figure before automatic delivery begins. Let the manager edit the settings after the test and then enable the schedule. Opening the form or clicking a toggle is not enough to mark setup complete: saving may fail, or the test may expose a problem. Show the saved state and the next send time.

People also get interrupted. A call may pull the manager away after they enter recipients. When they return, keep the saved choices and show what remains. Replaying the whole feature introduction would only slow them down.

The confirmation should explain what happens next

Once the manager saves, show who will receive the email, what dates it will cover, when it will go out, and where to stop the schedule. That is more useful than congratulating them for discovering a feature. They may not open the CRM again until next week; the confirmation needs to stand on its own.

The first scheduled email shows that delivery worked. It cannot tell you whether colleagues used the figures in their meeting. A test email, an enabled schedule, and confirmed delivery are different states. Keep them distinct in the interface and in any claim about adoption.

What the next send can reveal

After the first send, the manager may learn that the email went out before the data refresh or that one recipient needs another view. Let them open the rule from the report, change its timing or recipients, and send another test. Help should answer that new question instead of announcing the feature again.

A successful second send shows that the automation continues to run. Whether the team finds it useful needs another check: which figures came up in the meeting, what was missing, and did the manager return to manual email? Sometimes the report itself needs work. Find that out before adding another prompt.