A journey triggered by a real business event
A subscription renewal, a support resolution, or an order from a system outside Mailchimp's native connectors enrolls a contact in the right journey automatically.
Mailchimp runs two layers of automation: classic single-trigger automations (welcome a new subscriber, follow up on an abandoned cart) and the newer Customer Journey Builder, a visual map of branching paths and conditions a contact moves through. Both are genuinely native and work well, right up until the trigger you actually need is something that happens outside Mailchimp.
A classic automation starts from a single trigger, someone joins a list, clicks a link, makes a purchase on a connected store, and runs a linear sequence from there: send this, wait that long, send the next one. It's straightforward to build and covers welcome series, re-engagement, and birthday or anniversary sends well.
Customer Journey Builder replaces the straight line with branches. A contact can take different paths based on whether they opened a previous email, what tag they carry, or data pulled from a connected e-commerce store, so the same journey can treat a first-time buyer differently from a repeat one without building two separate automations by hand.
Autoresponders, Mailchimp's older, simpler term for the same basic idea, still work the same way under the hood: a trigger inside Mailchimp, a sequence of sends, no custom logic required to set one up.
Every one of those triggers is something Mailchimp can see happening on its own: a form submit, an email click, a purchase on one of its connected storefronts. The moment the real-world event you want to react to happens in a different system, a support ticket closing, an invoice getting paid, a subscription renewing, a wholesale order landing in a system outside Mailchimp's supported list, there's no native path to fire a journey off it.
We build that trigger. We connect the system where the real event actually happens to Mailchimp's API, so the right automation enrolls a contact the moment something true happens in your business, not the moment someone remembers to tag them manually.
A subscription renewal, a support resolution, or an order from a system outside Mailchimp's native connectors enrolls a contact in the right journey automatically.
Account tier, usage data, or a loyalty status pulled from your actual systems feeds the journey's branch conditions, not just what Mailchimp already has on the contact record.
Tell us what event actually matters and where it happens.
Point us at the real event, a renewal, a resolved ticket, an order from outside your connected store, and we'll build the connection that gets it to Mailchimp. Automations are one example; n-frames automates whatever's manual, in Mailchimp or anywhere else in your business.
Let's talk →A classic automation runs a single linear sequence off one trigger. Customer Journey Builder lets that sequence branch into different paths based on behavior, tags, or purchase data, so one journey can handle several outcomes instead of needing several separate automations.
Yes, both are standard, well-supported automation triggers: a welcome series fires off a new signup, and a birthday or anniversary send uses a date field on the contact record. Neither needs any custom setup beyond picking the trigger and writing the email.
An older term for the same basic concept as a classic automation: a trigger, then a sequence of emails sent on a schedule. Mailchimp's current interface groups autoresponders and automations together under the same builder.
Not on its own. Native triggers are limited to events Mailchimp can see directly, a form fill, an email click, a purchase from a connected storefront. Reaching an event in your CRM, accounting system, or support desk takes an API connection that passes the event to Mailchimp, which is exactly what we build.
By default an automation or journey only applies going forward from the moment it's switched on. It won't retroactively enroll contacts who already matched the trigger condition earlier, you'd need to run it once against a static list of those existing contacts to catch them.