Start in Migma with the email the customer should receive. Write its purpose, the facts it may mention, and the action it asks the reader to take. Then work backward with your Customer.io owner: which event proves that this message is appropriate, and which fields supply its words and links?
An event tracking plan becomes useful when it answers those questions. A spreadsheet full of event names can still leave a designer guessing whether “completed” means payment accepted, setup finished, or shipment delivered. Those are different moments and need different emails.
Customer.io’s tracking-plan guide identifies event naming, data types, timestamps, segments, and triggers as planning concerns. The template below turns those concerns into a practical creative brief. It is an original working example, not a description of a preconfigured integration.
Write one message promise before naming the event
Suppose an opted-in customer finishes setting up a workspace. Your email should help them invite a teammate. It should not congratulate them on a purchase or imply that someone has already joined.
Give Migma approved brand context and this narrow job: explain that setup is complete, show the workspace name when it is available, and offer one invitation action. Keep the audience rule separate from the writing prompt. A draft that sounds appropriate does not establish who may receive it.
Save the business definition beside the brief: setup is complete only after the required configuration steps pass. If the product team instead emits an event when someone opens the setup page, change the data contract or change the message. Do not ask better copy to hide an unreliable trigger.
Use a compact event-to-email contract
Start with these columns. Add another only when someone can explain which decision it supports.
| Contract item | Example for a setup email | Who confirms it |
|---|---|---|
| Business moment | Required workspace setup finished | Product owner |
| Event name | workspace_setup_completed | Engineering owner |
| Identity | The intended account and recipient | Data owner |
| Event time | When setup actually finished | Engineering owner |
| Copy field | workspace_name, a display string | Content and data owners |
| Action field | Approved invitation destination | Product owner |
| Missing-data rule | Omit the name; hold if action is unavailable | Email owner |
| Outcome | A teammate invitation was completed | Analytics owner |
These names are illustrative. Use the actual contract your team supports. The important distinction is between evidence for sending, values used inside the email, and evidence of the later outcome. One field should not silently stand in for all three.
Define what each field means
For every value that affects copy, record its type, source, allowed empty state, and example. A workspace name may be a string, but a string containing only spaces is still unusable. A link may be present yet point to a preview environment.
Time fields need a declared meaning. “Observed at” and “received by Customer.io at” can differ. If an event arrives late, reviewers need to know whether the message still makes sense. Store the original occurrence time and let the responsible platform owner decide how delays affect eligibility.
Avoid adding personal information just because it is available. If the email needs a workspace label and one action, the creative brief usually does not need a full account record. Share approved examples with Migma and keep production secrets out of screenshots and review notes.
Review three examples before building the design
Use a small fictional case set. The ordinary case has a short name and working action. The sparse case has no name but still has a valid action. The exception case has an ambiguous completion state or missing destination.
For the ordinary case, check that the draft says exactly what happened. For the sparse case, approve natural fallback wording such as “Your workspace is ready.” For the exception case, document a hold or another owner-approved response. An empty button is not a fallback.
Include a long workspace name as an additional layout check. It should wrap without hiding the action or changing the meaning of the heading. These are acceptance examples for your own implementation, not evidence that a live trigger has been tested.
Make the Migma handoff explicit
Use Migma brand settings for durable voice and visual guidance. Put event-specific facts in the current brief. This keeps a temporary state from becoming a standing brand instruction for later drafts.
Ask Migma to prepare the normal and sparse examples for review. Approve the copy, button label, image treatment, and fallback behavior together. If an image is decorative, make sure the essential setup information remains readable as text.
When you export the reviewed email, the destination owner must map its actual fields and test the populated result. This workflow does not assume a native Customer.io export connection. Use the supported handoff your team has verified, and keep sending setup with its responsible owner.
Keep the plan useful after launch
Record the approved creative version beside the contract version. If engineering renames a field or changes what completion means, the email owner can identify which message needs another review.
For outcome reporting, choose the business action before interpreting engagement. An invitation click and a completed teammate invitation answer different questions. Ask the analytics owner how identity, timing, and attribution are handled rather than treating a link click as proof of completion.
Begin with one event and one message. Complete the definitions, examples, creative review, and destination check before copying the template across a lifecycle program. A short contract that people actually use is a better starting point than a large inventory whose fields nobody can explain.
Frequently asked questions
Does a tracking plan activate a Customer.io automation?
No. It documents the intended events, fields, and acceptance rules. The platform owner still has to implement, configure, and verify the actual automation.
Should the creative brief contain a full customer payload?
Usually it only needs the approved fields used by the message, with fictional or suitably minimized examples. Keep unrelated personal information and secrets out of the brief.
What happens when an action URL is missing?
Define the behavior before launch. A required action may call for holding the message or using an owner-approved alternative; do not render an empty button.
Can Migma replace the field-mapping review?
Migma can prepare the email from approved context, but the destination owner must verify actual field names, populated values, and sending eligibility.