Day-0 welcome
Welcome to {{product_name}}, {{first_name}}
Your workspace is ready. Three things to try first — takes about 4 minutes.
Use case
ReachBell for SaaS teams.
Onboarding sequences, feature announcements, re-engagement loops, and transactional sends — built on the same platform your product team already understands.
The problem
Three vendors, a sales engineer, and a Notion page.
The standard SaaS engagement stack is held together by integrations nobody owns.
The classic SaaS engagement stack is Customer.io for product events, Mailchimp or Resend for marketing email, Postmark or SES for transactional sends, OneSignal for push, and a Segment instance bolted on so each tool sees the same user. Each pairing is fine. The composite is fragile: a sign-up event fans out to five destinations, each with its own schema, its own retry semantics, and its own definition of an identifier. Debug a missing welcome email and you’ll spend the afternoon in webhook logs.
Pricing makes it worse. Once a SaaS crosses 10,000 active users, the per-tool MRR starts to look like a finance line item. The team often ends up disabling a flow because it’s too expensive to keep running, rather than because it stopped working. ReachBell’s bundled plans take that conversation off the table — push, email, and automations on every paid tier.
The third tax is the activation gap. Most SaaS products lose more revenue to users who never reached their aha moment than to active users churning. A real onboarding flow needs product events, branching, channel preferences, and a way to exit when the user actually activates — all in the same tool the marketing team uses for the monthly newsletter. Splitting that across systems is how the onboarding sequence ends up not being run.
Templates
Templates the product team will recognise.
Drop these into a flow, wire up the events, and your onboarding sequence is live before lunch.
Feature announcement
New: {{feature_name}} is live
You asked, we shipped. Tap to see what changed — no migration needed.
Re-engagement, 14 days inactive
Your workspace is waiting
Picked up a {{milestone}} since you last logged in. A quick 2-minute catch-up?
Trial ending in 3 days
3 days left on your trial
You've used {{usage_metric}}. Pick a plan to keep your data — no card needed until you do.
Teammate invitation
{{inviter_name}} added you to {{workspace}}
Tap to accept and join your team's workspace. Takes 30 seconds.
Weekly product digest
What shipped this week in {{product_name}}
Three improvements and one new beta — open to read the changelog.
Automation flows
Flows that move the activation needle.
Three flows that pay for the platform. Build them once, leave them running.
New customer onboarding (first 14 days)
Walk a brand-new account through their first key actions without nagging the ones who already finished.
- 01Trigger: `user.created` event fires immediately after signup.
- 02Send welcome email with one CTA — start the first project — and a Loom link.
- 03Wait 24 hours. If the user has not created a project, push: "Need help getting started?"
- 04Day 3: send the "5 things power users do in week one" email, branching on plan tier.
- 05Day 7: trigger the in-product checklist webhook so the dashboard surfaces progress.
- 06Exit early on `activation_event` (your definition — e.g. invited a teammate AND saved a dashboard).
Feature announcement (segmented)
Tell the right plan tier about a new feature without spamming the rest.
- 01Segment: plan in [growth, business] AND has used the legacy version of the feature in the last 30 days.
- 02Send launch email with a deep link to the new screen and a one-paragraph why-it-matters.
- 03Wait 2 days. For unopened recipients, send a push with the same CTA.
- 04Wait 5 days. Send a "tips from the team" follow-up only to recipients who clicked through.
- 05Track `feature_used` for 14 days after the launch and pin the conversion rate to the campaign report.
Trial-to-paid conversion
Nudge trialists toward an upgrade decision before the trial ends — without burning the ones who already decided.
- 01Trigger: `trial.started` event with a 14-day window.
- 02Day 3 push: "How is the trial going?" with a deep link to the help docs and a Calendly slot.
- 03Day 7 email: usage summary so the user sees the value they've already extracted.
- 04Day 11 email: "3 days left" with a clear pricing CTA and "talk to a human" option.
- 05Day 14 push at trial end: "Pick a plan to keep your data" — quiet hours respected.
- 06If `subscription.created` fires at any point, exit and start the onboarding flow above.
In the wild
Who's using it.
We use ReachBell on our own SaaS products before recommending it to yours.
OmegleCo. is the closest dogfooding parallel to a SaaS app on our books: registration, activation, retention, and re-engagement all run through ReachBell. The onboarding flow above is essentially the same shape as the one that walks a new OmegleCo. user from sign-up to first conversation, with the steps and merge tags tuned for the product.
VedHoroscope uses the platform as a transactional sender for account-level emails and as a marketing channel for premium-tier upsells. StumpScoreuses the events API to fire match-state-changed events and run different flows for free and pro subscribers. None of these products have a separate Customer.io contract; that’s the point of the bundling.
FAQ
Questions, answered.
Everything teams usually ask before switching. Something missing? Email us — a human replies.
Can ReachBell handle both marketing and transactional sends?
Yes. The transactional API mirrors the patterns of Postmark and Resend, so receipts, password resets, and invites send within seconds and bypass marketing-frequency caps. Marketing campaigns use the same templates and the same audience, but obey caps, quiet hours, and per-user opt-out preferences.
Do you support product-event-driven automations like Customer.io?
Yes. Pipe events from your backend or Segment to the events API and they become triggers in the visual flow builder. Conditions branch on event properties, user traits, or computed segments — and merge tags resolve from the event payload at send time.
How do you avoid pushing to a user across channels for the same event?
Each campaign can specify a channel waterfall — try push first, fall back to email if no click after N minutes — and per-user channel preferences override the default. Frequency caps apply across all channels of the same category (marketing vs. transactional).
Will the SDK fit into our React Native or Flutter app?
Mobile push works through FCM for Android and APNs for iOS, so any framework that supports them — React Native, Flutter, native, or hybrid — works without a vendor SDK. The web push snippet is plain JavaScript and ships in around 6 KB.
Can we run separate workspaces for staging and production?
Yes. Projects on Growth and above are unlimited, and Business plans include sandbox projects so QA can fire events without touching live subscribers. API keys are scoped per project so a leaked staging key can't broadcast to production.