Automations
Automations turn an event (something that happens in CleverOps) into one or more actions (something done automatically). Instead of remembering to message a customer when a job is booked, when a technician is on the way, or to ask for feedback after a visit, you configure a rule once and the system runs it for you.
Each automation belongs to a single VCR and has three parts:
- Event — when it runs (e.g. a job is completed, a technician is on the way).
- Conditions — optional filters that narrow when it should fire (e.g. only when a job's new status is In progress).
- Actions — what happens (notify a contact, create a follow-up task, or request feedback).
Automations are part of the CRM / Service Ops module, so the Automations tab appears in Settings only when that module is enabled for your VCR.
Overdue-invoice reminders and outstanding-quote follow-ups have a dedicated home: Payment Reminders (Settings → Reminders → Customer reminders) — keep the routine cadence there. Automations also offer Invoice overdue, Quote follow-up due, and Quote expiring soon events for layering extra escalation on top (e.g. notify your own team, or file a ticket). If you enable an automation on one of these events while the matching dedicated reminder is on, the editor warns you and requires an explicit acknowledgement before saving — both systems firing means the customer is contacted twice for the same milestone.
Accessing Automations
- Navigate to Settings in the sidebar.
- Under Customer messaging in the Settings navigation, click Automations.
The tab has two sub-tabs for two different audiences:
- Customer notifications — the customer-facing journey (this is what most of this page covers). Rules are grouped into the lifecycle a customer actually experiences: Job lifecycle, Quotes & sales, and Billing.
- Service desk — the internal Service health auto-tickets monitor, which files tickets for your own team and never messages customers.
Quick start: starter automations
The fastest way to begin is the starter set. On an empty Automations tab, click Add starter automations and CleverOps installs a ready-made, fully-editable set covering the most common cases:
- Job booked — confirm a new job to the customer.
- Work started — tell the customer when a technician begins (job status → In progress).
- Technician on the way (ETA) — notify the customer when a technician marks themselves en route.
- Job completed — confirm completion to the customer.
- Post-job feedback request (CSAT) — ask the customer to rate the service.
Adding the starter set is safe to repeat — any template you already have is skipped, so you only ever get one of each.
The starter automations are normal rules. Open any one to change its message, recipient, channel, or conditions — or switch it off if you don't want it.
Creating an automation
- Click New automation.
- Give it a Name (and an optional description).
- Choose the event under When this happens.
- Set any conditions the event offers.
- Add one or more actions under Do this.
- Leave Enabled on (or switch it off to save a draft), then click Create automation.
Events
| Event | Fires when | Conditions available |
|---|---|---|
| Job booked | A new service job is created | — |
| Job status changes | A job moves to a different status | Only when the new status is (any / scheduled / in progress / on hold / completed / cancelled) |
| Job completed | A job is marked completed | — |
| Technician on the way | A technician marks themselves en route (with an ETA) | — |
| Quote sent | A quote is sent to a customer | — |
| Invoice overdue | An invoice is past its due date with a balance still owing (checked once a day, in the morning) | Only when days overdue is at least N |
| Quote follow-up due | A sent sales quote has passed its follow-up date (checked once a day) | — |
| Quote expiring soon | A sent sales quote's valid-until date is within the next 3 days (checked once a day) | — |
The three daily-checked events overlap Payment Reminders — see the note at the top of this page. A daily check fires again each day the condition still holds, so give those rules a cooldown.
Actions
- Send a notification — message a recipient across the channels they accept (see Delivery and channels below). Choose the recipient (customer, site contact, or assigned technician — see who each one reaches). Write a subject and a message using
{{variables}}(listed beneath the message box) — see Writing the message. Leave either box blank to send the standard wording for that event instead. A live Preview below the message shows exactly what the customer will see, with sample data filled in; when the standard wording is in use it says so. - Request feedback (CSAT) — send a post-job rating request containing a one-tap feedback link (
{{csat_url}}). Jobs only. The customer lands on the portal's review page and answers in one tap — All good, Please call me or Something's not right — with an optional 1–5 rating and a note. The rating comes back onto the job form (the Customer review panel) and the customer's Activity timeline; the same panel — and the Review & invoice queue — lets staff ask again by email, WhatsApp or SMS, and a low score (1–2) files an Operational follow-up ticket automatically. Requests left unanswered expire 14 days after they were last sent. See Customer review. - Create a follow-up task — open an internal task/ticket so a person follows up. Choose the task type and an optional due time. The task is filed against the job or quote that fired it (for an overdue invoice, against its customer).
An automation can have several actions — for example, Job completed can both notify the customer and send a feedback request.
Writing the message
Type {{variable}} to insert a detail, for example Hi {{customer_name}}. A variable with nothing in it — or a name that isn't one of the listed variables — becomes blank.
To include words only when a variable has a value, wrap them in a section: {{#name}} … {{/name}}. The starter Job booked message uses one, so a job without a booked time doesn't end on a dangling "for":
Hi {{customer_name}}, we've booked your job "{{job_title}}"{{#scheduled_at}} for {{scheduled_at}}{{/scheduled_at}}.
sends "…your job "Alarm service call" for Fri 18 Sep, 09:00." — or, with no time booked, "…your job "Alarm service call"." The opposite, {{^name}} … {{/name}}, includes its words only when the variable is empty.
Details are written the way a customer reads them:
| In the message | Reads as |
|---|---|
Dates and times ({{scheduled_at}}, {{expires_at}}, {{due_date}}…) | South African time, 24-hour: Fri 18 Sep, 09:00. Dates show just the day, Fri 18 Sep; the year appears only when it isn't this year. |
| A job booked as Morning, Afternoon or Evening | Fri 18 Sep, in the morning — the clock time stays hidden from the customer, as the job form promises. An Estimate reads around 09:00. |
Amounts ({{balance_cents}}) | R 1 250.00 |
Statuses ({{to_status}}) | Words, not codes: in progress, on hold |
When the subject or message is blank — or whatever you wrote comes out empty for a particular job — the standard wording for the event is sent, for example Your job is booked / Hi Thabo, we've booked your job "Alarm service call" for Fri 18 Sep, 09:00.
Delivery and channels
At the top of Customer notifications sits the Delivery card: a short statement of how messages travel, a row of channel chips, and your send limits. There is no delivery switch here to find or forget.
Notifications go out through the platform's multi-channel messaging service: email in parallel, then a push → WhatsApp → SMS cascade that stops at the first channel that reaches the customer. Customers without the CleverAlert app are reached too — by email, and (once they've opted in) WhatsApp or SMS.
Automation messages are automatic messages. While the control room's Automatic messaging switch is off under Settings → Messaging — the switch for taking on an imported customer base — every one of them is held: it shows in the Outbox as Automatic messaging off and is not sent later when the switch goes back on. Follow-up tasks and tickets are still created.
The channel chips reflect the WhatsApp / SMS switches on the Messaging tab — that tab owns them (a channel switched off there shows as off in Messaging here, and an action restricted to that channel won't send).
| Channel | Reaches |
|---|---|
| App push | Customers with the CleverAlert app installed. Always available. |
| Contacts with an email address on file — or the billing email on the customer record, when the contact has none or the customer has no contacts. | |
| Opted-in contacts, once your WhatsApp sender is approved. | |
| SMS | Opted-in contacts, within your monthly SMS budget. |
Each action's channel selector chooses how to deliver:
- Automatic — the full cascade above (recommended). Every channel the customer accepts is tried.
- App push / Email / WhatsApp / SMS only — restrict to a single channel.
| Recipient | Resolves to |
|---|---|
| Customer (billing contact) | The customer's contact tagged for this kind of email (Service jobs, Quotes or Invoices & receipts — see Email documents), otherwise their primary contact, then the next in call order — reached on every channel that contact accepts. A contact who covers only some sites is only chosen for those sites. When that contact has no email address, or the customer has no contacts at all, the email goes to the customer's billing email. A job or quote with no customer attached goes to the customer of its site, provided that customer belongs to your control room. |
| Site contact | A contact at the site first; otherwise the customer's contact, as above |
| Assigned technician | The technician assigned to the job (app push) |
WhatsApp and SMS are only ever sent to contacts who explicitly opted in (POPIA), and every SMS/WhatsApp send counts against the caps on the Messaging tab. A customer who replies STOP is never messaged again on that channel. Email and app push carry no per-message cost. Delivery is near-real-time (a background job runs every minute); every send is logged — app push in the recipient's notification history, and email/WhatsApp/SMS in the Messaging tab's outbox. Follow-up tasks are created immediately.
Feedback requests go out multi-channel too. The one-tap rating link is delivered as a full clickable link in email / WhatsApp / SMS (and app push), so a customer without the app can still rate the visit.
Send limits
Automations fire the moment something happens. That is right for the event and wrong for the customer at 21:40 — so the same Delivery card carries two limits, applied to automated messages only. Anything a staff member clicks Send on (an appointment notice, a completion note, a cancellation) always goes out immediately.
Hold messages between — the overnight window (default 20:00–07:00), set as a time window. Messages raised inside it are held, not dropped: a job signed off at 21:40 reaches the customer when the window next opens. Nothing is lost, it just arrives at a civilised hour. Set the two times the same to send around the clock.
Set the two times the same and the control shows Same start and end — the whole day, because that is what an equal start and end means on every other window in CleverOps. On this one field it is the wrong way round: equal times switch the overnight hold off entirely, so automated messages send around the clock rather than being held all day. Nothing is ever held for 24 hours.
Max per customer per day — a ceiling on how many automated messages one customer can receive in a day (default 4; clear the box for no limit). Between a booking confirmation, two appointment reminders, an on-the-way heads-up, a work-started note, a completion note and a feedback request, a customer with two jobs in a week can otherwise collect a lot of messages.
Going over the daily limit drops the message rather than holding it, and records the reason. This is deliberate: these notices are time-relevant, and "your job is booked" arriving two days late is worse than not arriving. The limit counts a whole customer, not each contact — three contacts in one household don't multiply it by three.
Someone twenty minutes from your customer's gate always gets through, whatever the hour and whatever the daily count. It's the one message where being late or silent costs a wasted callout — and nobody is en route at 03:00, so the exemption can't become a nuisance.
Both limits apply to every control room, and a control room that never opens this card still gets the defaults — 20:00–07:00 and 4 per customer per day. Only control-room managers can change them.
Did it actually send?
Underneath the limits, a Last 7 days line reports what they did: how many automated messages were delivered, how many are waiting for morning, how many went over the daily limit, and how many found no channel to reach them at all. States with nothing in them stay hidden, so the line is short on a quiet week.
This exists because a limit you can't see is indistinguishable from a bug. If the cap is set too low, or a customer has no reachable channel, the number tells you instead of the message quietly disappearing.
For the detail on one job — every message, which channel carried it, and whether it bounced — open the job and use Customer comms (see Creating a job).
The "On the way" notification
The Technician on the way event is triggered from the job itself. Open a job and, in the Dispatch section, optionally enter an ETA (minutes) and click Mark on the way. This stamps the job as en route and fires the event, so any matching automation notifies the customer.
The starter template sends:
Hi Thabo, your technician Sipho Ndlovu is on the way — expect them by about 14:30.
Who is coming. For a security company this is not a nicety: the customer is about to open their gate to a stranger, and a name they were given in advance is something they can check against the person who arrives.
{{technician_note}}— use this one. Renders "your technician Sipho Ndlovu is", and falls back to "your technician is" when the staff record has no name, so the sentence always reads properly.{{technician_name}}— just the name, for building your own sentence.
The name comes from the technician's staff record (first and last name), falling back to their roster label. If your roster uses handles like Tech 2, tidy the names on the People page — the customer sees whatever is there.
When to expect them. The technician thinks in minutes, but the customer always gets an absolute clock time. A relative ETA goes stale the moment it is sent ("about 60 min" read four hours later looks like a broken promise).
{{eta_note}}— use this one. Renders the whole suffix " — expect them by about 14:30", or nothing at all when no ETA was entered, so the sentence stays clean either way.{{expected_by_time}}— just the clock time (14:30, SAST), when you want to build your own sentence.{{eta_minutes}}— the raw minutes. Avoid it in customer-facing copy for the reason above.
Letting them call the technician. Available, but off by default:
{{technician_phone_note}}— renders " You can reach them on 082 123 4567.", or nothing when there's no number.{{technician_phone}}— just the number.
The number comes from the technician's own login profile, which for many teams is a personal mobile. Sending that to customers should be a decision, so nothing does it until you add the variable to the message yourself.
The technician's profile picture is carried with the notification, but nothing displays it — showing a face on the customer's push notification needs a CleverAlert app change that hasn't been made.
After clicking Mark on the way, the confirmation toast echoes the exact time the customer was promised. The CleverAlert app shows the same absolute time on the customer's visit card — and once that time has passed, the app switches to "Technician is on the way and will be with you as soon as possible" rather than displaying a stale or negative countdown.
Service health auto-tickets
The Service desk sub-tab holds the Service health auto-tickets card — an opt-in monitor that watches this control room's monitoring signals and files a ticket when a site shows a pattern that usually needs a technician. It is the bridge between the monitoring side and the service desk: monitoring noise becomes triaged, billable service work automatically. Unlike customer notifications, this monitor only files internal tickets — it never messages customers.
It only ever files tickets — never jobs. A tech coordinator reviews each auto-ticket and decides whether it becomes a job, attaches to existing work, or gets dismissed.
Detectors
| Detector | Fires when a single site logs… | Default threshold |
|---|---|---|
| Comms unstable | panel/CCU offline alerts (E350) | 10 in 7 days |
| Repeated mains failure | AC-failure alerts (E301) | 3 in 7 days |
| Camera detection noise | camera detections that are cloud-checked but never verified | 750 in 7 days |
| Integration key expired | an active Integration key expired event — a linked panel's API key (e.g. Olarm) no longer authenticates, so CleverCam can't sync, arm or disarm that panel until the key is renewed | immediate; one ticket per affected hub |
Each detector has its own on/off toggle and threshold (the key-expired detector is existence-based, so it has no count threshold). The look-back window is capped at 7 days (older events are pruned from the platform), and the cooldown (default 14 days) controls how soon a pattern may file again after its previous ticket is closed. While an auto-ticket for a pattern is still open, the same pattern is never filed twice.
How it runs
- Off by default. Nothing is filed until a control-room manager enables the card and saves.
- Once enabled, a daily scan runs in the early morning. Run scan now runs it immediately for this control room and reports how many tickets were filed.
- Auto-filed tickets appear on the Tickets page with a violet Auto chip, the byline "Filed by the Service health monitor", issue domain Technical, and the site attached — so the open-work radar and the normal convert/attach triage flow apply to them like any other ticket.
Only control-room managers can change these settings; everyone else sees them read-only.
Payment reminders (overdue invoices & quotes)
The routine reminder cadence for overdue invoices and outstanding quotes lives in Payment Reminders (Settings → Reminders → Customer reminders) — that's the customer-facing chase sequence, with grace days, repeat interval, and a cap. The Invoice overdue, Quote follow-up due, and Quote expiring automation events here are for layering escalation on top of it (notify your own team, file a ticket, or send an extra nudge). When the matching dedicated reminder is on, saving an enabled automation on one of these events requires ticking an acknowledgement that the customer may be contacted twice for the same milestone.
Enabling, editing, and deleting
- Enable / Disable — use the button on each rule. A disabled rule keeps its configuration but never fires.
- Edit — open a rule to change its event, conditions, actions, or cooldown.
- Delete — open the rule with Edit and use Delete automation in the Danger zone at the bottom. It removes the rule; past activity stays in the log.
Cooldown
Each rule can set an optional cooldown (minutes) per subject. Within that window the rule won't fire twice for the same job, quote, or invoice — useful for events that can flap (for example, a job status that toggles back and forth).
Activity log
Expand Recent activity to see the most recent times your automations ran, including which rule fired, the event, and the outcome (success, partial, failed, or skipped). This is the quickest way to confirm an automation is working and to spot, for example, a notification skipped because a contact had no email or phone on file.
Best practices
- Start with the starter set, then tailor the messages to your brand voice.
- Make sure customers can be reached — every notification is multi-channel, but it still needs somewhere to go: a contact (email, the CleverAlert app, or WhatsApp/SMS once they've opted in) or a billing email on the customer record. A job with no customer, on a site with no customer, can't be messaged and is logged as skipped. To see what a customer actually received, open the job's Customer comms.
- Use conditions to stay relevant — e.g. only notify Work started on the In progress status, not every status change.
- Set a cooldown on noisy events to avoid double-messaging a customer.
- Check the activity log after setting up a new rule to confirm it fires as expected.