Every established money transfer business has sent the message it regrets: a rate promotion to customers who never use that corridor, a maintenance notice that went out after the window started, or a launch announcement to the whole base that brought a wave of unsubscribes. The problem is rarely the wording. It is that the message went to the wrong people, at the wrong time, through a process that needed a developer.
This guide is for marketing, customer and operations leads at operators who already have an active customer base. It covers how to design subscription channels customers will actually want, how to compose and schedule a broadcast, how to choose an audience and check its size before anything is saved, and how to handle the four messages you send most: rate news, corridor launches, service notices and maintenance windows.
Where it helps, we show how the Broadcast module in RemitSo's admin panel handles each step. The platform manages channels, subscriptions, audiences and scheduling. Your team still decides what to say, who needs to hear it and when.
Recognise why broadcasts stop being read
Customers stop reading broadcasts for one reason: too many of them were irrelevant. Each message that does not apply to the reader teaches them to ignore the next one, including the one that matters, such as a planned outage on the day they intended to send money.
Three habits cause most of it:
- One list for everything. Promotions, service notices and corridor news all go to the same audience, so a customer who only wanted to hear about outages gets offers too.
- No sense of size. Someone sends to "everyone in the corridor" without seeing how many people that is, and finds out afterwards it was the wrong segment.
- Developer-dependent sending. If a message needs an engineer to run a script, it gets sent late, or it gets sent to whatever list was easiest to pull.
The fix is structural: give customers a choice of what they hear about, send only to people who chose it, and let the team that owns the message send it.
Design subscription channels customers will choose
In RemitSo, broadcasts are organised around subscription channels that customers subscribe to, grouped into subscription channel categories. In this guide, "channel" means one of those: a topic a customer has chosen to receive, such as rate news or service notices. Customers hear about the topics they subscribed to, which is the consent that makes a broadcast worth reading.
Good channels share three qualities.
- Each one makes a clear promise. "Service notices" tells a customer exactly what they will get. "Updates" does not.
- Operational and promotional topics stay apart. Customers who opt out of offers should still be able to hear about maintenance. Put them in separate categories so the choice is obvious.
- There are few enough to understand. Four to six channels across two or three categories is plenty for most operators. Every extra channel is another decision for the customer.
A workable starting set: a Service category with service notices and planned maintenance; a Rates and offers category with rate news and offers; a Corridors category with news about new and changed destinations.
Rule of thumb: if you cannot describe a channel in one short sentence a customer would understand, split it or drop it.
Consent rules for marketing messages vary by country, and your compliance team should confirm what applies in your markets. A structure where customers subscribe to named topics makes those conversations easier, because you can show what each customer chose.
Compose and schedule a broadcast
RemitSo broadcast messages are composed and scheduled across channels from the console. That means the person who owns the message (a marketing lead for an offer, an operations lead for a service notice) writes it and sets when it goes, without a developer.
A few habits keep messages useful:
- Lead with what changes for the reader. "Transfers to this corridor will pause between 02:00 and 03:00 on Sunday" beats "We are upgrading our systems".
- Give the time and time zone. Your customers and their recipients may be in different zones.
- Say what the customer should do, or say plainly that they need do nothing.
- Write for the languages you serve. If your app runs in French or Spanish as well as English, plan the wording for those customers before you schedule.
Scheduling matters as much as wording. A message timed for when customers usually send, or a day before a change takes effect, is read; one sent at an hour nobody looks at their phone is not.
Choose the audience and check the count before saving
A broadcast in RemitSo can go to a chosen audience, and the console shows how many customers will receive it before the message is saved. This is the single most useful safeguard in customer messaging.
Use the count as a sense check every time:
- Far higher than expected: the audience is probably wider than you meant. Check before saving.
- Far lower than expected: subscriptions to that channel may be low, or the audience is narrower than intended. Either is worth knowing before you rely on the message.
- Zero: nobody will receive it. Better to learn that now than after the event it was meant to announce.
Watch for: an important service notice sent only to a channel few customers subscribe to. If a change affects every customer on a corridor, check the count and consider whether the notice also belongs in the app itself or in transaction emails.
Handle the four messages you send most
Rate news
Customers who care about rates want to hear when a corridor's rate is unusually good or a better rate is available to them. Send rate news to the rate news channel only, and keep it specific: which corridor, which rate, until when. Customers can also set their own rate alerts in the app (a daily rate, or a ping when the rate hits a target); our guide to rate alerts covers how the two work together without teaching customers to wait.
Corridor launches
A new destination interests the customers who send there, or who have family there, and few others. Use the corridors channel, and time the message for when the corridor is genuinely open: fees set, payout channels configured, rates loaded.
Service notices
Changes to how a corridor works, a payout method being added or removed, a new document requirement. These belong in the service notices channel, sent early enough for customers to act.
Maintenance windows
RemitSo books maintenance ahead with a start, an expected finish and a customer message, and pauses only what the work needs; transfers already under way carry on. Maintenance broadcasts can be sent automatically. Our guide to maintenance without downtime covers how to plan a window.
| Message type | Channel | Audience | Timing |
|---|---|---|---|
| Better rate on a corridor | Rate news | Rate news subscribers who send on that corridor | When the rate starts; say when it ends |
| First-transfer offer | Offers | Subscribers who have not yet completed a transfer | When the offer starts, with a reminder before it ends |
| New corridor open | Corridors | Corridors subscribers | Once fees, payout channels and rates are live |
| Fee change | Service notices | Subscribers on the affected corridor | About a week before the scheduled date |
| Payout method added or withdrawn | Service notices | Subscribers on the affected corridor | Before the change, early enough to update recipients |
| Planned maintenance | Planned maintenance | All maintenance subscribers | When the window is booked, and shortly before it starts |
The audience column describes who each message is for. How narrowly you can reach that group depends on the channels you set up and the audience you choose, so check each one against the recipient count before you save.
Pair a broadcast with a rate rule or promo code
A broadcast tells customers about an offer. The offer itself lives elsewhere, and the two should be set up together so the message never promises something the app does not deliver.
- Exchange rate rules give a customer group, platform, payout country or partner its own rate, fixed or as an adjustment that follows the standard rate. Rules can start on a date. New customers move to the Default group after their first completed transfer, so a New group rate works as a first-transfer offer. Set the rule, check its start date, then schedule the broadcast for the same time. Our guide to customer-specific exchange rates covers rule design.
- Promo codes, an optional add-on, give money off or a better rate, with limits, dates and uses per customer. A broadcast is the natural way to hand a code to the customers you want to use it. Set the code's dates to match the message, and its limits to match the audience count you saw. Our guide to money off versus a better rate covers which kind of offer to choose.
Takeaway: set up the offer first, test it as a customer would, and only then schedule the broadcast. A message about an offer that does not work yet is worse than no message.
Use broadcasts only for what they are for
Broadcasts are one of several ways the platform talks to people. Keeping each to its job is what keeps broadcasts relevant.
- Transfer updates are sent automatically as push notifications at every step, worded for the delivery method. They do not belong in a broadcast.
- Rate alerts are set by each customer for themselves.
- Team alerts such as failed payouts or chargebacks go to subscribed staff through Alert Management, not to customers.
- Broadcasts are for news a group of customers chose to hear: rates, offers, corridors, service and maintenance.
Scenario: announcing a new corridor with a first-transfer rate
The numbers below are illustrative, chosen to show the reasoning rather than to describe any real operator.
An established operator is opening a new destination for its sending currency. Its customers have been subscribing to channels for some months.
Step 1: make the corridor real first
Operations sets the fee rule, configures payout channels and loads rates. Marketing adds an exchange rate rule giving the New customer group a better rate on the new pair, starting on launch day.
Step 2: compose and check the count
The marketing lead writes a short message: the destination, the payout methods, the first-transfer rate and when it ends. Choosing the corridors channel, the console shows about 4,200 recipients. That matches expectations.
Step 3: catch a mistake before it goes
A second draft, aimed at customers who might also want rate news, shows about 31,000 recipients: the whole rate news channel. The lead drops it rather than sending a launch message to customers who never asked for corridor news.
Step 4: schedule
The broadcast is scheduled for mid-morning on launch day, after operations confirms the first test transfer has paid out. A reminder about the first-transfer rate is scheduled for two days before it ends.
Step 5: what customers experience
Customers who opted into corridor news hear about it once, on the day it works. Everyone else hears nothing. Those who tap through see the rate, the fee and the Total to pay before they commit.
Doing it with RemitSo
The Broadcast module sits in the admin panel; transfer updates, rate alerts and the quote itself live in the customer app.
- Subscription channel categories: topics grouped so operational and promotional messages stay apart, which benefits both: customers choose clearly, and your team keeps service notices reachable for those who decline offers.
- Channels customers subscribe to: messages go to people who opted in, so your customers get fewer, more relevant messages.
- Compose and schedule from the console: the owner of a message writes and times it, so your team reaches customers without a developer.
- Chosen audience with the count shown before saving: the number of recipients appears before anything is saved, so your team catches a wrong audience before it reaches anyone.
- Automated maintenance broadcasts: windows are booked ahead with a customer message and pause only what the work needs, so your customers know in advance and transfers already under way carry on.
- Exchange rate rules with start dates: a group rate starts on the day the broadcast goes, so your customers get exactly what the message promised.
- Promo codes, an optional add-on: codes with dates, limits and uses per customer can be handed out by broadcast, so your team controls the cost and your customers get a clear offer.
- Customer-set rate alerts: customers who want rate pings set their own, so your broadcasts do not have to carry them.
What your team still does: decide the channel structure, write every message, choose each audience and judge when it should go.
Frequently asked questions
How many subscription channels should we create?
Usually four to six, grouped into two or three categories. Each should make one clear promise. Too many channels make the choice harder for customers and the audiences too small to be useful.
Can we see how many customers will receive a broadcast before sending?
Yes. In RemitSo the console shows how many customers will receive a message before it is saved, so a wrong audience can be corrected first.
Should transfer status updates go out as broadcasts?
No. Transfer updates are sent automatically as push notifications at each step, worded for the delivery method. Broadcasts are for news customers chose to hear.
How do we tell customers about planned maintenance?
Book the window ahead with a start, an expected finish and a customer message. RemitSo can send maintenance broadcasts automatically, and the window pauses only what the work needs.
Do we need promo codes to run an offer by broadcast?
No. An exchange rate rule for a customer group can carry a better rate without a code. Promo codes are an optional add-on for when you want limits, dates and uses per customer on a code you hand out.