Notifications & Messaging

CleverOps sends customer-facing messages through a single multi-channel send-service. Instead of each feature wiring up its own email or SMS, everything that needs to reach a customer hands the message to one service, which decides how to deliver it based on the contact's saved channel preferences and consent.

This page covers the layer underneath every one of them: the channels, the routing model, and how to capture each contact's channel preferences and opt-in consent.

The messages that ride it are configured elsewhere and are live — job-stage updates including "technician on the way" and post-job feedback in Automations, invoice and payment chasing in Automated reminders, appointment confirmations in Job appointment reminders, and quote follow-ups in Quotes. All of them deliver through exactly the channels and preferences described here, and all of them obey the send window and daily cap set on Automations.

Channels and routing

There are four delivery channels. They are not all equal — they combine in a specific way:

• Email runs in parallel. It is the always-available, first-class channel (especially for documents) and is attempted independently of the others.
• App push → WhatsApp → SMS is a fallback cascade. The service tries these in order and stops at the first one that actually sends. If a channel is unavailable (not opted in, no contact detail on file, or not yet live) it falls through to the next.
• A WhatsApp that bounces still falls through. WhatsApp accepts a message first and only reports a few seconds later whether it could be delivered. When it reports a failure (most often: the number is not on WhatsApp), the cascade carries on to SMS for that message — under the same consent, messaging switches and budget as any SMS — and the Outbox shows the SMS as sent in its place. A number WhatsApp reports as not on WhatsApp is then skipped for WhatsApp for 30 days (Outbox: Not on WhatsApp) and goes straight to SMS; the mark lifts as soon as that person messages us on WhatsApp or a WhatsApp to them is delivered.

So a single notification might, for example, send an email and an app push; or send an email and — if the contact has no app — fall through to an SMS, but only if they opted in.

Channel	Status	Notes
App push (CleverAlert)	Live	Delivers only when the contact is linked to a CleverAlert app user. Reuses the existing CleverAlert push pipeline. Service-desk pushes carry a deep link into the customer portal — see below.
Email	Live	Sent in parallel. Uses the same email provider as invoice and quote sends.
WhatsApp	Live	WhatsApp Business template messages from CleverCam's two shared numbers — Service Desk (Cleo: jobs, quotes, invoices, statements, codes) and Control Room (Clava: alarms, open/close, heads-ups). Opt-in is required unless the message is a document the customer asked for. A message WhatsApp later reports undeliverable falls through to SMS (see above).
SMS	Opt-in gated — activates on configuration	A paid fallback, sent via SMSPortal. Only ever sent to contacts who have explicitly opted in (POPIA + cost), only once an SMSPortal account is configured, and only while the destination's SMS budget (see below) has headroom for the month.

Push needs a linked app user

App push is delivered to a contact's CleverAlert app. A contact who is not linked to a CleverAlert app user cannot receive push, and the cascade will fall through to WhatsApp/SMS. Link a contact to their app account from the contact editor (see below).

Push deep links into the customer portal

Where an SMS or WhatsApp message carries a customer-portal link (an invoice, a quote, a job appointment), the app-push version of the same message carries that destination too. Tapping the push opens the matching portal page inside the app — the invoice it announces, the quote awaiting a decision, or the appointment page with its reschedule request. This applies to the automation notifications for quotes (sent / follow-up / expiring), overdue invoices, and job updates (created, status change, on the way); job-lifecycle broadcasts ("appointment scheduled", the day-before reminder) open the app's native Service jobs list. The links use the same share codes as the text-message versions, so a customer sees one consistent document wherever they open it. Older app builds that don't understand the deep link simply open the app, as before.

Capturing channel preferences and consent

Channel preferences and consent live on each contact, on the customer's Sites & contacts tab.

