Onboarding

Onboarding tracks a journey — one new customer's road from an accepted quote to a live, monitored site: the paperwork, the pre-staging, the install visit, and go-live, all on one board. It picks up exactly where Leads leaves off — the pre-sale pipeline (New through Quoted) stays on the Leads board, and a journey covers everything after a deal is real, whether that's a brand-new install, a takeover of an existing alarm, or an add-on for a customer you already have.

Onboarding journeys module — alpha

Onboarding is gated by the per-VCR Onboarding journeys module and currently ships at alpha stage. If you don't see Onboarding in the Sales switcher, anyone who can manage the VCR can switch the module on from the Modules & capabilities board on Settings → General, or a company owner can do it under Company Admin → Company Settings → Modules.

Open Sales from the sidebar (CRM group) and it lands on the shared Sales overview — funnel analytics built from journey milestones, alongside the leads and quotes overview tiles. A slim Overview | Leads | Quotes | Onboarding switcher sits above the header on all four screens for hopping between them (the Onboarding item itself is hidden for companies without the module). Pick Onboarding in the switcher and it lands on the Board tab, with a Settings tab beside it for the per-company configuration, and — for anyone with permission to manage sales — an Import tab beside those for bringing in a book of business in bulk (see Bulk import).

Funnel analytics

Pick Overview in the switcher (or land there directly from the sidebar) and, with the module on, the shared Sales overview opens with an Onboarding journeys section ahead of the leads and quotes tiles — built entirely from the per-stage timestamps each journey carries (enquiry, first contact, quote sent, accepted, installed, live). It's read-only: nothing here sends a message or changes a journey. The same analytics also live on the Onboarding page itself, under the Insights tab, for when you're already working the board.

KPI tiles — Active (journeys in flight now), Live in 30 days (went live this month), Median time to live (the median number of days from enquiry to live, over journeys that have gone live), and Conversion (the share of all journeys that reached Live).
Conversion funnel — how many journeys reached each milestone, Enquiry through Live, with each bar also showing its percentage of the enquiry count. A milestone counts as reached if its own stamp or any later stamp is set, so a journey started part-way through (skipping enquiry or first contact) still counts at every step up to wherever it actually got to.
Time in each stage — the median number of days between each pair of consecutive milestones, counting only journeys that carry both of that pair's timestamps, in order.
Started vs went live — an 8-week trend of journeys started against journeys that went live.

Active, Live in 30 days, and each bar of the conversion funnel open the Onboarding board; unlike the leads and quotes tiles, the board isn't pre-filtered to that milestone.

Everything a journey does already works without staff: the Getting Started link collects the details, the customer record is minted, the site is pre-staged, panic-app cover links the hub and sends the app invitation. The only thing that needed a person was the first click — so Onboarding → Settings → Sign-up link publishes one public link (or QR) that a person fills in themselves.

Create a sign-up link makes it; it is inert until you tick Active. Then choose:

What a sign-up becomes — Panic app cover, Just collect their information, Link an existing alarm or Install a new system. Whichever you pick, the journey created is exactly the one the Start onboarding wizard would have created with the same answers, including its task pack, gates and plan.
Location cover only (panic app cover) — for people with no premises: the page never asks for an address and the journey is created as location-only cover.
Headline and a line under it — the words on the page. Nothing else about your control room is exposed: the page shows only your name, logo and brand colour.

Share the link (Copy). Someone opening it gives their name, mobile, and optionally an email and company — then lands straight on their own Getting Started page to finish the rest, exactly as if you had sent them the link yourself. You see the journey on the board like any other, with "signed themselves up from your sign-up link" on its timeline.

Abuse is handled for you. The submit never runs from the browser: it goes through a server-side endpoint that hashes the visitor's IP (no raw addresses are stored), refuses more than a few sign-ups an hour from the same connection, and silently drops anything that trips the hidden honeypot field or fills the form impossibly fast — a bot gets a thank-you and nothing is created. The card shows the last 30 days: how many signed up, and how many were turned away.

Needs attention

Above the board sits a strip that answers a different question than the columns do. The columns answer "where is everything?"; Needs attention answers "what is waiting on me?" — across every stage, not just one column — sorted oldest wait first, because the longest-suffering customer is the one to call.

A journey lands here for one of three reasons, each shown with its own wording:

Waiting on us — the journey's own persisted waiting_on flag says the next move is staff's: a gate on Staff approve is holding it, the customer has submitted something nobody has checked yet, or the service agreement has not been prepared — the Sign your service agreement step is open but nothing has been built for the customer to sign, so it is the company's move, not theirs (the hold reads "Agreement not prepared — nothing for the customer to sign yet", with a count of any other steps that genuinely are with the customer). The card shows the exact hold sentence the journey is carrying (for example "Waiting for staff to open onboarding"), not a generic label. When nothing is left with the customer, the hold names what the company has not done yet rather than a generic "next move is ours": "Answers are in — open onboarding to create the customer" (every form is in, and the agreement, debit order and app invitation need a customer record), "Site not created yet — create it from the customer's answers", "No visit booked yet — create the install job", or "Install job has no date yet — book it on the schedule board". Each carries its button — Open onboarding, Create the site, Create the install job, Open the install job — whichever way the gates are set, so a journey the automation could not move (no address to build a site from, for instance) is still one click from moving.
Stalled — nobody is formally blocked, but the journey has sat still past the company's own Stalled after threshold (see Clocks & money).
Automation failed — the journey's background automation errored repeatedly and gave up; nothing will move until someone looks. This outranks everything else, since it isn't a person's decision holding the journey, it's broken.

Each row carries the wait sentence, how long it's been waiting, and a button: some holds (opening onboarding, marking vetting passed, pre-staging the site, booking the install or the assessment) resolve in one click right from the strip; others (checking a customer's submission, approving go-live, preparing the agreement) open the journey's workspace instead, because reading what was submitted — or seeing the go-live evidence, or what the agreement can be built from — has to happen before anyone presses anything. When nothing is waiting on you, the strip collapses to a quiet "Nothing is waiting on you" line. Hide / Show tucks the whole strip away without losing the count.

The strip's holds are read straight from what the journey itself has recorded (waiting_on / held_reason, stamped the moment the hold happens) rather than recomputed from the current gate settings — so relaxing a gate afterwards can never make an already-held journey quietly disappear from the queue.

Board tab

Below Needs attention, the board is the map: one column per stage from a booked site assessment onward.

Column	What sits there
Assessment	A site visit is needed before the deal can be quoted or installed — a consultant walks the property and confirms coverage.
Onboarding	The quote was just accepted — customer inputs are being verified and mandate/credit steps are running.
Prepare	Blocking tasks are done; the pending site is being staged and the install visit is being booked.
Install	The install (or link/takeover) visit is booked and being carried out.
First 30 days	The settling-in window right after go-live.

Assessment is its own job kind and its own stage, distinct from the install visit — a technician who drives out just to survey a site books an assessment job, never an install job, so completing a survey can never accidentally take the customer live or start billing the way a mis-typed "installation" job once could. A journey only sits here once a survey has actually been booked; the column shows "No site assessments booked" rather than disappearing when it's empty.

There's deliberately no Live column: going live and settling into First 30 days happen in the same automated tick, so a Live column would sit permanently empty. A journey that has gone live shows a green Live <date> chip on its First 30 days card instead.

Each column header shows a count of the journeys sitting in it. Cards are ordered oldest-first and stay put — they never re-sort under your cursor when a background check touches a journey. Earlier sales stages (New, Contacted, Qualified, Quoted) stay on the Leads pipeline — a journey isn't minted onto these columns until a quote is accepted. A Show N pre-accept journeys on the Leads pipeline button above the board reveals journeys still in Enquiry, Contact, or Proposal (a booked site assessment gets its own column instead, as above) as a row of cards right there, so you can open a workspace, copy a Getting Started link, or review steps without leaving the Onboarding board, while the deal itself keeps being worked on Leads. Hide tucks the row away again. With none to show, the line is plain text rather than a button that does nothing.

The board refreshes itself: when a customer submits a step or an automated check moves a journey, the columns update without a manual reload.

Finding a journey

A search box above the board finds a journey wherever it sits — and that includes journeys the board itself never loads. The columns hold active journeys only, so an information request that completed itself the minute the customer answered, or a journey somebody cancelled, is not on the board at all. Search asks the database about the whole book instead: active, complete, lost and cancelled alike.

It matches the journey's name and reference, the customer, lead, contact or company name, the site name or address, the internal notes, the journey id, and the share code from the customer's Getting Started link — so a journey id quoted in an automatic ticket, an estate's own job number, or a share code a customer reads out over the phone all land on the right card. Two characters is the minimum. Clear empties the box.

While a search is running:

A line under the box says how many journeys matched — e.g. "3 matching journeys, across every journey, open or closed."
Matches that are still active stay in their columns, and the pre-accept row narrows with them.
Matches that are no longer active appear in the strip below the board, which opens itself so nothing found is left hidden. Completed journeys wear a green Completed chip there; lost and cancelled ones keep their red chip and reason. The Closed journeys button becomes a count of those matches and is greyed out — search owns the strip while it is running.

