DM flows

Build the conversation the bot sends after a trigger fires — single messages, branching questions, and handoffs.

A flow is the sequence of messages the bot sends after a trigger fires. You build the flow inside the automation editor.

The building blocks

A flow is made of nodes. The ones you'll reach for most:

Node	What it does
Send Message	Sends a text DM. Supports emoji and line breaks.
Quick Reply	Sends a message with tappable buttons and branches on the tap.
Wait for Reply	Pauses until the buyer types a reply.
Capture Field	Stores the buyer's answer (`shade`, `size`, `address`) for use later.
Condition	Splits the flow based on a captured field or an earlier answer.
Human Handoff	Stops the bot and hands the conversation to your team.

There are more — images, links, shared posts, Q&A cards, timers. See Flow nodes for the full reference.

Anatomy of a good flow

A flow that actually converts usually looks like this:

Acknowledge. One short line in the user's language confirming you heard them.
Answer the obvious question first. If they commented PRICE, give the price before anything else. Don't make them ask twice.
Qualify, only if needed. Ask one question to narrow the product (What shade are you? / 30ml or 50ml?). Skip if irrelevant.
Point to the next step. One line telling them how to order — your team will follow up to close, or send them to the link in your profile.
Offer a human. A quick-reply button like คุยกับแอดมิน that triggers a handoff.

Avoid: long opening greetings, multi-paragraph product descriptions, more than two qualifying questions, "Did that help?" follow-ups. Every extra message is an exit point.

Tone

Tuku is your brand's voice in the DM. The bot should:

Sound like a human typing on their phone. Short sentences. Real emoji, not stickers. One emoji per message at most.
Use the same language as the comment. Don't reply in English to a Thai comment.
Be specific. ฿890 for 30ml, ฿1,490 for 50ml lands better than Pricing varies — message us.
Never sound automated. Avoid Thank you for your message!, Our team will get back to you shortly, Please find the link below.

When in doubt: read it out loud. If it sounds like a corporate auto-reply, rewrite it.

Branching example

A shade-match flow for a foundation product:

Trigger: keyword SHADE
└─ Send Message "Hi! ขอบคุณที่สนใจ Foundation ของเรานะคะ 🌿"
└─ Capture Field "ปกติใช้สีอะไรของแบรนด์อื่นคะ?" → save to shade_reference
└─ Quick Reply "หรือเลือกจากนี้เลย:"
   ├─ "Fair"     → handoff to your team
   ├─ "Light"    → handoff to your team
   ├─ "Medium"   → handoff to your team
   └─ "ไม่แน่ใจ" → handoff to your team

When a step can't run

Sometimes a step can't do its job — a DM may be undeliverable, or a node may have nothing to act on. Tuku handles each case in one of three ways:

Behaviour	What happens	When
Stops the flow	The flow halts at that step; nothing after it runs.	A message step can't be delivered — the person isn't DM-eligible, or the messaging window or limit is reached. Covers Send Message, Send Link, Send Image, Share Post, Q&A Card, Quick Reply, Capture Field, and AI reply.
Skips and continues	That one step is skipped; the flow moves on to the next.	A Reply with no comment to reply to (e.g. a DM-triggered flow), or an AI reply that has no answer and no fallback set.
Pauses, then resumes	The flow waits, then picks up later.	Wait for Reply, Wait for Follow, and Timer — plus Quick Reply / Capture Field, which send and then wait for the buyer.

The practical upshot: in a comment flow, put a Send Message before a Reply. Because an undeliverable DM stops the flow, the Reply after it only runs once the DM has actually sent — so you never publicly say "check your DMs" when no DM went out.

Testing a flow before you publish it

As you build, the editor shows a mobile preview of your messages so you can see how each DM will look to the buyer.

For a real end-to-end test, comment on one of your own videos from a second account — the trigger will fire and you'll see the real DM land in the inbox.

Editing a live flow

Each flow has a draft you edit and a published version that runs. Make your changes in the draft, then publish to swap the live behaviour over. Until you publish, your edits don't touch any real conversations.