Most of a beta happens over email. You invite testers by email, announce new tasks by email, remind people by email, and route answers to the right colleague by email. So when someone goes quiet, the first question worth asking is not "are they disengaged?" but "are they even receiving this?"
This guide covers both sides of that: making sure your emails arrive, and making sure the ones you receive are the ones you actually want.
In this article
- Why emails stop arriving
- Spot a tester who has unsubscribed
- How delivery gets restored
- Choose what lands in your own inbox
- Send each email to exactly the right people
Why emails stop arriving
Anyone can unsubscribe from Stomio emails, and it is easier to do by accident than you might expect. Clicking unsubscribe in an email footer does it, and so does the built-in unsubscribe button that mail apps like Gmail and Outlook show next to the sender name. People often tap it to clear a busy inbox without registering which sender they just silenced.
There are two levels, and the only difference is how much stops:
- Unsubscribed from project and workspace notification emails. Announcements, reminders, and other notification emails stop arriving.
- Unsubscribed from all Stomio emails. Every optional email stops, across every workspace and beta the person belongs to.
In both cases, essential emails are still delivered. Invitations and password resets go out regardless, because they are the emails someone needs in order to use their account at all. That is also why an unsubscribe can stay invisible for a long time: the tester accepted your invitation just fine, and only the follow-up communication went missing.
Spot a tester who has unsubscribed
Open a tester's profile from your tester table. Their profile info now shows a warning banner when their email delivery is blocked, telling you which of the two levels applies.
A tester's Profile info panel showing a warning banner that the account is unsubscribed from project and workspace notification emails
The banner only appears when there is a problem. A tester who is receiving your emails normally shows nothing at all, so an empty space is good news, not missing information. If Stomio cannot check the status at that moment, you will see Email delivery status is currently unavailable instead, which means the check failed, not that the tester unsubscribed.
This is worth checking before you chase someone for being unresponsive. A tester who never saw your last three announcements is not disengaged, they are unreachable, and the fix is completely different.
How delivery gets restored
An unsubscribe belongs to the person who made it, so only they can undo it. You cannot resubscribe a tester on their behalf, and that is deliberate: consent to receive email has to come from the person receiving it.
The good news is that it takes them two clicks and no support ticket. When someone is unsubscribed, a Resubscribe button appears in their own Preferences page in Stomio, right at the top. They click it, and delivery is restored.
So the practical play, once you have spotted an unsubscribed tester, is to reach them another way (a ticket, your own email, a call) and point them at their Preferences page.
Choose what lands in your own inbox
The same Preferences page controls what Stomio sends you. It has grown to a fairly precise set of switches, so you can stay informed without drowning:
- Daily project messages digest: one daily summary instead of a message-by-message stream.
- New tickets: a ticket was opened.
- New messages in tickets: activity on ticket conversations.
- Mentions in tickets: someone mentioned you by name.
- Beta announcements: announcements sent in your betas.
- Project status updates: a project changed state, for example moving from published to running.
- Beta reminders: reminder emails going out in your betas.
- Survey responses digest: a digest of incoming survey responses.
The Email section of the Preferences page, with a switch for each type of email
Everything is on by default, so this is a page you visit to turn things down rather than to switch things on. Workspace owners get one more switch, Monthly workspace stats, under its own Workspace Emails heading further down the page.
If you are unsubscribed, these switches appear dimmed and cannot be changed. That is expected: an unsubscribe sits above the individual settings, so use Resubscribe first and then tune the switches.
One deliberate detail: Mentions in tickets is its own switch, separate from New messages in tickets. Being mentioned by name is someone deliberately asking for your attention, so you can silence the general firehose of ticket messages and still be pulled in when a colleague actually needs you. If you only change one setting on this page, make it that pair.
Send each email to exactly the right people
Inside a beta, a Triggered Email step lets you send an email automatically when a tester reaches that point in a task. It cannot be the first step of a task, since something has to happen before there is anything to trigger on.
The To field is where targeting happens, and you can combine:
- All managers or All testers in the beta.
- Tester tags, so only testers carrying a given tag get the email. Tags are defined once for your workspace and applied to individual testers, which makes them the usual way to segment by platform, region, or cohort. These are tester tags, not beta labels: labels are a separate, per-beta concept used to segment tasks.
- A person custom field, which routes the email to the person recorded in that field on each tester's record.
That last option is the newest and the most useful for account-based betas. If you track a person on your tester records, for example a sales contact, a customer success manager, or an engineering owner, you can send straight to them rather than to the whole manager list, and each tester's email goes to their own contact. You set these up like any other custom field (see Qualify Your Beta Testers Using Custom Fields).
One rule to keep in mind: a person field can record either a colleague from your workspace or an external contact's email address, and only the colleague can be a To recipient. External contacts are reached through the Cc field, which also takes person custom fields. So the natural pattern is to send the email to the internal owner and copy the external contact when they should see it too.
Two things worth knowing:
- The full set of audiences above is available in beta projects. In-app (widget/SDK) projects offer the Triggered Email step too, but its audience is managers only, since tags and person fields live on testers you have placed in a beta. Survey projects do not offer the step at all.
- Triggered emails fire on new answers only. Correcting or updating data that has already been answered will not set off another round of emails, so you can clean up your data without spamming anyone.
Put together, that is the whole loop: the right email, to the right person, actually landing in their inbox, with your own notifications tuned to the level you want.