Journeys are also directly linkable. Opening a journey puts ?journey=<id> in the address bar, so the page can be bookmarked, refreshed, or pasted to a colleague and it re-opens that journey's workspace.

Start onboarding (the wizard)

Click Start onboarding above the board — the same button sits on the Customers page, in a customer's header, and behind a lead card's Start onboarding chip — to open the one wizard every kind of onboarding starts from. It asks three questions; nothing is created until the last step.

Who — a new person or company (name, phone, email, language; a company name makes it a business account), an existing customer (details pre-fill from the record, and identity is only asked again if no ID / registration number is on file), or a lead (pulls the contact details through; a lead that already decided its account keeps it). While you type a new person's name, phone or email, matches from your book are offered — Use this one switches to the existing customer instead of minting a twin. Segment (Residential / Business / Estate) follows the name and can be overridden.
What happens — the outcome you're after, in plain words: Just collect information (stop there; the answers land on the customer), Panic app cover (their home becomes a site with a Panic App hub and they get the app with site + location panic), Link an existing alarm (tick currently monitored by another company for a takeover), Install a new system (alarm, or cameras / CCU), or Change an existing site (an add-on, reconnect or relocation on a site the customer already has). Under the hood each maps to a journey kind — Info request, Panic only, Alarm link / Takeover, New install / CCTV + CCU, Add-on / Reconnect / Relocation — so every profile, gate and stage rule described on this page still applies. For collect information, link an existing alarm and install a new system you also pick How many sites? (1–10) and can give each a label (Head office, Warehouse, Shop): the customer then answers an address and keyholders once per site — the link headings read Site 2 of 3 — Shop, and every keyholder step after the first offers Use the same keyholders as site 1 — while identity, banking, the agreement and the app are asked once. At the finish each site is created on its own (site 1 is the journey's main site, the journey's Site tab lists them all with a created / waiting chip), with its own call list, and the answers for site 2 never overwrite site 1's. For every outcome except Just collect information, step 2 also has a Plan picker: tick the billing plan(s) the customer signs up for (your control room's active plans under Billing → Plans), with a quantity, an agreed price if it differs from the list price, and — on a multi-site journey — whether the plan applies to every site; a running per month, per site total shows beneath. The choice is carried on the journey: it fills the agreement's plan fields (plan name, monthly price, plan lines) when the contract is prepared, it shows on the journey's Site tab under Plan, and at go-live the subscriptions are started on the site — automatically when the Start billing at go-live gate is Automatic, otherwise by a person with Start billing now on that tab (a ticket reminds you). Journeys started from an accepted quote keep billing from the quote's subscription lines as before. An At the end we will… panel spells out what will be created and when, honestly reflecting your gates (Automatic vs Staff approve), whether customer messages are on, whether the control room has a published app, and whether location panic is switched on.
What to ask — the control room's own task pack (Onboarding → Settings), pre-ticked for the outcome and editable: identity, address & access notes, keyholders & safe words, agreement, debit order, uploads, the app. Sections that don't apply to the outcome or segment are not offered. Then who fills it in: Send the customer a link (WhatsApp / SMS first, then email, in their language — or copied by hand when customer messages are off) or I'll capture it now (opens the journey so you type the answers in on their behalf).

Finish reviews the three answers and creates the journey, snapshots the requested steps, mints the one-link Getting Started page and — when Send journey messages to customers is on — queues the link to send within a minute. Starting from a lead is idempotent: if that lead already has an open journey, the wizard opens the existing one instead of creating a duplicate, so re-clicking is always safe.

Choosing Panic app cover also asks where they need cover: At home and anywhere (the usual case — their home becomes the base), or Anywhere only — no fixed address, for someone with no premises at all. The second option creates the base with no address, doesn't ask the customer to confirm an address, and gives them Location panic only, so a premises panic is refused rather than dispatched to a placeholder. A panic base never gets an installation window either way — there is nothing to install, and a window would suppress the very dispatch the cover exists for.

A Panic app cover journey finishes itself: once the address and keyholder answers are verified, the site, Panic App hub and the account holder's Site + location panic entitlement are created (when the Pre-stage the site gate is Automatic — otherwise a person presses the button on the journey's Site tab), a person sends the app invitation from that tab, and the journey goes live the moment they connect the app (or waits for Approve go-live when that gate is on Staff approve). Go-live evidence for a panic-app journey is a linked hub on the site and a connected app user — a Panic App hub never sends a signal, so none is expected.

Which account the journey belongs to

A journey with no customer behind it creates one the moment it reaches Onboarding. That's right for a genuinely new customer and wrong for everyone else — a second account means a second agreement, a second debit order and a second statement for one person. The dialog therefore settles the question before you press the button:

The lead already points at a customer. The picker is replaced by a green line — "Linked to Acme Holdings — the lead already points at this account, so the journey uses it and no new customer is created." Nothing to choose; the journey uses that account.
No customer yet. Leave the picker on New customer — create one when onboarding opens for a brand-new customer, or search and pick an existing one for an add-on, a reconnect, a relocation, or a second property.
The lead's details match somebody you already have. An amber We may already have this customer panel lists the matches with the reason each one matched — Same billing email, Same phone number, Same name — and a Link this one button beside each. Linking is one click and avoids the duplicate entirely.

The customer is never told any of this. Nothing about whether an account already exists is shown on their Getting Started page — see Who the account is for.

Journey cards

Each card on the board shows the journey's name — whatever it has been called, or the customer or lead's name where it hasn't — the journey id (#N — the same id every automatic ticket quotes), an age chip, a pace chip where the journey has run past its target, one chip carrying the kind and segment together (New install · Residential), and — once the pending site has been created for it — a green Site chip.

The pace chip reads "Day 34 of 21" — the journey's total age against that kind's delivery target, seeded per kind/segment and editable under Settings → Journey kinds. It appears on a card only once the journey is past its target — amber past it, red at twice it. A journey running to time is not news, and every card carrying two clocks side by side (a pace chip and an age chip) is two numbers to read on a surface whose whole job is to be read at a glance; the workspace's own header still shows the pace for every journey, on target or not. The chip only exists where a target is set for that kind/segment.

The age chip reads "3 days in this stage" and is measured from the moment the journey entered that column, not from the last time anything touched the record — so a background check can't quietly reset it. It turns amber once the journey passes your Stalled after setting (see Clocks & money) and red at twice that, which makes a column of ageing cards visible at a glance.

A journey held by a gate set to Staff approve carries an amber chip naming the hold — read straight off the journey's own persisted held_reason, not recomputed from today's gate settings, so relaxing a gate afterwards can't make a genuinely-held journey look fine: Accepted — approve to open (quote accepted, waiting for someone to open onboarding — these cards sit in the Onboarding column even though the journey hasn't formally entered it yet), Installed — approve go-live (install signed off, waiting for go-live sign-off), or Vetting (a business journey in Prepare whose credit vetting is holding scheduling). A journey whose automation has failed repeatedly carries a red Automation failed chip instead. Click a card to open the journey workspace.

The journey workspace

Opening a journey fills the screen — it's the surface deals are worked on, laid out like the site and customer experiences rather than a small dialog. Three zones:

The hero. The journey's name in large type — whatever it has been called, with the customer or lead it belongs to as a smaller line underneath so a rename never hides who it is for — with the journey's kind, segment, a whose-turn chip (Waiting on us / With the customer / Scheduled), its Ref chip if it carries one, and its pace chip (see Journey cards). A journey that has been closed carries a red Cancelled or Lost chip instead of a whose-turn chip, and a strip above the tabs saying when and why. Under them runs the milestone rail — Enquiry → Quote → Onboarding → Prepare → Install → Live — the staff twin of the progress rail the customer sees on their own page, with the real date stamped under every milestone already reached (Accepted 18 Jul, Install booked 21 Jul, …). Below the rail sits one next action, spanning the whole workspace so it's visible whichever tab is open: the same hold sentence and button the Needs attention strip offers, or nothing at all if the journey genuinely isn't waiting on anyone. A journey has exactly one next move at a time; showing five buttons of equal weight is how the real one gets missed.

The context rail (left). It scrolls on its own, independently of the working tabs, so reaching the bottom of a long tab never carries the Getting Started link, the tab bar or the next action off the screen with it — the hero and the next action stay pinned above both columns whatever you scroll. (On a narrow window the two columns stack and the whole workspace scrolls as one page, with the working tabs first.)