1. Open Customers in the sidebar and select a customer.
2. Open the Sites & contacts tab and find the Contacts & notification preferences card.
3. Add a contact, or click Edit on an existing one.
4. In the contact editor, find the Notifications & consent section.
5. Set the channels this contact may be reached on:
   • App push (CleverAlert) — on by default. Only delivers if the contact is linked to a CleverAlert app user.
   • Email — on by default. Needs an email address on the contact.
   • Text messages (WhatsApp / SMS) — off by default. One consent covers both text transports. Tick only with the contact's explicit consent. Mainly relevant for contacts without a linked CleverAlert app, since push is preferred whenever one exists. Whether that consent reaches them by WhatsApp, SMS, or both is decided by the control room's channel switches (Settings → Messaging) — WhatsApp first (it's cheaper), SMS as the fallback.
   • When text is on, pick which alarm-event types this contact wants a message for — e.g. life safety and burglary, but not power/connectivity faults. Every type is selected by default (matching the historical all-or-nothing behaviour); at least one must stay checked or the contact will never be texted.
6. Save. When you switch the text consent on, CleverOps records a consent timestamp (and which staff member captured it) against the contact for audit purposes. Switching it back off records a withdrawal timestamp.

POPIA consent for text messaging

Text messaging (WhatsApp/SMS) is an opt-in channel. Only enable it when the contact has given explicit consent to be contacted that way. CleverOps never sends WhatsApp or SMS to a contact who has not opted in, and stamps the consent record on save so you have an auditable trail.

"STOP" replies file a ticket

If a contact or keyholder replies STOP to a WhatsApp or SMS message, CleverOps opts them out of that channel and automatically files a ticket — an Opt-out chip on the Tickets page — so your team knows to honour it and can decide whether to switch that contact's whole Text messages consent off. Repeated STOPs on the same channel don't pile up (one open ticket at a time), and the ticket carries the contact and their customer/site.

A STOP applies to the number, not just to one record: every contact and every keyholder on file with that number is opted out of that channel — a keyholder on several sites, or one phone shared by two contacts — and your control room gets one ticket, naming the first of them.

On WhatsApp the number also matches a contact's alternate number and a CleverAlert app user's phone. An app user's keyholder records are opted out too but file no ticket, because nothing your team texts them reads that consent. A WhatsApp STOP also means the automatic Clava alarm WhatsApp no longer reaches that keyholder on any site; your control room still handles the alarm as normal.

If they reply START on WhatsApp, every record at the number goes back to the WhatsApp consent it had before the STOP: a record that was never opted in stays that way, and one your team has ticked since stays ticked. A keyholder saved from the site's People tab after the STOP keeps its text consent off, because the save replaces the record START reads — tick it again if they want the messages.

SMS event-type preference isn't live yet

The per-event-type SMS preference is captured today so it's ready when it's needed, but no alarm-event notification currently reads it — CleverOps doesn't yet send an SMS automatically when an alarm fires (see "What's next" below). It will take effect once that automated alarm-event messaging is built.

Email and app push

Email and app push are treated as standard service channels and are enabled by default, because they are the normal ways a control room reaches an account holder. You can still turn either off per contact if a customer asks not to be emailed or pushed. App push additionally depends on the contact being a CleverAlert app user — without that link, push simply does not fire (the cascade moves on).

Linking a contact to their CleverAlert app account

The link is set on the contact, and CleverOps helps you find the right account:

• The picker. The contact editor's Linked CleverAlert app user dropdown lists every app user already connected to this customer's sites — plus any CleverAlert account whose email or phone exactly matches this contact's, even if that account hasn't joined one of the customer's sites yet (those options are labelled "matches this contact's email/phone").
• One-click suggestions. When an unlinked contact's email or phone matches exactly one app account, CleverOps offers it inline — a "This looks like …" card in the editor, and a "Looks like app user … — Link app user" row on the contacts list. The click is the confirmation; nothing is ever linked automatically, because a link shows that login the customer's documents.
• A suggestion is never made for an app account that's already linked to another of the customer's contacts, and ambiguous matches (two possible accounts) are never suggested.

Once linked, the contact's push notifications deliver to that app — including the service-desk deep links described above — and the app's My Account & Billing row lights up for that login.

Fallback order

By default the fallback cascade is app push → WhatsApp → SMS. This order is what makes SMS a true last resort: it is only reached when push and WhatsApp could not deliver, and even then only with opt-in. (A per-contact override of this order is supported in the data model for future use; the editor uses the default order today.)

Messaging usage, free allowances and rates

Outbound messaging is metered per control room, per calendar month, across every send path — document and reminder emails, notification-service sends, and event-conversation WhatsApp messages. Each channel has a monthly free allowance; volume beyond it is charged at a per-message rate:

Channel	Free per month (default)	Beyond the allowance
Email	1 000	R5 per started block of 100 emails (R0.05 / email)
SMS	0	R0.20 per SMS from the first
WhatsApp	0	R0.15 per message from the first

• The default allowances and rates above are platform settings; a CleverCam super admin can adjust them, and per control room can set both a free-allowance override and a per-message price override for any channel — e.g. a higher free-email tier, or a custom SMS/WhatsApp rate for one VCR. Both are edited from the Free / price control on that VCR's row under Super Admin → Messaging (a per-VCR custom price shows as @Rx.xx on the row).
• Super admins review volumes and computed overage under Super Admin → Messaging: per-VCR sent counts for each channel, the allowance applied, and the overage amount for the selected month.
• The overage amounts are currently informational — they are not yet added to the monthly Settings → CleverCam subscription breakdown.
• App push is not metered or charged.

Delivery logging

Every send attempt — including ones that were skipped (e.g. "not opted in", "no app user", "not implemented yet", or blocked by a budget) — is recorded in a delivery log, with all the attempts from one notification grouped together. This is what will power delivery reporting and "was this message received?" views as the messaging features roll out.

The text budget and the Outbox

Because texting has a hard per-message cost, each VCR caps its text spend so runaway usage — a misconfigured automation, an abusive contact spamming a site — cannot blow through the bill unnoticed. This lives under Settings → Messaging, split into four sub-tabs:

Budgets

Messaging switches. The first card is your own control over everything this control room sends its customers. It is there for taking on a customer with history behind them: an import can bring years of overdue invoices with it, and nothing else stands between that history and the customer's inbox. Import with both switches off, turn Messaging on so your staff can talk to people, then turn Automatic messaging on once you've checked what's waiting. Company owners and admins can change them, and each change asks you to confirm.

• Messaging — off means nothing reaches customers at all: no email, WhatsApp or SMS, whether automatic or sent by your staff. An invoice, quote, document or job notice sent by hand is refused. Alarm handling, dispatch and the app carry on as normal.

• Automatic messaging — off stops what goes out without anyone pressing Send; your staff can still message customers by hand. Turning Messaging off turns this off too. It holds:

  • invoice, quote, deposit and signature reminders, pre-debit notices and job appointment reminders
  • monthly summaries
  • automations
  • onboarding journey messages
  • alarm auto-replies (Clava), supervision escalation messages to the customer, and Log & notify alarm notices from Action Plans
  • event heads-ups, open/close receipts and late-to-close messages

  It also holds three messages to your own staff: decision notices, purchase-approval emails and guards' shift reminders.

Log & notify alarms go quiet

A Log & notify alarm never reaches an operator — the message to the customer is the whole response. While Automatic messaging is off, those alarms are only logged: no operator card and no customer message.

Alarm-time messages while Automatic messaging is off. Only the message to the customer is held; your operators see and handle everything as usual.

• An open/close receipt is not sent.
• A late-to-close nudge is not sent: no app push, no WhatsApp or SMS, no postpone link. The late-to-close event still wakes for an operator when its escalation window runs out, just as it does for a site with nobody to tell.
• An event heads-up is not sent, and the event timeline does not say keyholders were asked. A heads-up for a site that still looks open or not armed goes out later only if its alarm is still active when Automatic messaging goes back on (and at most 12 hours after the alarm came in). A pre-staged intrusion heads-up is never sent later.

A held message is recorded, never silently dropped. Texts, app push and the emails that automations, alarm notices and journey messages send show in the Outbox as Skipped, with the reason Automatic messaging off or Messaging switched off. So do held heads-ups, open/close receipts and late-to-close messages. Held reminder and document emails are recorded against the customer and show on their Messages sent view.

Preview what would send counts the scheduled messages that are due right now — invoice, quote, deposit and signature reminders, pre-debit notices and job reminders — and sends nothing. Run it before turning Automatic messaging back on: what it counts goes out on the next run. Messages fired by an event while the switch was off are not saved up, so Preview does not count them: automations, Log & notify alarm notices, onboarding journey messages, open/close receipts and late-to-close messages. They are recorded as held and are never sent later. Event heads-ups are not counted either; the one that can still go out later is described above.

Customer texting. Whether a customer can receive a WhatsApp or an SMS at all comes down to two settings:

1. Customer texting for the control room — set by CleverCam, shown read-only in the card under the switches. Off means every text is skipped; app push and email keep working.
2. The person's own consent — the single Text messages (WhatsApp / SMS) tick on a customer contact, or on a site person under Site People.

Both must be on. There is no per-site switch and no separate WhatsApp and SMS switches: WhatsApp is simply tried first because it is the cheaper channel, with SMS as the automatic fallback. This covers everything — receipts, reminders, service notices, and the alarm-time "Are you safe?" message alike. The Messaging switches above sit on top of both: they never make texting possible, but either one can hold a message back.

If the card says texting is off and you need it on, contact CleverCam.

Notices. The third card picks which automatic notices this control room sends its customers. These choose the content, not the channel — delivery is still decided by the settings above, and while Automatic messaging is off none of the three is sent:

• Event heads-up — tell the customer an alarm came in and is being handled.
• Open/close receipts — confirm each arm and disarm. High volume: one message per state change, per area (see below).
• Late to close — flag a site that hasn't armed by its expected time.

Receipts follow the state, not the signal

An open/close receipt goes out when the site changes arm state — not every time a panel mentions its arm state. If a panel reports "disarmed" for an area that is already recorded as disarmed, no message is sent.

This matters because some panels re-send their whole stored state on every reconnect. A radio panel that drops and re-registers every few minutes would otherwise send the same "your site was disarmed" to every keyholder each time, for a disarm that happened once. The genuine arm or disarm that follows still gets its receipt.

The check is per area, so on a multi-area site, one area arming is still announced while the others sit unchanged. Sites with no areas are checked as a whole. If an area has been silent for more than a week, the next signal is treated as news and sent — the receipt is only ever held back when there is a matching state on record to hold it against.

Alarm auto-reply (Clava). On control rooms with Clava, an emergency alarm can reach the customer automatically — an "Are you safe?" chat in the CleverAlert app, and a WhatsApp for keyholders who aren't on the app. It never fires on a duress alarm.

The fourth card sets which sites that applies to:

• Only sites I switch on (default off) — nothing auto-replies until you switch a site on individually. This is the default, and the one to use when you want to try it on a couple of sites before rolling it out.
• All sites (default on) — every connected site auto-replies unless you switch it off individually.

Either way, an individual site can override the default from its Monitoring → Operations settings (see Site details), and changing the default here never reverses a site you've already set explicitly. The card shows how many sites are switched on and how many off.

Two things still apply on top: Customer texting must be on for the control room, and each keyholder needs their own Text messages consent — switching a site on never messages someone who hasn't agreed to it.

Because the setting lives on the connection between your control room and the site, it never affects another company monitoring the same site.

One text budget. A single monthly budget covers WhatsApp and SMS combined (each send priced at its channel's rate — R0.15 per WhatsApp, R0.20 per SMS by default):

• Monthly text budget (VCR-wide) — an optional cap on the whole control room's aggregate text spend. Leave it blank for no cap.
• Default per-site text budget — what any site is capped at when it has no override of its own (see Site overrides below). Leave it blank for no cap, or leave the tab entirely unsaved and the platform default of R1000/month/site applies.

Both caps are enforced at send time. Once the site's effective budget or the VCR's aggregate budget is reached for the calendar month, further texts to that scope are skipped (logged in the Outbox as "Text budget reached") until the month rolls over — and the first blocked send each month files a ticket on the Tickets page with a Budget chip, so an exhausted budget is never silent. Live alarm conversations are never budget-blocked.

Site overrides

Search for a site to give it its own monthly text budget instead of the default — useful for a site that legitimately needs a higher allowance, or one you want to cap tighter than the rest. Only sites with an override are listed; every other site simply inherits the default above. To remove one, click Edit on its row, then Remove override beside Save and Cancel; after a confirmation the site returns to the default.

Outbox

Lists every message attempt for the selected month — email, app push, WhatsApp and SMS — with its destination, site, status, and the skip reason or provider error, filterable by channel, site and status. This is the practical "who did we message and did it go out" view; a blocked-by-budget attempt shows up here just like a successful send. The summary line shows the month's sends per channel and the combined text spend.

WhatsApp inbound

Every WhatsApp message a customer sends us that the system could not fully route lands here instead of disappearing — an unknown sender, a reply after the related alarm conversation already closed, a message to a number we don't recognise, or a Service Desk message (those are ticketed and answered by Cleo — see Service Desk WhatsApp (Cleo) — and shown here for reference). Each row shows when it arrived, the sender's number, the message, why it needed attention, whether an automatic reply went out, and the ticket it created (if any). Use Mark handled once someone has followed up; the Needs attention filter hides handled rows.

A row appears in your control room's list once the sender is recognised as one of your customers or keyholders. A message from a number no control room recognises is only visible to CleverCam. Automatic replies from other businesses' WhatsApp accounts ("Thank you for contacting …", office hours) that arrive seconds after one of our messages are shown as Another business's auto-reply (ignored) and are marked handled on arrival — nobody needs to act on them, and Cleo never answers them.

Service Desk WhatsApp (Cleo)

Customers can write to the Service Desk WhatsApp number — the number your statements, invoices, quotes, job reminders and verification codes come from. Cleo, the Service Desk assistant, answers straight away and files the conversation as a ticket for your team.

Who Cleo recognises, and what it may tell them. Cleo works out who is writing from what we have sent that number:

How the sender is recognised	What Cleo can do
A customer contact with that number (or they swiped to reply to one of our messages to that contact)	Everything below, within the contact's permissions (reschedule, bookings, payments)
A number we sent a customer's own documents to (a statement, invoice, quote or reminder), or the customer's billing phone	Answer about that account — open jobs, what is still owed, sites — and send the account link. Never a reschedule link (that permission belongs to a named contact).
A keyholder or app user of one control room, or a number we sent a verification code to	Answer general questions and give your company's contact details from Contact details. No account information.
A number no control room recognises	No reply (answering strangers invites spam). The message is kept for CleverCam.

What Cleo does. Answers questions about appointments, invoices and the account from the real records — the counts and amounts it quotes are the account's totals (every open job, every unpaid invoice by the amount still owed, how much of that is overdue), not a sample. It sends the customer's own self-service links (reschedule or cancel a visit, view the account and statements, pay), takes booking requests, arranges a call back, and says so plainly when it cannot help — it cannot arm or disarm an alarm, open gates or control any device, and it cannot send or read verification codes (it tells the person that each code expires 10 minutes after it is sent and to request a new one in the app). It answers in the customer's language (English or Afrikaans) and may offer up to three quick-reply buttons.

The ticket. Each sender gets one open ticket per control room (source WhatsApp). Every message they send, every Cleo answer and every team reply is added to it, so the ticket reads as the whole conversation — see WhatsApp conversation on the Tickets page. The subject starts with what the conversation is about — Payment, Reschedule, Callback, Complaint … — and moves up when a later message is more serious (a complaint outranks a payment question), gains [Urgent] when Cleo judges it urgent, and a snoozed ticket comes due again when the customer writes. A plain "thanks" is added to an open ticket but never opens a new one. Payment questions land on the Accounts desk; everything else on Other.

Answering as a person. Reply from the ticket's WhatsApp conversation panel. The reply goes out from the Service Desk number, signed with your first name, and Cleo stays out of that chat for 20 minutes so it never talks over you. WhatsApp only allows a free reply within 24 hours of the customer's last message; after that the panel says so and you phone them instead.

Cleo sends at most 8 replies to one number in 10 minutes; anything beyond that is still ticketed, just not answered automatically. Replying STOP opts the number out of WhatsApp messages; START turns them back on.

Customer event heads-up (live-alarm SMS/WhatsApp links)

For live alarm events, CleverOps can send the customer an SMS or WhatsApp message carrying a secure portal link they can tap to tell the control room what's happening. This reuses the same link-and-portal mechanism as the job and billing reminders — a one-tap page, no login. Two situations trigger a send:

• A dispatchable intrusion alarm (a camera-verified person/vehicle, or a panel burglary/panic) that is pre-staged (the Dispatch Copilot warms the nearest response unit — see Dispatch Copilot) — the customer gets the link while the operator is still working the keyholder call. (The Clava alarm WhatsApp from CleverCommand is a separate rail and carries no browser link — its "All is fine" verifies with tap buttons inside the chat; see Alarm auto-reply (Clava).)
• A site that still looks open or not armed after hours (a closing / fail-to-arm event) — so an open premises isn't mistaken for an intrusion.

The page offers the same three options as the CleverAlert app's reply row (and the WhatsApp first-contact buttons), calm → alarm:

• All is fine (on a closing event: I'm closing / arming later) — the confirm path, gated by the password challenge below.
• Phone me — asks the control room to call this keyholder back. The operator sees a "Customer requested a callback" entry plus a ready-to-tap call chip on the event board with the keyholder's name and number.
• Send help — an overt emergency request (two taps, so it can't fire by accident). It writes a strong "Customer raised an emergency" entry the operator acts on and pre-marks the event as a customer-declared emergency. It never auto-dispatches — an operator (or the control room's own automation rules) sends the unit. Being deliberately visible, it is the opposite of the silent duress path.

The "All is fine" password challenge. Any keyholder whose link is personal to them and who has a challenge word on file (the free-text password — the app's colour credential is never used on a human channel) is asked to prove identity by picking their word from a multiple-choice list: the real word among same-category decoys generated at send time, with the duress word sitting indistinguishably among the options. A keyholder with no word — including one who only has an app colour — is never challenged: their calm tap is recorded as an operator-facing signal only, and the page never asks for a colour. One attempt, and every processed tap shows the identical success screen:

• Correct password → the same two-tier resolve the app/WhatsApp rails use: an alarm still inside its response window auto-completes; one an operator has already seen soft-resolves for the operator to finalise. The event log shows the standard "All in order" entry. On a closing event it is marked closing-later instead.
• Duress password → silently escalates. Never a stand-down.
• Wrong password → the link locks silently and the control room is alerted on the event timeline plus a supervisor alert — but the customer's screen still shows the normal success page, so a typo and coercion look identical to anyone watching. The operator phones to verify.

Password gate, one attempt, duress-safe

Auto-action never happens on a tap alone — only a verified password resolves anything, exactly as the in-app flow requires. Nothing on the customer's screen (success page, locked link, reloaded page) reveals whether a tap was correct, wrong, or duress.

Who may stand an alarm down. Being sent the event is the authorisation: a keyholder who receives the alarm and gives the correct response password may stand it down, and one who receives a fail-to-close notice may postpone it. There is no separate per-keyholder permission — deciding who gets notified is the decision. (Until 2026-07-25 there were "May cancel alarms" / "May postpone schedules" toggles. They only ever gated the portal link — the WhatsApp rail ignored them — so the same customer with the same password got different outcomes depending on channel. Removed.)

Who receives it — the site's keyholders. The heads-up goes to the site's non-app users (keyholders without the app) who are opted in to text messaging. Manage them from the site: open a site → People tab → edit a non-app user → Off-app messaging (a single Text messages (WhatsApp / SMS) consent + which alarm categories). Because being notified is what authorises a stand-down, that consent list is the control — add someone here only if you'd accept their password-verified "all is fine". App users get push, not text; account-level billing/statement contacts live on the customer record.

Turning it on. Off by default and enabled per control room by a CleverCam super admin (customer_event_heads_up_enabled). While off, nothing is sent. When on, the message still obeys every rule on this page — it only reaches keyholders opted in (WhatsApp-opted keyholders get WhatsApp first, with SMS as the fallback), and the SMS leg only sends while the site/VCR SMS budget has headroom. The pre-staged intrusion heads-up additionally requires Dispatch Copilot pre-staging to be enabled. A heads-up is an automatic message, so while the control room's Automatic messaging switch is off it is held instead (see Messaging switches).

Photos on WhatsApp

When an alarm has a camera snapshot, CleverCam can put that image in front of the keyholder on WhatsApp — the picture answers "what actually happened?" far faster than words. This works two ways:

• In an active alarm chat (on request). When a keyholder is already replying to a WhatsApp alarm conversation and asks to see what triggered it ("send me the photo", "what set it off?"), the assistant sends the alarm snapshot straight into the chat, with a short caption. This is a free-form reply, only possible while the customer is inside WhatsApp's 24-hour conversation window (i.e. they messaged us), and it only offers a photo when one actually exists. It is never sent during a duress or wrong-password ("cover") turn, where replies stay deliberately neutral.
• On the heads-up itself (image header). The pre-staged-intrusion and closing heads-up messages can lead with the camera snapshot as the message's image, above the text and the reply button. Because a business-initiated WhatsApp message must use a Meta-approved template, this uses a dedicated image-header template variant and is gated off until those templates are approved on the sending number — until then (or when an event has no snapshot) the plain text heads-up sends exactly as described above. No image is ever attached to SMS.

In both cases the snapshot is only ever sent to an opted-in keyholder, and only when the alarm genuinely has a picture on file.

What's next

This send-service is the foundation. The features that will use it are delivered separately:

• Automated job-stage notifications — booked, "on the way" / ETA, completed.
• Invoice payment reminders and quote follow-ups.
• Post-job feedback / CSAT requests.
• Bulk messaging / campaigns to customers.

Each of those will emit through the channels and per-contact preferences on this page — so setting a contact's preferences and consent now means they are honoured automatically once those features arrive.