Outreach

Rules that find the clients who are due, and write to them.

Outreach reaches people you already have. You describe who should hear from you — “due for a Botox”, “two sessions left on a course”, “not back in six months” — and Moshivo finds them in your own history and sends each one a message with a link that books.

It is not Campaigns, which reads what your paid advertising did. That one looks outward and measures; this one looks inward and sends.

The board

One row per rule: its name, who it targets written out in words, and its results — sent to 40 · 6 booked. Booked is counted from the link in the message, so it is the number that says whether the rule earns its keep. Above the list, how many people have opted out; every rule skips them.

The board — each rule with who it targets and what it brought back.
The board — each rule with who it targets and what it brought back.

Writing a rule

New rule opens a form in three parts.

Who it targets. Every condition you add must be true, so conditions narrow rather than widen. You can ask for someone due for a service (any recurring one, or a named one — it uses the recurrence set on Services against that client's own history), not back in N months, a first visit within N days, at least N visits, has had or never had a given service, or no-showed and never rebooked. A rule with no condition is refused, because it would reach every client you have.

What it offers.The service the message is about, an optional discount — percentage or amount, valid for a number of days — and your own sentence. You do not have to explain why you are writing: when the rule targets a recurrence, “It has been three months since your Botox with Dr Napat” is written for you from the facts that made the match, and your sentence follows it. That line is what books people; “we miss you” does not.

How it sends. One channel, Email or WhatsApp — there is no fallback, so a rule on WhatsApp skips anyone with no number. Then either I press send or Send by itself, nightly. Manual is the default on purpose: a mistyped condition should cost you a read-through, not four hundred messages.

Checking before you send

Audience shows exactly who a rule matches right now, and it is produced by the same code that does the sending — a preview that can disagree with reality is worse than no preview. Beside it, Send to 23 does it. An automatic rule runs each night and reaches only the people who have newly become due.

Nobody is written to twice by the same rule, ever. That is enforced at the moment a person is queued rather than checked at send time, so two overlapping runs cannot double-send.

Marketing has a price, and it is yours

An offer promotes rather than confirms, which makes it a marketing message. On WhatsApp that means it is billed per send, it counts against Meta's per-recipient marketing limit, and enough reports restrict your own number — the one your clients message you on. This is the one place in Moshivo where sending more is actively worse than sending well.

Every message carries a way out, and an unsubscribe holds across the whole business. That is the consent mechanism the product has, and under Thailand's PDPA it is not decoration. An opt-out made between the queue being built at night and the message going out is honoured too.

Prepaid courses

Two conditions read packages instead of inferring from the calendar: Sessions left, at most and Package expires within N days. They are stronger than everything above because they state a fact the client already paid for rather than a guess, and unlike every other condition they do not require a past visit — someone who bought a course and never came back is exactly who they are for.

A balance reminder is not an offer and does not use the offer message. It has its own, so it carries none of the cost or the limits described above: telling someone what they already own is a service message. And it follows the purchase rather than the person, so a client who buys a second course next year can be reminded again.

Outreach is included from Growth. A queue built on Growth pauses on a downgrade rather than being lost.