Customer — the contact phone and email from the journey's facts (tap-to-call / tap-to-email), plus chips linking through to the customer, lead, quote, install job, and assessment job wherever each exists yet.
Legal identity — who the account is legally for: the legal name and the ID or company registration number, once captured. When the same number (or the same email, phone or name) already belongs to another customer in this control room, the card shows them with a Link button. Linking points the journey at the real account and, if a prospect account had already been created for this journey and nothing has been attached to it yet, closes that duplicate. If the duplicate already has invoices, sites, subscriptions, quotes or jobs on it, the link is refused and says which — that's a merge, not a link, and it needs a person. The card is hidden entirely when there's nothing to say.
Getting Started link — the customer's one link for the whole journey, the same URL from first contact through to go-live and beyond. Copy link grabs it for a WhatsApp message or an email; Open the page shows you exactly what the customer is looking at. See The customer's Getting Started link below.
Internal — staff-only, and never shown to the customer or included in any message to them: Name this journey, a Reference (someone else's number for this work — an estate's job number, an insurer's claim), and free-text Notes. See Naming a journey.
This journey — how it ends: Mark lost, Cancel journey, Reopen, and Delete. See Ending a journey.
The site — once the pending site exists: its name, the address that actually landed, a 📍 Pinned / No map pin chip, and a keyholders chip (2 keyholders · 2 with safe words), with Open jumping to the full site page. The pin chip only goes green on a coordinate a responder could actually drive to — a site with one coordinate missing, or sitting on the 0, 0 placeholder some imports left behind, reads No map pin so nobody mistakes it for placed. The full call list lives on the Site & install tab.

The working tabs — Steps / Paperwork / Site & install / Facts / Activity. Old links and tickets that deep-link to the previous tab names (Overview, Tasks, Install, Timeline) still land in the right place.

Steps tab

The same steps the customer sees on their Getting Started page, in the same order, one card per step — numbered while open, ticked when done. Each card's header carries the step's kind (Form, Signature, Debit order, Document, App), what it blocks (Blocks install, Blocks go-live, Due after go-live — matching the Blocking setting on its task pack entry), the date it was received or completed, and a status chip:

Status	Meaning
Waiting on customer	Not submitted yet.
Not prepared	The service-agreement step while nothing has been built for the customer to sign yet — the hold is the company's, not the customer's. See The agreement step below.
Needs checking	The customer (or a staff capture) has filled it in and it's waiting on your review. It stays here until someone presses Verify — unless the company has switched Verify customer inputs to Automatic, in which case it passes straight to Done unread.
Received	A signature or debit-order step whose answers are in but which completes itself on signing.
Done	Verified correct, or signed.
Waived	Skipped, with a reason on file.

Seeing what you're approving. Click a card to expand it in place and read what was actually submitted, laid out as labelled fields rather than raw data. Anything answered as a repeated set — the keyholders, above all — is laid out as a table in call order: number, name, relationship, phone and response word in columns, so three people's numbers and three people's words can be compared down a column rather than read out of a run-on line. Account numbers are masked to their last four digits — enough to recognise the account, not to read it back out. If the step was sent back to the customer, the note you wrote appears as a highlighted banner.

Arriving from a queue opens the right step. When you come in from Needs attention's Check N submissions — or from the workspace's own next-action button, or a ticket that deep-links to the steps — the first step actually waiting to be checked is already expanded and scrolled to. You land on the submission, not on a list of collapsed cards with no indication which one is yours.

Verify only appears inside that expanded card, after the answers, and only for a step that has genuinely been submitted — you can't approve a submission you haven't looked at, and you can't verify a step that's still waiting on the customer. On a step that is waiting to be checked it is the card's primary action and comes first, ahead of Amend their answers. Steps that complete themselves when the customer signs — the debit-order mandate, the service agreement and any other signature or payment step — never offer Verify at all; they're signed off by the signature itself, and the card says so. Waive them if they aren't needed.

The agreement step. While no agreement exists for the customer to sign, the Sign your service agreement card reads Not prepared rather than Waiting on customer, and its expanded body says so plainly and fixes it in place: Prepare the agreement (built from the accepted quote), Prepare now anyway / Prepare again with a contract template in use, or — when the company has neither a template nor an accepted quote to build from — Set up a contract template, which opens Onboarding → Contracts. A Paperwork tab button sits beside it for the full envelope view. Once an envelope exists the card reads Waiting on customer again and completes itself when they sign.

Fill in for the customer. The Getting Started link is the customer's way in — this is yours. On any form or custom step that's still waiting or submitted, the expanded card offers Fill in for the customer (or Amend their answers on one already received): the same form the customer sees on their page opens inline inside the card — the details step includes the same address search plus a Pin the exact spot satellite map, so a phone capture lands with a real map pin — pre-seeded with anything already known. On the debit-order step the button reads Capture banking details — the mandate PDF is then prepared exactly as if the customer had typed their details, but the signature still comes from them on their own page; nothing here signs on their behalf, and signature and payment steps can't be captured at all. A staff capture is recorded on the journey's timeline, counts as a submission (so auto-verify, facts merging, and the mandate chain run identically), and the customer sees the step ticked off on their page.

Waive (on waiting or submitted steps) and Reopen (on done or waived ones) sit at the far end of the expanded card's action row; each opens a small dialog that asks for a reason, and neither will proceed without one. A waive reason is kept on the audit trail. A reopen reason is shown to the customer — the step reappears on their Getting Started page as outstanding with your note attached, so write it for them ("the ID photo is cut off — please upload the whole document"). If anything is rejected, the reason why is shown on the spot rather than the action silently failing.

Paperwork tab

Everything the customer has to sign or send, and the debit order, as one list with one status vocabulary — the service agreement, any ad-hoc document attached for signature, any document requested back from the customer, and the mandate all used to be four unrelated mechanisms with three different affordances, and the mandate — the one row that decides whether this customer can be billed — had no staff surface at all.

Every signature row also shows the envelope's real life — where the link went, whether it has been opened, and what has become of it — and carries the buttons that move it. That is more than a step's own status can say: a step reads pending right up until the moment it is signed, so "we haven't sent it yet" and "they've opened it three times and not signed" looked identical.

The debit-order mandate always sits first: Not signed yet, Signed <date> — NOT activated (signed but the Activate mandate gate hasn't switched it on — no collection will ever be attempted until it does), or Active — collecting, with the masked account details underneath.
The service agreement shows Not prepared until you click Prepare (builds it from the accepted quote — see Preparing the service agreement), then Awaiting signature, then Signed <date>. With a contract template in use, the row instead says what the automatic preparation is still waiting for, and offers Prepare now anyway (and Prepare again after a decline or withdrawal). With neither a template nor an accepted quote, nothing here can build it: the row says so and offers Set up a template (Onboarding → Contracts) instead — or waive the step on the Steps tab if the agreement was signed on paper.
Any attached document or requested upload shows the same shape in its own words — Awaiting signature / Signed <date> for something the customer signs, Awaiting upload / Received — needs checking / Received <date> for something requested back — because "Signed" on a proof-of-residence upload would be a lie.
Anything with a signing envelope behind it — the agreement, the mandate, and every attached document — reads its status from the envelope: Awaiting signature, Opened <date> — not signed, Signed <date>, Declined, Withdrawn, or Link expired. A line under the title says where it went and what has happened since: Emailed to jaco@example.co.za · opened 2× · link valid to 20 Sep, or Not sent to anyone yet.
Those rows carry the actions to match. Send on an envelope nobody has been told about yet; Resend once one has gone out (which also extends the link's expiry, and re-opens a declined one); Copy link to paste the signing URL into a chat or read it out; Signed PDF to open the signed artifact with its certificate page; and Withdraw to kill the link immediately, leaving the step on the journey.
A still-open requested upload also offers File it — the customer emailed it, WhatsApped it, or handed it over instead of using their link, and staff file it against the request. That completes the step exactly as if the customer had uploaded it themselves: it lands on the customer's Documents tab, and the step ticks off on their Getting Started page.
Click + Add to attach something new: Something for them to sign (see Sending a document for signature), Something for them to send us (see Requesting a document), or Something we already have — a PDF or photo filed straight onto the record with a title and a category, no step added for the customer. It appears in this list as Received, on the customer's Documents tab, and under Your documents on their Getting Started page. All three need the journey's customer to exist first — until then + Add is disabled and says so, rather than simply not being there.

Site & install tab

What exists so far — one honest checklist read from the database, not from the journey's own stamps: the site, its keyholders, a linked hub and the install job (and, for a panic-app journey, the Panic App hub, the account holder's app entitlement and the invitation). Every waiting row carries the button that does it — Pre-stage the site, Fill in for the customer (opens the keyholders step), Link a hub, Book the installation — so what is missing sits next to the thing that fixes it. Link a hub opens the site's Hardware tab with the Add hub wizard already open (CCU by serial, an alarm communicator through a receiver, CleverMail, Panic App — see Site details → Hardware); while the journey is active the site page carries a Back to onboarding journey #N button, so the round trip is two clicks and the Hub linked row is green on return.
The site — once the pending site exists, everything onboarding built for it: name, address (and whether it carries a real map pin), status, and the full call list — each keyholder's call order, name, phone, whether they've connected the app, and whether their safe words are on record — with Open the site page for everything else. While no site exists yet, this section explains what pre-staging will do and which way the Pre-create the pending site gate is set — the Pre-stage the site button itself lives once, on the Site row of What exists so far at the top of the tab, so there is never a second copy of it further down the page. Pre-staging is idempotent — running it on a journey that already has a site only adds any keyholders from the Keyholders & passwords answers that are not on the site yet.
Panic app cover — for a customer whose protection is the app: one button creates the site from the answers if it does not exist yet, adds a Panic App hub so the site qualifies for location panic, puts the journey's contact on it as the owner with Site + location panic, and sends the app invitation (WhatsApp / email, or a link). It warns if location panic is switched off for the control room. On an install or takeover journey this section is folded under Also available: panic app cover — click it to expand; on a panic-app journey or an info request it is shown in full.
The control room is told about the site. Every other desk already hears from a journey — the technical desk gets the alarm-account verdict, accounts gets the go-live billing ticket, the schedule board gets the install job. The desk that actually answers the alarm now does too: when a journey creates a site that isn't ready for an operator — nobody on the call list, no response word on record, or no map pin — one "New site on your board needs finishing" ticket is filed for the operational desk, naming each site and what it's missing. It closes itself the moment nothing is missing (re-apply, a later pre-stage, or someone filling it in on the site). A site that is complete from the start files nothing at all, and panic-app cover is excluded — its cover is the app, not a call list.
Answers changed since the site was created — appears only when the customer has since confirmed something the site doesn't have: a keyholder who isn't on the call list, a different response or duress word, a corrected address or pin, new access notes or pets. The site stays the source of truth — nothing is applied until you tick it and press Apply to the site. Add new keyholders is ticked by default (a missing name on the call list at 02:00 is the real risk); updating names/safe words, the address and pin, and access notes/pets are opt-in, because the site's version is usually the one that was corrected on the day. When a verified re-submission names a keyholder the site doesn't have, a ticket — "Answers changed after the site was created" — is filed for the control room and closes itself once you add them.

An Info request shows a shorter Site tab instead — just the site section (whose checklist button reads Create site & keyholders from answers, and a completed request with no site carries it as the primary next action) and panic app cover; no assessment, installation or go-live sections. See Request Customer Info → Turning the answers into a site.

Site assessment — the assessment job's booked/done dates once one exists, or a Book a site assessment action. The action does not need the journey to have a site yet: a survey normally happens before the site record exists, so a siteless journey books the visit against the address captured on the journey, and the note under the button says so. The site picks the job up later, once it's pre-staged.
Installation — the install job's booked/installed dates once one exists, or an explanation of what booking one will create and which way the Schedule the install visit gate is set. As with the site, the Book the installation button lives once, on the Install job row of What exists so far. (A panic-app journey has no install row up there, so it keeps the button in this section.)
Go-live evidence — two chips, Hub linked / No hub linked and First signal / No signal received, plus the list of blockers go-live would refuse on right now, if any. See Go-live needs evidence below.

Facts tab

The typed-once details captured from sales and confirmed by the customer (address, access notes, pets, language, and anything else gathered along the way) are editable here, saved with Save facts. Fields are grouped in a fixed order — Contact, Legal identity, The property, Alarm system, and Anything else for values the grouping doesn't know about — so the same account reads the same way whether its answers came from the wizard, the customer's own page, a staff capture or an import. The site address and the access notes get a full-width box rather than a quarter of a row, and phone and email fields are typed as such. Anything answered as a set rather than a single value (the keyholder draft, for instance) is listed read-only under Captured lists — it is worked on the Steps tab and applied to the site from Site & install — because flattening it into a text box would destroy its structure on save.

Edits survive leaving the tab: the Facts label carries a • while there are unsaved changes, and closing the journey with any unsaved facts (or unsaved internal details) asks before discarding them. Correcting something here corrects it downstream — the pending site, the technician's job sheet, and the service agreement all read from the same Facts. Each save is recorded on the journey's Activity with your name and the labels of the fields you changed — Facts edited: Contact phone, Site address — never their values, since ID and account numbers live here too. Facts that arrive some other way (the customer's answers when you verify their step, the alarm-account check, an amended wizard) are not repeated there; those actions have lines of their own.

Activity tab

A rail of every stage transition the journey has been through — From stage → To stage, how long it dwelt in the stage it left, when the move happened, and who or what caused it (automatically, by a staff member, or by the customer) — ending with "Now in (current stage)" for the open-ended final leg. Below the rail sits the same Activity & notes timeline used on leads, quotes, jobs and tickets — add a note yourself, or read the append-only audit trail of what the journey has done: besides its stage and status moves and the steps it ran, it records every message sent to the customer (acknowledgement, welcome, installation booking or a new installation time, go-live, first invoice, the day-7 and day-30 check-ins, reminders about outstanding steps), milestones (hub linked, first signal received, credit vetting done), each step a person verified, waived (with the reason) or reopened, every save on the Facts tab (Facts edited: and the fields that changed), and edits to the journey's title, internal notes or external reference. The quote whose acceptance opened the journey, and its deal, each get a line linking to it.

Every document out for signature on the Paperwork tab — the agreement, the mandate, an attached document — leaves its own lines too: sent to the signer (who pressed Send or Resend, and whether it went by email, SMS or WhatsApp — again on a resend, with they had declined it when a resend re-opens a declined one), opened by the signer, signed (with the name they signed as), declined (with their reason), withdrawn (by whom — including when ending the journey withdraws it), and each reminder the system sent. An agreement or mandate that is only prepared for the Getting Started page gets no sent line, because no message went out. A signing step that completes itself when the customer signs is shown by the signed line alone, not by a second, nameless Verified line. Signing history from before 14 September 2026 was filled in from what each envelope had recorded — when it was opened, signed, declined or withdrawn, and its latest reminder; earlier sends were not recorded.

Naming a journey

A journey used to be called whatever it happened to be linked to — the customer, or the lead, or a contact name typed at enquiry, or Journey #212. A landlord with four properties, or an estate rolling out block by block, produced a board of identical cards.

The Internal card in the journey workspace's context rail fixes that, and holds the two other things staff need to keep on a journey:

Name this journey — what the board calls it. 12 Oak Ave — cottage, Blue Hills phase 2. It wins over every derived name on the board, in Needs attention, in the drawer hero, and in search; the customer or lead it belongs to still shows as a smaller line under the name, so renaming never hides who it is actually for. Leave it blank and the old derived name comes back.
Reference — someone else's number for this work: an estate's job number, an insurer's claim reference. Searched on the board alongside the name, the customer, the journey id and the share code, and shown as a Ref chip in the drawer hero.
Notes — the one paragraph anyone picking this journey up needs. "Waiting on the body corporate AGM before the fence quote can go out."

All three are staff only. None of it appears on the customer's Getting Started page or in any message to them.

Changing a journey after it has started

Deals change. Someone who asked you to just collect information decides they want the panic app; a takeover turns out to need an install; a customer you never asked for a copy of an ID suddenly does need one. Change this journey, in the This journey card at the bottom of the context rail, reopens the wizard's last two questions against a journey that already exists — so none of that means closing one journey and starting another.

It asks the same two things the wizard's steps 2 and 3 ask, both starting on what the journey says today rather than on a default:

What happens at the end — the same five outcomes, with the journey's current one marked what it is now. Changing it changes what the journey finishes as: switch a Collect information journey to Panic app cover and the panic-cover rails take over — once the address and keyholder answers are verified, the site, Panic App hub and the account holder's entitlement are created, and the journey goes live when they connect the app. Everything already answered stays answered.
Ask the customer for — the control room's task pack, ticked to what this journey asks for now. Tick to add a step, untick to stop asking for one. Steps the journey carries that the new outcome can't ask for are named in amber and removed with the change.

Underneath, a This will panel spells out the consequences before you commit — including the one that isn't obvious: a step you untick that the customer has already answered is not deleted. The answer is evidence, so the step is marked waived, keeps everything typed into it, stays on the timeline, and any signing link still out for it stops working. Only a step that was never answered is removed outright.

The customer's link does not change. Added steps simply appear on the Getting Started page they already have — which is why Let the customer know is ticked by default when you add something: it sends the usual WhatsApp / SMS (falling back to email) pointing at that same link, because nobody reopens a page they finished. Untick it for a correction they never needed to see.

A finished journey can be changed too — an info request that completed is the commonest reason to open this at all — and doing so reopens it. A cancelled or lost journey has to be reopened first.

Three things put the outcome beyond changing, because the journey has already acted on it and the app can't un-act:

it has gone live;
billing has started from it;
its agreement is signed.

In each case the change is refused with the reason, and the advice is to start a new journey for the extra work — it can point at the same site. Sections stay editable in all three cases, because "send me one more document" is the normal follow-up to a live account. Every change writes a line to the journey's Activity saying exactly what moved.

Ending a journey

status used to be written only by automation, so a duplicate, an abandoned deal or a mis-typed enquiry stayed on the board forever — ageing, counted in every stall figure, with no way for a person to say it was over. The This journey card in the context rail is where a person says so.

Mark lost — the deal didn't happen. They went elsewhere, or changed their mind.
Cancel journey — this journey shouldn't be running: a duplicate, a test, the wrong kind, or work that was folded into another journey.

Both ask for a reason, keep it on the journey and on its activity trail, and then take the journey off the board. Ending a journey also withdraws every signing link still out with the customer — a cancelled deal whose contract link still signs is the expensive version of this mistake — and drops whatever the automation had queued for it. Nothing is deleted: the journey, its steps and its history stay readable.

Reopen puts a closed journey back on the board — closed by mistake, or the customer came back. Withdrawn signing links deliberately stay withdrawn; press Send on the Paperwork row to mint a fresh one.

Finding a closed journey

Closed journeys are not in the board's columns — those are a model of work in progress. The Closed journeys button above the board opens a strip of them, newest first, each with its reason on the card. The board's search narrows that strip too. Automated tickets and old links that name a journey by id still open it whatever its status.

Deleting a journey

Delete, on the same card, is for the journey that should never have existed. It erases the journey and everything that only exists inside it — its steps, its queued automation, its stage history, its Getting Started link and any unsigned document waiting on it — and cannot be undone. It asks you to type DELETE to confirm.

The customer, lead, quote, or any document already signed is not deleted. And delete is refused outright, in so many words, once the journey has caused anything real:

Refused because
A site was pre-staged for it
An installation job was booked against it
A site assessment was booked against it
A debit-order mandate is attached
The customer has signed something on it
It went live

Those checks run in the database, not in the browser, so there is no way round them from the app. When a journey is real but over, Cancel or Mark lost is the right answer — the record survives and can be reopened. Deleting also needs company-manage rights, a step above the sales permission that covers the rest of the journey workspace.

Starting onboarding from a lead

You don't have to leave the Leads board to start a journey. Any deal card that has moved past New (and isn't Lost) gets an onboarding chip. While the deal has no journey yet it reads Start onboarding — click it and CleverOps jumps to the Onboarding board with the Start onboarding wizard already open and that lead pre-selected. Once a journey exists (started by hand, or automatically when the deal's quote was accepted — see What happens automatically), the same chip reads Open onboarding and jumps straight to that journey's workspace instead, so there's never a way to mint a duplicate. The deal workspace mirrors this with its Start onboarding / Open onboarding journey button and an Onboarding — stage chip in its hero, and the quote editor shows the same journey as an Onboarding chip in its links — with a toast announcing the journey the moment an acceptance lands.

Bulk import

For anyone with permission to manage sales, an Import tab sits beside Board and Settings for bringing in a book of business from a migrated customer or site export — a Pastel or SEON CSV, or any CSV — and minting one onboarding journey per row. It's a three-step wizard:

Choose a CSV file — upload the export.
Map columns & pick the kind — columns are auto-mapped from common headers (Account/reference, Name, Company, Contact person, Phone, Email, Address, City/suburb, Current provider, Notes). Remap any column by hand, toggle whether the first row is a header, and choose the journey kind (default Takeover) and a default segment (Residential, Business, or Estate — a per-row Segment column can override it for that row). Name is the only required column; a Download a blank template button is there if you'd rather start from a clean sheet.
Review & import — a preview classifies every row as Ready, an in-file Duplicate (a repeated reference or phone within the same file), or Invalid (no name). Nothing is created until you confirm.

Confirming turns each Ready row into a journey through the normal creation flow, so every one gets its own Getting Started link and the company's task pack. The import is idempotent: a row is skipped automatically if an active journey already exists for the same account/reference, or failing that the same phone number — so re-importing the same export, or a refreshed one, is safe and won't create duplicates. The result summary shows how many rows were created, skipped, and failed, and large files import in batches automatically.

Bulk import only creates journeys — it doesn't import customers, sites, billing, or contacts directly. Those are minted as each journey progresses, exactly as they are for any journey (see What happens automatically).

Where a SEON export comes from

A control room moving off SEON doesn't have to produce that CSV by hand. CleverCam runs a migration tool against your SEON tenant — with your SEON agent login it pulls every customer, property, zone description, keyholder and operator instruction, and writes a file shaped for this Import tab. Ask your CleverCam contact to run it.

What the Import tab takes from that pull is one journey per property. The parts a journey can't carry — zone descriptions, the keyholder call list and the key/tech/responder instructions — are loaded separately by the same tool, straight onto the sites once they exist. Two things deliberately don't come across: SMS and WhatsApp opt-ins (that consent was given to your previous provider, so it has to be collected again), and keyholder passwords, which land in each keyholder's notes for an operator to see rather than in the app's password field.

Several properties, one panel. SEON sometimes models each partition of one alarm panel as its own property — the cottages on a farm, a house and its flat. CleverCam links a panel to one site, so the tool folds those properties into a single site with Partitions as separate premises switched on: each former property becomes a premises on that site with its own name, map pin and directions, its keyholders are scoped to their premises (people who were on every property become whole-site keyholders), and the old sibling sites are archived. See Alarm zones → Partitions as separate premises for what the control room sees afterwards.

Settings tab

Settings are per company (VCR). A company that hasn't configured Onboarding yet sees a single card: "Onboarding isn't configured for this company yet" with a Seed the defaults button. Seeding installs the default task pack (confirm details, keyholders, sign, debit order, ID/company docs, app) and a starting profile per journey kind, and everything stays editable here afterwards. Once seeded (or for a company already configured), the tab shows five groups. A sixth sub-tab, Contracts, holds the company's own agreement PDFs — see Contract templates.

Customer messages

Send journey messages to customers — the master switch for every customer-facing journey message (welcome, booking, go-live). It ships off, and CleverOps keeps it off until the customer portal's Getting Started page has been deployed — switching it on before then would just send links that dead-end. While it's off, an amber banner sits at the top of the Onboarding page stating plainly that customers are being sent nothing, because in that state the Getting Started link never reaches them on its own — you have to send it yourself with Copy link from the journey workspace. Journey messages are also automatic messages, so the control room's Automatic messaging switch (Settings → Messaging) holds every one of them while it is off, even with this switch on.
Auto-acknowledge new enquiries — when a new-relationship lead comes in (Takeover, Alarm link, New install, CCTV + CCU, or Panic only — Add-on, Reconnect and Relocation journeys skip this, since there's already a relationship), reply automatically over WhatsApp, falling back to SMS, within about a minute.
Ack copy — business hours and Ack copy — after hours — the two message templates, each editable with placeholders for the customer's {name}, your {company}, and the promised call-back time in {mins}. CleverOps fills these in automatically when the message sends; leave a field blank to fall back to the shipped default copy.

Clocks & money

First-touch SLA (minutes) — how long before a new enquiry should get its first human contact. A lead still sitting in New past this target, checked during business hours (07:00–17:00, Mon–Fri), raises a one-time "Lead waiting — nobody has made contact" ticket — grab it on the Leads board.
Quote SLA (hours) — how long a quote should take to go out once a journey is in progress.
Stalled after (days) — how long without movement before a journey counts as stalled.
Debit-order mandate mode — Signed mandate (e-sign) (the customer e-signs a generated mandate PDF right on the Getting Started page), Netcash DebiCheck (their own bank confirms the mandate with them directly instead — see DebiCheck instead of signing below), or Off. DebiCheck needs the company's Netcash DebiCheck template configured first; a journey started with DebiCheck selected but nothing configured falls back to Signed mandate automatically, so onboarding always has a working mandate path.
First invoice — Charge the partial start month in full, Pro-rata the partial start month, or Partial start month free. A subscription's first invoice covers the time from its start date to its first full period — whole months at full price, and the partial start month as chosen here. It matters when the control room invoices the whole book on one billing day (Billing → Config → Billing run): a subscription started on the 13th is first billed on the billing day, so the 13th to month-end is the partial month. With anniversary billing there is no partial month and the setting does nothing.

Gates

One entry per handoff the journey can either carry out on its own or stop and wait for a person. All nine gates are live and show an Automatic / Staff approve dropdown, each with a one-line explanation underneath of what the two choices do.

Gate	What it guards
Open onboarding on quote accept	Moving a journey from the sales stages onto the Onboarding column (and minting the prospect customer) when its quote is accepted.
Verify customer inputs	Marking a customer's submitted task as verified.
Credit vetting (business)	Credit checks on business-segment journeys, before scheduling proceeds.
Activate mandate	Turning on the debit-order mandate once the customer signs it.
Schedule the install visit	Creating the install job once blocking tasks are done.
Pre-create the pending site	Creating the pending site once blocking tasks are done.
Go live on install sign-off	Taking the journey live once the install job is signed off.
Start billing at go-live	Starting the accepted quote's subscriptions.
Apply add-on amendments	Applying an Add-on journey's signed amendment to its subscriptions.

Every gate ships Automatic except two, which seed to Staff approve: Schedule the install visit (book the first install visits yourself and flip it once you trust the auto-created jobs) and Verify customer inputs. As the settings tab puts it: autonomy is a dial, not a fork — approve everything on day one and relax individual gates as trust grows, rather than an all-or-nothing switch.

Why Verify customer inputs defaults to Staff approve

On Automatic a submission is marked verified within a minute of arriving, with nobody's name recorded against it — the status says "checked" but nothing read it. That covers the answers your control room depends on at 2am: keyholder order, response and duress words, and gate access notes. On Staff approve the step stays Needs checking until a person presses Verify, and their name is stored against it.

Banking and signature steps are unaffected by this gate either way — a debit order completes only when the bank confirms it (DebiCheck) or the customer signs the mandate, and it has never been auto-verified.

What "Staff approve" does on each gate:

Open onboarding on quote accept — the accepted quote still stamps the journey's acceptance, but the journey holds instead of moving onto the board. An automatic ticket ("Onboarding awaiting approval") tells the office, the card appears in the Onboarding column with an amber Accepted — approve to open chip, and the journey workspace gets an Open onboarding button. Pressing it is the approval: the journey moves onto the board, the prospect customer is minted, and everything proceeds exactly as the Automatic path would have.
Verify customer inputs — each customer submission files an "Onboarding input needs review" ticket and waits for you to Verify (or Waive) it in the journey workspace, instead of verifying instantly.
Credit vetting (business) — business-segment journeys only. Once the journey's blocking tasks finish, scheduling stays locked: a "Credit vetting needed before scheduling" ticket is filed and the journey carries a Vetting chip on its board card. Vet the account, then press Mark vetting passed in the journey workspace to release scheduling — the install job and schedule ticket follow exactly as the Automatic path would have produced them. Automatic skips the hold — there's nothing to vet.
Activate mandate — Automatic turns the debit-order mandate on the moment the customer signs it (see Signing the debit-order mandate below). Staff approve leaves it signed but inactive and files a "Mandate signed — activation needed" ticket for someone to activate it. This gate is specific to the Signed mandate (e-sign) path — DebiCheck mandates activate separately once the bank authenticates them, outside this gate (see DebiCheck instead of signing below).
Schedule the install visit — Automatic creates the install job (from the kind's job template, checklist included) the moment blocking tasks finish, and it waits in the schedule board's Unscheduled column, ready to book. Staff approve — the default here — leaves creating the job to a person. Either way, once blocking tasks finish an "Onboarding ready to schedule" ticket tells the office — naming the install job if Automatic already created it, or asking someone to book the visit from the Onboarding board if it didn't.
Pre-create the pending site — CleverOps leaves creating the pending site to a person instead of staging it the moment blocking tasks finish.
Go live on install sign-off — completing the install job stamps the installation but holds the journey short of Live. A "Go-live awaiting approval" ticket is filed, the card shows an amber Installed — approve go-live chip, and the drawer gets an Approve go-live button — pressing it activates the customer, sends the go-live message (comms permitting), and settles the journey into First 30 days. Note this gate holds the journey's go-live bookkeeping; the site itself still leaves installation mode when the install job completes, exactly as it does for manually created sites. Whichever mode this gate is on, going live is also refused outright until the go-live evidence below checks out.
Start billing at go-live — Automatic starts the accepted quote's subscriptions the moment the journey goes live. Staff approve files a "Go-live — start billing" ticket instead, for someone to start them from the quote on the customer's page.
Apply add-on amendments — Add-on journeys sign an amendment rather than a fresh quote. Automatic applies its subscription changes (added, changed, or cancelled lines) the moment the sign step completes. Staff approve files an "Amendment signed — apply the changes" ticket instead. Either way, anything left unapplied still applies when go-live billing starts.

Click Save settings to store changes to Customer messages, Clocks & money, and Gates together.

Go-live needs evidence

Going live used to have one condition: the install job's status flipping to completed. Nothing checked that a hub was ever linked or that a single signal was ever received, so a site with no hardware at all could be taken live — and billed — by a technician tapping Complete on the wrong job.

Go-live now checks for two facts before it will do anything irreversible:

A hub is linked — stamped the moment a hub is linked to the site, however it gets there: the site's Hardware → Add hub, the journey's Link a hub, or the technician's commissioning screen.
A signal has been received — stamped on the first event the site raises after the journey began: the hub or communicator has actually reported in.

A Blocks go-live task left outstanding counts too — this is the setting whose words are now enforced literally: it used to only hold up the move into Prepare (i.e. scheduling), with nothing checking it again at go-live itself. Now it blocks go-live itself, matching what the label has always said.

If any of these are missing when go-live is attempted — whichever way the Go live on install sign-off gate is set — CleverOps refuses to do any of the go-live work: no activation, no billing, no go-live message. Instead it files a "Go-live refused — evidence missing" ticket listing exactly which conditions aren't met, and the journey's workspace (Site & install tab) shows the same reasons live, along with Hub linked / No hub linked and First signal / No signal received chips. Fix whatever's missing on the site, then re-run go-live from the board — commissioning re-checks automatically once the missing evidence lands, so a hub reporting in after the fact clears the block without anyone re-triggering anything by hand.

Task pack

Below the gates, the task pack table lists every customer-facing task your company can offer, with the defaults from seeding:

Task	Blocking (default)
Who the account is for	Blocks go-live — the name and ID or company registration the agreement and invoices are issued in. For a business it also asks who signs for the company and in what capacity (Director, Member, Trustee, Authorised representative), plus that person's ID number and email. The company holds the account; a person binds it — so the signature request is sent to the signatory rather than the billing contact, and `{{signatory.name}}` / `{{signatory.capacity}}` can be printed on your contract template. An individual account is unchanged: they are their own signatory.
Confirm your details	Blocks install
Your people — keyholders & passwords	Blocks install
Your alarm system	Due after live — panel make and model, how it communicates (radio / GSM / internet / app), the account or transmitter code, who monitors it today and whether notice was given, where the panel is. Pre-ticked by the wizard for Link an existing alarm. When this step is verified, CleverOps looks the account code up against your receivers and writes the verdict on the journey's Site tab (Alarm account): bound to this site, signals to another site (with a Use this site for the journey button so you attach the journey to the existing site instead of pre-staging a duplicate), reaching us, not bound (bind the pending identity at pre-stage), or not seen yet — and files one technical ticket worded for that verdict. Check again re-runs it once the radio has been re-pointed.
Sign your service agreement	Blocks go-live (all kinds except Add-on) — prepared by hand from the Paperwork tab, or automatically from a contract template
Sign your amendment	Blocks go-live (Add-on journeys only)
Set up your debit order	Due after live
Upload your ID	Off
Company registration & VAT	Off (Business segment)
Get the app	Due after live

Each row has two controls, both of which save immediately — there's no separate save step for this table:

Blocking — Blocks install, Blocks go-live, Due after live, or Off. Off tasks aren't offered on new journeys at all, which is why Upload your ID and Company registration & VAT need switching to another option here before customers ever see them.
Active — a plain on/off toggle for whether the task is currently offered.

Journey kinds

Below the task pack, the Journey kinds table carries the per-kind defaults — one row per journey kind (and per segment, where a kind has been split). Seeding creates one row per kind with no segment, meaning any segment. Like the task pack, every control saves immediately — there's no separate save step for this table.

Column	What it does
Install template	Which job template the install visit is created from — this is what gives the technician a checklist. A kind with no template picked raises its install job with no checklist at all.
Assessment template	The same, for the site-assessment visit. Disabled when Assessment is set to No assessment.
Assessment	No assessment, Optional, Required, or Merged into the install — whether this kind of job gets a site survey before the install, and whether it's a separate visit or folded into the install.
Paperwork	New contract, Amend the existing contract, or No paperwork — what the customer signs. Add-on journeys seed to amendment; Relocation seeds to none.
Target days	The delivery promise this kind is measured against, driving the pace chip on every card. Leave it blank for a kind you don't want paced.
On	Whether the kind is offered on new journeys. Turning it off leaves journeys already running on it untouched.

The two template pickers read your company's job templates. Enabling the onboarding module now seeds the full template library — the ten field-tested presets, checklists included — into your own editable templates, and wires sensible per-kind defaults where you haven't picked one: New install → Alarm system installation, CCTV + CCU → CCTV installation with CCU, Takeover and Alarm link → System takeover / re-link, and the assessment picker → Site assessment for every kind that takes a survey. Change any of them here; a default never overwrites a choice you've made.

What happens automatically

Once a journey is running, several handoffs advance it without anyone clicking anything — most subject to a gate, a couple unconditional:

Site assessment booked (where one is needed) → the journey moves to Assessment. Booking a survey — via Book a site assessment on the journey's Site & install tab — creates its own assessment job kind, separate from the install job, and moves the journey into the Assessment column. Completing that survey moves the journey on to Proposal without ever touching go-live or billing, because an assessment job and an install job are now different things entirely.
Quote accepted → onboarding opens. Accepting the linked quote moves the journey onto the Onboarding column and mints a prospect customer from the journey's facts (name, contact details) — the source lead is linked to that new customer. The lead itself is marked Won and moved to the archive the moment the quote is accepted, with or without the Onboarding module; the journey carries on regardless. With the Open onboarding on quote accept gate on Staff approve, the journey holds here until someone presses Open onboarding in the drawer.
Blocking tasks done → the site pre-stages itself. Once every task that blocks install is verified or waived, CleverOps creates the pending site — on the same installation hold a manually created site gets (your control room's hold length, 2 hours unless you change it), with the map pin from Your details if the customer set one — and the keyholders the customer listed in Your people become that site's call list as non-app keyholders, each carrying the household's shared response and duress word. An automatic ticket tells your office it's "ready to schedule." With the Pre-create the pending site gate on Staff approve, the ticket still files but the site is left for a person to create.
Install signed off → live, if the evidence is there. Completing the install job takes the site — and the journey — live: the prospect customer becomes active, and the journey settles into First 30 days. With the Go live on install sign-off gate on Staff approve, the journey holds short of Live until someone presses Approve go-live in the drawer. Either way, go-live itself is refused if the evidence isn't there yet — a hub linked and a signal received. An install job that was already signed off when the journey picked it up (the visit happened before the site was pre-staged) counts the same way — the journey makes the go-live move the moment it adopts the job. One install job belongs to one journey: a second journey on the same site never picks up a job another journey already holds. Cancelling the install job releases it — the journey drops back to Prepare reading "No visit booked yet — create the install job", ready for a replacement.
Lead lost or dropped → the journey closes with it. This one isn't gated — it always happens. Dragging the source lead to Lost, or archiving a lead that isn't won, closes its journey too, marked Lost with the lead's own reason carried over (or Cancelled for an archive), so a dead deal stops raising tickets and nudging a customer who was never won. A won lead in the archive keeps its journey: won deals move to the archive by themselves, and the journey is the delivery of that win.

On install day, the technician commissions the site right from the job in the CleverTech app: link the panel's communicator or hub to the site, trigger it and watch the control room receive the first signal live, then mint and WhatsApp each keyholder's 4-digit app invite code on the spot. If the site has a linked CleverCam CCU, the same screen also shows a CAMERAS section the technician can tap through to set up that hub's cameras in the company's CleverAlert app — it needs that app installed on the technician's device, and it isn't offered for panel communicators. Completing that job is what ends the site's installation mode — the moment the Go live on install sign-off gate is watching for.

Customer-facing messages (welcome, booking, go-live) only ever send while Send journey messages to customers is switched on; with it off, every step above still runs, just silently.

The same goes while the control room's Automatic messaging switch is off under Settings → Messaging: every step still runs, and the messages are held. A held message is not treated as sent. The journey's activity trail does not record it as sent. The customer's first invoice, which the journey would otherwise send and mark as sent, stays unsent for the office to send the ordinary way. The held attempt shows in the Outbox as Automatic messaging off. Held messages are not sent later when the switch goes back on.

Care cadence after go-live

Going live doesn't end the journey — an hourly check drives a light touch through the First 30 days column, all timed from the moment the journey went live:

Day 2 — an "Onboarding QA call — day 2" ticket asks your office to call the customer: anything unclear, panic button tested, app notifications on?
Day 7 — the customer gets an automatic check-in message, if Send journey messages to customers and the control room's Automatic messaging are both on.
Day 30 — the journey's active life completes regardless of comms — that bookkeeping step always happens, even with messaging off or no reachable contact. Comms permitting, the customer also gets a month-in-review message carrying the Refer a friend ask (see Referrals below) — and because that ask is a marketing solicitation rather than a service update, it only sends to a customer who has given marketing consent; without it, the send is skipped rather than forced through as if it were transactional.

Separately, a journey sitting in any stage short of go-live — Enquiry, Contact, Assessment, Proposal, Onboarding, Prepare or Install — for longer than Stalled after (see Clocks & money) raises an "Onboarding journey stalled" ticket, worded for the stage it's stuck in (chase the decision on an undecided quote; agree a date on a finished-tasks journey that isn't booked yet; and so on), so a deal that's gone quiet mid-way doesn't die silently. Before that ticket fires, CleverOps tries the cheaper fix first: while the hold is genuinely on the customer (not on staff) and comms are on, it sends up to two automated nudges pointing back at their Getting Started page, naming how many steps are still outstanding. Only once those nudges are spent, comms are off, Automatic messaging is off (the ticket says so, and asks you to call), the customer can't be reached, or the next move is staff's to begin with does the stall become a ticket for a person to act on. The stall clock is measured from when the journey entered its current stage, so a routine background write can't reset it; moving the journey on genuinely does. It's the same clock that colours the age chip on the board card.

Referrals

Once the journey is live, the Getting Started page also carries a Refer a friend card with the customer's own referral link, alongside Share on WhatsApp and Copy link buttons. Opening it takes the referred person to a public, company-branded /refer/ page — no account needed — where they leave their name and mobile number (email and suburb are optional). Submitting drops a new deal onto your Leads pipeline, sourced referral and noted with who referred them. It only creates and attributes that lead — nothing is billed, credited, or converted automatically. The same phone number won't create a duplicate within 30 days, and an invalid link shows a friendly Link not found message rather than an error.

The same referral link is also the payload of the day-30 message above — see Care cadence after go-live for the consent rule that gates that particular send.

The customer's Getting Started link

The customer only ever gets one link, sent to them once and reused for the whole journey — opening it lands on the branded Getting Started page on the customer portal. It shows their progress across four steps — Quote → Your details → Installation → Live — and the tasks from your task pack that apply to them: confirming their details, adding keyholders and a household response/duress word, signing their agreement, entering their banking details for the debit order, and getting the app.

One link, forever, literally. Once the journey goes live, the same URL stops rendering the setup page and instead renders the customer's real account view — the same invoices / statement / pay / jobs tabs described in Customer Account Link — with everything about the setup itself (the four-step progress rail and any documents signed or sent along the way) folded into a collapsed Setup record accordion at the top. There's no second link and no separate account-link email to send afterwards; the link the customer was given on day one is the same one that works for as long as they're a customer.

Told, not left guessing. Before go-live, the page keeps the customer oriented:

A "Your installation visit" card shows their booked date once one exists, and a fresh message goes out whenever it's booked or moved — sourced from the job's actual scheduled time, not the day it was booked, and never phrased as an ETA.
A "We're coming to look at your site" card does the same for a site assessment, where the journey's kind needs one first.
Whenever the ball is genuinely in your court and the customer has nothing left to do, a "What happens next" card explains what's happening on your side in plain, absolute terms — never a promised turnaround time.
If a customer stalls partway through, they get up to two automated nudge messages before staff are asked to call (see Care cadence after go-live).

Forms don't lose work. Every field is mirrored to the browser's local storage as the customer types, so a dropped call, a low-battery phone, or an accidental refresh doesn't cost them their answers. A submitted-but-not-yet-verified step stays editable — the customer can correct a typo without phoning in, right up until staff verify it; once verified (or waived), it's locked.

Everything they signed or sent, on the same page. A Your documents card lists what the customer has signed or uploaded on this journey — the service agreement, the debit-order mandate, any ad-hoc document staff attached or requested — each with a link back to the signed copy where one exists, or an On file badge for something uploaded to a private store.

Who the account is for

The first step on the page, Who the account is for, is the one that decides whose name the service agreement and every invoice carry. The customer picks Myself / a person or A business and answers one question either way:

A person gives their full name as it appears on their ID, and their 13-digit SA ID number. A non-citizen's passport number is accepted in the same field, and the page says so.
A business gives its registered company name and its CIPC registration number, plus a VAT number if it has one. A number typed as bare digits is reformatted to YYYY/NNNNNN/NN when they leave the field, and the page confirms what it recognised — "Private company — (Pty) Ltd", "Close corporation — CC".

Both checks are advisory. A number that doesn't match the South African shape gets a note suggesting a second look, and then saves exactly as typed — a trust, an estate, a foreign passport, or a genuinely unusual registration must never be a dead end at 9pm on a Sunday. Blocks go-live by default (changeable in the task pack), which means it never delays an installation: the hardware protects the property whether or not the paperwork has caught up.

The step appears after the quote is accepted, alongside the signature and debit-order steps. A prospect deciding whether to buy is never asked for an ID number.

The customer is never told whether you already have them. The number they give is matched against your customer list after it arrives, and the result goes only to your team — as the Legal identity card in the journey workspace and, where an exact match turns up, as a "Same legal entity already has an account" ticket. The page itself says nothing more than "saved", because a page that told a stranger "you already have an account with us" would let anyone test any ID number in the country against your customer list.

Answers flow onto the customer record automatically — legal name, entity type, ID or registration number, VAT number — so the invoice and agreement are made out correctly without anyone retyping them. Staff can also fill this step in on the customer's behalf from the Steps tab, which records it as a staff capture and ticks the step off on the customer's page.

On Your details, the address field offers a Google-Places-style search — pick a suggestion and it fills in the street address, complex/suburb, region and country and drops a map pin automatically, confirmed with a Location pinned note, so the pending site CleverOps stages for the customer carries a real location pin rather than just typed text. The customer can still type the address by hand instead.

Under those fields the customer is offered a map: "Show me a map — I'll pin the exact spot" (or "Check or move your pin on a map" once an address search has placed one). It opens satellite imagery with its own search box, and they tap the map or drag the pin onto their own gate. Nobody knows the right spot better than the person who lives there, and this is the step where they can say so — a plot with no street number, a complex with several entrances, a farm gate a few hundred metres off the road. It's optional; the address search alone still sets a pin.

The map only loads once they press that button — the page itself never loads one — so a customer who opens the link and reads it costs nothing in map usage.

When you fill this step in for them from the Steps tab, the same form carries the same map, shown open under the address search rather than behind a button. On both versions the map's own search moves the pin only; the address fields come from the address search above it. Whatever the pin ends on is the coordinate the pending site is created with, which is what a responder later navigates to and what decides the site's suburb.

Needs a map key

The customer-facing map appears only where the portal has been given a Mapbox token (VITE_MAPBOX_TOKEN). Without it the button isn't offered at all and the step behaves exactly as it did before — address search, typed fields, and the pin that search produces.

On Your people, a household response word (all-is-well) and duress word (secretly-in-trouble) are captured once at the top of the step, rather than under the first keyholder. Each keyholder below is then just a name, phone number and optional notes, listed in call order.

Signing the debit-order mandate

When Debit-order mandate mode (see Clocks & money) is Signed mandate (e-sign), entering banking details on Set up your debit order does more than save the numbers: CleverOps generates a debit-order mandate PDF there and then, and a Sign your mandate now step appears right on the Getting Started page — the same OTP-verified e-sign flow used for other documents, with no extra login or app needed. The moment the customer signs, CleverOps creates the debit-order mandate record automatically, subject to the Activate mandate gate. The drawn signature lands on the mandate's own signature line as well as on the certificate page.

When the company's agreement comes from a contract template and that agreement is still to be prepared, the mandate waits to join it: the two go out as one document, and the customer signs once — the step reads "your debit-order mandate and your service agreement are one document now — read it and sign once". Signing completes both steps. A company that has also uploaded a mandate template gets the banking details stamped into its own mandate PDF instead of the generated one.

DebiCheck instead of signing

When Debit-order mandate mode is Netcash DebiCheck, Set up your debit order drops the signing step. The Getting Started page also asks for the account holder's 13-digit SA ID number — DebiCheck uses it to match the request to them at their own bank — and there's no Sign your mandate now step to follow. Once the customer saves their details, the task shows a short message instead: their bank will confirm this debit order with them directly (DebiCheck), with nothing more to sign here.

Behind the scenes, saving those details captures a debit-order mandate for the customer, inactive for now, and files a ticket, "DebiCheck mandate ready to submit," asking your team to submit it for DebiCheck from the customer's Billing tab. The debtor then approves the request at their own bank, and the authenticated (or rejected) result arrives automatically a couple of days later — CleverOps never submits the request on its own.

DebiCheck mode only works once the company has configured its Netcash DebiCheck template (and Netcash keys). A VCR set to DebiCheck without one configured falls back to the Signed mandate (e-sign) flow automatically, so onboarding always has a working mandate path either way.

Preparing the service agreement

On the journey workspace's Paperwork tab, the service agreement row shows Not prepared until the journey has an accepted quote and someone clicks Prepare. Pressing it builds the agreement from the accepted quote — the schedule of services is the quote's subscription lines and pricing, since no live subscriptions exist yet at this point in the journey — wrapped in the company's own contract terms (Billing → Config → Documents → Service agreement), the same polished document as the customer's Billing-tab service agreement. While the step has nothing behind it the journey reads Waiting on us — Agreement not prepared — nothing for the customer to sign yet — on the board, in Needs attention and in the workspace's next-action strip, whose button prepares it from wherever you are; a journey with neither an accepted quote nor a contract template is pointed at Onboarding → Contracts instead.

The prepared agreement becomes the customer's Sign your service agreement step on their Getting Started page (the /j/ Hub), signed there through the same OTP-verified e-sign flow used for the debit-order mandate, and the step ticks itself off the moment they sign. Preparing it does not email or text anything by itself — press Send on its Paperwork row to put the signing link in front of the customer, exactly as for any other signable document.

With a contract template (Onboarding → Contracts — see Contract templates) the agreement is the company's own PDF, prepared automatically and already filled in from the journey's verified answers: it is built the moment the customer has been created and every form step the agreement binds (Who the account is for, Confirm your details, Your people) is verified, waived or staff-captured — and, when the journey has a debit order signed electronically, once the banking details are in, because the mandate then goes into the same document for one signature. Until then the customer's page says "We'll prepare your agreement once your details are checked" and names what is still to come. The customer's drawn signature is placed into the template's signature boxes (and the signing date into its date boxes) as well as on the certificate page.

Sending a document for signature

Works on every kind of journey — takeover, alarm link, new install, CCTV, panic only, add-on, reconnect, relocation and info request alike. It is how a contract or a debit-order mandate gets in front of a customer, and it does the whole job: prepare the document, choose who signs, and send them the link.

From the journey workspace's Paperwork tab, click + Add → Something for them to sign.

1. The document. Either a Standard document — the company's shared library, the same one the customer's Documents tab sends from, which is where the monitoring contract and the debit-order mandate template live — or Upload a PDF for a one-off. A one-off upload can be ticked Save it as a standard document, which adds it to the library so the next journey picks it from the list instead of hunting for the file again. A company with an empty library opens straight on the upload option.

2. What the customer sees it called. Pre-filled from whichever document was picked, and editable — this is the title on the signing page and in the email or text.

3. Send it. By email, By SMS / WhatsApp (only offered where the company has turned on SMS signing under Billing → Config → Documents), or Don't send yet. The signer and their address or number are pre-filled from the journey's contact details and the customer's contacts — tap a contact chip on the On file row to use them, or type someone else. The one-time code goes to the same address or number as the link; that pairing is what makes the signature evidence of who signed, which is why the channel is a deliberate choice rather than something inferred from whatever details happen to be on the journey.

4. When it must be signed. Sign anytime, or Before go-live — the latter is a blocking step.

Whichever channel is chosen, the document also appears as a sign step on the customer's Getting Started page (the /j/ Hub), signed there through the same OTP-verified e-sign flow used for the debit-order mandate. Don't send yet means exactly that: no message goes out, the document waits on the Hub page, and the Paperwork row keeps a Send button for when you are ready. A journey can carry as many signable documents as it needs; each is signed independently and ticks itself off the journey's task list the moment the customer signs it, and the signed PDF — original plus a certificate page carrying the signer, the OTP-verified marker, timestamps and the document's checksum — comes back on the row as Signed PDF and on the customer's Documents tab.

If the send itself fails — a rejected address, or the control room's messaging switched off under Settings → Messaging — the document is still added to the journey and the dialog says so, so the fix is one Send on the row rather than starting over.

Nothing is chased before it is sent

An unsent document is genuinely unsent: it is not counted as delivered, and the automatic signature reminders will not chase a customer about a document whose first message never went out.

Requesting a document

From the same Paperwork tab, click + Add and choose Something for them to send us to ask for a document back from the customer instead of sending one to sign: type what you need — proof of residence, a copy of an ID, company registration, or anything else — choose what to file it as (ID document, proof of residence, signed contract, or other) so it lands on the right shelf of the customer's Documents tab rather than as Other for someone to re-sort, choose when it's needed (Anytime or Before go-live), then click Request it. Like the sign option, it needs the journey's customer to exist first.

The request adds an upload step to the customer's Getting Started page (the /j/ Hub). The customer picks a photo or PDF there, up to 15 MB, and uploads it. The file is stored privately and appears on that customer's Documents tab; the task then moves to Submitted on the journey, same as any other task — waiting on your usual review, not signed and not verified on its own. A request added as Before go-live is a blocking step; Anytime doesn't block.

Funnel analytics​

Sign-up link — the customer starts their own journey​

Needs attention​

Board tab​

Finding a journey​

Start onboarding (the wizard)​

Which account the journey belongs to​

Journey cards​

The journey workspace​

Steps tab​

Paperwork tab​

Site & install tab​

Facts tab​

Activity tab​

Naming a journey​

Changing a journey after it has started​

Ending a journey​

Finding a closed journey​

Deleting a journey​

Starting onboarding from a lead​

Bulk import​

Where a SEON export comes from​

Settings tab​

Customer messages​

Clocks & money​

Gates​

Go-live needs evidence​

Task pack​

Journey kinds​

What happens automatically​

Care cadence after go-live​

Referrals​

The customer's Getting Started link​

Who the account is for​

Signing the debit-order mandate​

DebiCheck instead of signing​

Preparing the service agreement​

Sending a document for signature​

Requesting a document​