Build email flows by describing them in chat

What this page covers

Part of the Mailprompt features set, this page explains what the chat actually produces when you ask for a flow. The short version: a reviewable draft with a named trigger, ordered steps, waits, conditions and copy, not a black box that starts sending.

Start with the outcome, not the builder

Most flow tools begin with a canvas. You pick a trigger from a menu, drag a delay onto the canvas, connect a send node, then open a separate editor to write the email. That works when you already know the shape of the flow. It is slow when you know the outcome you want but not the sequence that gets there.

Mailprompt starts from the outcome. A request such as “recover checkouts that stall before payment, without discounting on the first message” gives the system enough to draft a trigger, a wait, a first email and an exit condition. You can then read the draft and correct it. The point is not to remove your judgement; it is to remove the setup work that stands between your judgement and a testable flow.

The chat is also a useful place to ask questions. You can ask why a wait was chosen, what event starts the flow, which audience it uses or what happens when a customer orders before the second message. The answer should point at the draft, not at a generic help article.

What the draft contains

A flow draft has to be concrete enough to review. Mailprompt writes down the trigger, the audience, the ordered steps, the waits, the conditions and the exit rules. Each send step points at a block document with a subject line and a rendered email, so you can see the message rather than a placeholder.

The draft also records the assumptions it made. If you asked for a win-back flow without saying how long a customer should be inactive, the draft should say which inactivity window it used and why. If you asked for a discount, the draft should show where the coupon comes from rather than inventing a code in the copy.

That record matters at review time. A flow that looks reasonable but silently assumes the wrong audience is worse than a flow that states its assumption and asks you to confirm it.

Triggers, waits and conditions

Mailprompt's flow model is built from a small set of parts: a trigger, waits, sends and conditional branches. A trigger can be a store event, a date, a profile property or entry into a segment. A wait is a duration such as hours, days or weeks. A condition can check whether an event happened, whether a profile is in a segment or whether a property matches a value.

That vocabulary is deliberately narrower than a general-purpose automation builder. Narrow parts are easier to review, easier to test and easier to explain back to you in chat. If a request needs a part the model does not have, the right response is to say so, not to fake it with a send that looks like a condition.

The same model covers the core ecommerce flows: a welcome sequence, an abandoned checkout sequence, a post-purchase sequence and a win-back sequence. Each one is a different arrangement of the same parts, which is why the chat can draft a new flow without a new integration for every use case.

Review is the product, not a checkbox

A flow can recover revenue or annoy a customer, and the difference is often a detail: the wait is too short, the audience includes people who already ordered, the discount is deeper than the margin allows. A human review is where those details get caught.

Mailprompt's approval view is therefore part of the flow feature, not a separate compliance screen. You see the trigger, the audience, the steps, the rendered email and the assumptions in one place. You can approve, reject with a note, or ask for a narrower draft. The flow does not become live until the approval is recorded.

This is also why the chat cannot “just fix it” after approval. A change creates a new draft, and the new draft needs a new approval. The rule is boring, which is the point: it holds even when the person asking is in a hurry.

What happens after approval

Once a flow is approved and live, it runs from the trigger you confirmed. Sends pass through the same checks as every other marketing message: suppression, consent, frequency caps, quiet hours and the send gate for the account. If a check blocks a send, the run should record why rather than silently skipping the customer.

Results are reported per flow and per email. Opens are shown, but revenue attribution is click-based, because open tracking is not a reliable signal. The revenue per email page explains the attribution model in more detail.

You can pause a live flow without deleting it. Pausing is the right move when a promotion ends, when a supplier changes a shipping promise or when a message needs a rewrite. A paused flow keeps its history and its draft, so you can resume it after the approval for the new version.

Where the guardrails sit

The chat is allowed to propose, not to publish. It cannot add a purchased list, remove an unsubscribe link, invent a customer quote or promise a delivery time the store cannot meet. Those rules are enforced in the tool layer and in the approval view, not left to the model's judgement.

The model also receives product and brand data rather than profile emails. A flow draft does not need a customer's address to describe a wait or a subject line, so it should not receive one. That separation keeps the creative work useful without spreading personal data further than the send itself.

If a requested flow depends on an integration that is not available in your account, the draft should name the missing piece and stop. A convincing mock-up of an integration is worse than a clear gap, because it hides the work that still has to happen.

Related reading

• Approvals explains the gate that every draft passes through.
• Revenue per email explains how results are attributed.
• Mailprompt vs Klaviyo compares two different billing models.