Email and Push Fallbacks: Design One Clear Next Step

An email fallback should help the customer finish a task they still need to complete. Prepare that email in Migma with the same approved facts and destination as the original notification, then let the journey owner decide when it is eligible to send.

The difficult question is not how to repeat a push notification in a longer format. It is whether the reader still needs the information and whether email is an appropriate next channel. A fallback that ignores completed actions can become a reminder to do something the customer has already done.

This guide is published by Migma. It defines a content and acceptance workflow for teams using a multichannel platform such as Customer.io. It does not claim that Migma automatically detects failed push delivery or controls another platform's fallback logic.

Define what fallback means in this journey

“Fallback” can describe several different situations. A push notification might be unavailable because the user has not enabled it. A sending service might report a failure. A notification might be delivered while the underlying task remains incomplete. Those states are not interchangeable.

Write the exact condition your workflow uses. If the condition is “task incomplete after the chosen interval,” say that. Do not label it “push failed” without delivery evidence. The difference affects both the routing and the wording of the email.

Customer.io's channel strategy guide discusses matching channels to the customer's context and coordinating them. It is a useful starting point for the content decision, while your implementation owner must confirm which signals and controls are available in the actual journey.

Follow the task through three decisions

First, determine whether the task is still relevant. If the customer completed setup, a setup reminder should stop. If an appointment was cancelled, its reminder needs a different purpose. A previous notification is not sufficient reason to send another message.

Second, determine whether email is an appropriate route for this person and purpose. Review channel eligibility and the message's role using your team's normal policies. Permission for one channel should not be treated as automatic eligibility for every other channel.

Third, decide what extra value the email provides. It can offer context, instructions, or a durable record that a short push message could not carry. If it contributes nothing beyond another interruption, reconsider the fallback.

Record the answers next to the journey. That gives the reviewer a reason for the email rather than a generic rule to use every available channel.

Build an email that expands the useful information

Start the creative in Migma with the approved task, current state, destination, and support route. Review the brand context so the email feels like the same product as the notification.

For a hypothetical incomplete setup task, the push could invite the user back to the product. The email can explain what remains, why it matters, and where to resume. It should not claim the notification was ignored or blame the recipient for missing it.

A concise email brief might say:

Help someone complete the remaining setup step. Explain the approved next action, link to the correct destination, and offer support. Do not claim a delivery failure or add a deadline unless those facts were supplied.

Keep the main action consistent across channels. If the push opens a setup screen while the email promotes an unrelated upgrade, the journey has changed goals without telling the reader.

Keep the claim consistent as state changes

The draft should describe a state the final workflow can still verify. “Finish adding your first item” requires confidence that the first item is not already present when the message sends.

Identify which facts are stable and which need a fresh check. The product name may be stable; task completion, availability, and expiry can change. Have the data owner decide how the destination version receives those values.

Prepare copy for supported branches rather than assuming one sentence covers every state. If a task is complete, the accepted behavior may be no message. If a destination becomes unavailable, the workflow may need an operational exception instead of a fallback email with a dead button.

This is a design decision to document, not a claim that an email can update itself after reaching the inbox.

Test the email and the routing separately

Run Migma Email Preflight for writing, links, inbox layout, and common sending risks. Review the email's action on desktop and phone inboxes through your normal process.

Use HTML export for the destination when appropriate. A developer or lifecycle owner must adapt the message to that platform's personalization and routing. A PNG review image is not a sendable template.

Then test the journey's key states with controlled accounts: push unavailable, the relevant failure signal, task completed before the fallback, task still incomplete, and missing optional data. Only include states that your actual implementation supports.

Check the resulting sequence, not only the email preview. Record why the fallback sent or stopped, the final message version, and the destination it used. A provider accepting a push or email does not establish that the person completed the task.

Give the fallback one owner

Name the person responsible for the eligibility rule and the person responsible for the creative. They should approve the same message version and task definition. A new product state can require a routing update even when the email design stays unchanged.

Keep the chosen interval documented as a team decision rather than presenting it as an optimal industry standard. Revisit it using appropriate task outcomes and customer feedback, while acknowledging other changes that affect interpretation.

Migma helps make the email clear and reviewable. The multichannel platform and its owner determine whether the message should exist at that moment. A successful fallback is a coherent next step, supported by current state and useful information, rather than a second copy of an earlier interruption.

Frequently Asked Questions