Skip to main content

Contract templates

Onboarding → Contracts lets a control room use its own agreement for the onboarding journey's Sign your service agreement step. You give it the agreement in one of two ways — upload a PDF and place boxes on its pages, or write it in markdown (starting, if you like, from the standard agreement every control room has) and let CleverOps lay it out — and say which step uses it. From then on each journey's agreement is prepared automatically, already filled in from what the customer typed on their Getting Started page — company name, ID or registration number, address, keyholders, response word, plan and price — and, when the journey includes a debit order signed electronically, the mandate is put behind the agreement in the same document, so the customer draws one signature for both.

A control room that sets up neither keeps today's behaviour exactly: the clause-based agreement CleverOps composes from Billing → Config → Documents → Service agreement, prepared by hand from the journey's Paperwork tab, and the generated debit-order mandate.

Two ways to the same thing

An uploaded PDF and a markdown agreement end up identical to the rest of onboarding — a document with boxes on it. Everything after this page (preparing, one-signature bundling, signing) works the same whichever way you made it. Uploading suits an agreement your attorney already drafted on a letterhead; writing in markdown suits starting from our standard wording and editing it, with the boxes taken care of for you.

Who can use it

The Contracts sub-tab appears for users who can manage the company (the same audience as Onboarding → Settings). It needs the Onboarding module and a seeded task pack.

Upload a PDF​

  1. Open Onboarding → Contracts.
  2. Pick what kind of document it is — Service agreement, Amendment, Debit-order mandate or Other — then Upload a PDF (or drop the file on the dotted area).
  3. The PDF is stored privately, its pages are counted, and the box editor opens straight away.

The template list shows each template's kind, its page and box counts, whether it is Active or a Draft, whether it was uploaded or written in markdown, and which step it is Used for. Edit boxes (or Edit text and Boxes for a markdown template), Activate / Deactivate and Rename sit on each row. Delete template is not on the row: it is in the Danger zone at the foot of the right-hand panel in the box editor (uploaded PDFs) or the text editor (markdown templates). Deleting a template never touches agreements already prepared from it — every prepared agreement is its own snapshot — and a step that used it goes back to the default.

Place the boxes​

The editor shows every page of the PDF with the boxes drawn over it. Boxes are positioned as a fraction of the page, so they stay where you put them whatever the page size.

Adding a box. Click a page to make it the active page, then press one of the Add to page buttons — or double-click anywhere on a page to drop a text box right there.

  • Text — one line, shrunk to fit the box if the value is long; Multi-line text wraps inside the box (use it for the keyholder list or the plan lines). Both take a value from the journey (below), a font size, and — for a single line — left / centre / right alignment.
  • Tick box — ticked when a rule is true: the account is a business, the account is a person, the bank account is cheque / savings / transmission, or always.
  • Signature, Initials, Date (when signed) and Signer's name are signer boxes: they are left empty when the agreement is prepared and filled in at signing time — the drawn signature is placed into every Signature box (and, fitted small, into every Initials box), the signing date into Date boxes, and the name the customer types into Signer's-name boxes. The signature certificate page is still appended at the end.

Moving and sizing. Drag a box to move it; drag the small square at its bottom-right corner to resize it. A selected box can also be nudged with the arrow keys (hold Shift for bigger steps) and removed with Delete. The inspector on the right shows the exact Left / Top / Width / Height as percentages, the page the box is on, and Duplicate / Remove.

Values from the journey. A bound box prints one of these when the agreement is prepared:

GroupValues
Customerlegal name, company name, account name, entity type, ID number, company registration number, VAT number, account number
Signatorywho signs for the company, the capacity they sign in, their ID number and email — captured on the identity step for a business account, and used as the signer the signature request is sent to
Contactcontact name, phone, email, and the phone again as digits only for character-cell boxes
Sitesite name, the address as one line or as separate lines (line 1, line 2, city, province, country), the map pin, access notes, pets, preferred language
Keyholdersa numbered list (multi-line), the names comma-separated, the count, and keyholder 1–6's name and phone individually
Response wordsthe response word, the duress word — tick Print as bullets to print •••••• instead of the word
Plan & moneyplan name(s), the monthly price across all plans, the plan lines with prices (multi-line), the quote number, the onboarding reference
Debit orderbank account holder, bank, account number, branch code, branch name and town, account type, collection day, mandate reference, the account holder's ID number and address, the debit amount as digits, and the first debit date as DDMMYYYY
Dates & partiestoday's date (long or YYYY-MM-DD) when prepared, the signer's name, and the control room's name, legal name, VAT and registration numbers

Every value comes from the journey's verified answers — the same facts the pending site, the technician's job sheet and the customer record are built from — so nothing is typed twice. A box whose value is empty for a particular customer simply prints nothing.

Preview. Preview with sample data renders the template on the server — the same code that produces the real agreement — with sample values, signer boxes outlined, and opens the PDF in a new tab. Type a journey number into the small box first and the button becomes Preview with journey: the render uses that journey's real answers, so you can check a live customer's agreement before it goes out. The preview always reflects the boxes on screen, saved or not.

Save and activate. Save keeps the boxes; Save & activate makes the template usable (a template with no Signature box, or with boxes that have no value, asks you to confirm — it will still work, the signature just lands only on the certificate page). Save & deactivate takes an active template out of use; a step that pointed at it falls back to the default until another is chosen.

Write it in markdown​

Instead of uploading a PDF you can write the agreement and let CleverOps produce the PDF and its boxes for you. Because the layout engine knows where every value lands as it sets the text, the boxes come from the words and can never drift out of place — there is nothing to drag.

  1. On Onboarding → Contracts, press Write in markdown. On an empty tab you can also press Start from the standard agreement, which drops our standard wording into the editor for you to edit.
  2. Give it a name and a kind, then write. Every line you type is a line in the document; leave a blank line between paragraphs. #, ## and ### make headings, #### text prints a small-caps eyebrow — a letter-spaced line the heading under it sits tight against, in plain words only (a token inside one prints nothing) — **bold** makes bold, *italic* makes italic, > text sets an indented italic line, - and 1. make lists, --- draws a rule, and \newpage on its own line starts a new page. The document is set in the same typefaces as your invoices; neither of them ships a true italic, so *italic* is the ordinary face drawn with a slight slant. A few structures come free: a heading that starts with a number (## 4. Payment) prints its number in your brand colour, and a clause line like 4.1 The Customer… hangs its number in the margin so the text lines up — a clause number needs at least one dot, so 4.1 and 4.1.2 hang in the margin while a bare 4. is an ordinary numbered list item.
  3. For richer layouts there are framed blocks, each opened with ::: and closed with ::: — ::: ribbon prints Label: value lines as a tinted reference strip, ::: cards prints side-by-side cards (split the columns with a --- line; start a card with ### Title for a header band, add ### Title | Tag for a filled brand pill on the band, and a second ### line prints as the card's name line), ::: notice draws a bordered callout (put the liability clause and its {{initials}} box in one), and ::: signatures is a two-column signing block whose titles set as small caps inside the frame. | a | b | lines make a table — the first row is the header, an all-bold row prints as a total row, and a row of unused token slots prints as clean paper rather than an empty ruled row. \pageinitials at the top puts an Initial box in the footer of every page that does not already carry a signature — the South African convention of initialling each page — and the signer's drawn signature fills them automatically, fitted small, so there is nothing extra for the customer to draw. Framed blocks do not nest, and a | a | b | line inside one is plain text rather than a table, so build a table outside its frame. An unclosed ::: is forgiving: it simply runs to the end of the document.
  4. Put a token wherever a value from the journey or the signature should go — choose it from Put a value here on the right and it is inserted at your cursor.
  5. Leave Company letterhead ticked (it is on for a new template) to give the agreement the same look as your invoices and quotes — see below — or untick it for a plain document.
Stay on ordinary letters

The agreement is set in Space Grotesk and Manrope, the same pair your finance documents use. Any character neither face carries is printed as a literal ? in the PDF rather than dropped. Ordinary keyboard characters, accented Latin letters, dashes and curly quotes are all safe; emoji, arrows, box-drawing characters and non-Latin scripts are not. If you paste wording in from another document, preview it and read the result before you activate the template.

Company letterhead​

With Company letterhead ticked, the compiled PDF carries the same branding as your other documents, taken from Settings → Profile (logo, brand colours, company profile):

  • at the top of page 1: your logo (or a monogram chip in your brand colour when there is no logo), the company name, its address, phone and email, the registration number and — when the company is VAT-registered — the VAT number packed onto shared lines, over a brand-colour rule; the document's first heading prints in the brand's strong shade, as an invoice's title does;
  • on every page: the thin brand-colour band along the bottom edge, a hairline with company · email · phone at the left and Page n of m at the right above it.

Untick it and there is no brand to draw on. The words and the boxes are unchanged, but headings, eyebrows and rules print in plain ink instead of your colour, and every tint the layout uses — ribbon strips, card header bands, notice frames, zebra rows — prints in neutral grey rather than a shade of your brand.

The letterhead is compiled into the template, so every agreement prepared from it carries it. If you change the logo, the colours or the company details later, open the template (Edit text) and Save again to recompile with the new look — agreements already prepared keep the look they were prepared with. Uploaded PDFs ignore the option; they bring their own letterhead. The row in the template list reads Written in markdown · company letterhead when it is on.

Tokens​

A token is a value in double braces, like {{customer.legal_name}}. The palette on the right lists every value grouped as it is elsewhere in onboarding — Customer, Contact, Site, Keyholders, Response words, Signatory, Plan & money, Debit order, Dates & parties — plus the four signer boxes: {{signature}}, {{initials}}, {{sign_date}} and {{signer_name}}.

Where a token sits decides what kind of box it becomes:

  • A token on its own line becomes a full-width box — right for the keyholder list, an address block, or a signature.
  • A token inside a sentence becomes a blank the words flow around, sized to the value — right for a name or a number mid-paragraph.

A stamped value prints as typed ink — bound boxes draw no line under the value, so the prepared agreement reads as a prepared document rather than a filled-in form. Only the signer boxes (signature, initials, date, name) draw ruled lines.

Fees and keyholders read best as a table. {{plan.lines}} and {{keyholders.list}} are single values that print as a block of text, but each service and each keyholder also has its own tokens — {{plan.line.1.name}} / {{plan.line.1.price}} / {{plan.line.1.cycle}} (six services, the cycle printing month, year, quarter or once-off) and {{keyholder.1.name}} / {{keyholder.1.phone}} (six keyholders) — so you can put them in a table with a heading row, a right-aligned fee column and a bold total row:

| Service | Fee |
|---|--:|
| {{plan.line.1.name}} | {{plan.line.1.price}} |
| {{plan.line.2.name}} | {{plan.line.2.price}} |
| **Total monthly fee, including VAT** | **{{plan.price}}** |

A table has a fixed number of rows, so use as many as you realistically sell — a row past the last service simply prints empty.

A few tokens take an option after a pipe: {{customer.id_number|mask}} prints •••••• instead of the value, {{keyholders.list|lines=6|rows}} sets how tall a block is (rows adds zebra-striped rows behind it — right for the fee and keyholder lists), and {{signature|label=For the Company}} captions a signer box. The Check panel counts the values and signer boxes as you type and warns if a token is not one of the known values (it would print nothing).

Laying out a paper-style debit-order mandate. A South African mandate form is a grid of one-character cells, so a handful of values print in the shape those cells expect rather than the shape a person reads. Contact phone — digits only ({{contact.phone_digits}}) prints 0825550123 rather than +27 82 555 0123, so the +27 does not burn four cells at the start of the row. Debit amount (digits only) ({{mandate.debit_amount}}) prints whole rands with no R, no comma and no decimal — 450, not R 450,00 — because the form pre-prints the decimal point and its own cents cells. First debit date (DDMMYYYY) ({{mandate.first_debit_date}}) has no separators. Branch name & town ({{mandate.branch_name}}) is the branch line those forms ask for beside the branch code, and Account holder's address ({{mandate.account_holder_address}}) the address they ask for beside the name.

Three of those cells come out empty today

The Set up your debit order step asks for the account holder, bank, account number, branch code, account type, collection day and — on DebiCheck — the ID number, and nothing else. Neither the staff capture form nor the customer portal collects a branch name, a first collection date or a separate account-holder address. So on a real agreement {{mandate.branch_name}} and {{mandate.first_debit_date}} print blank, {{mandate.account_holder_address}} falls back to the site address, and {{mandate.debit_amount}} falls back to the journey's monthly plan total. Lay the form out knowing which cells stay empty.

Don't mask the response or duress word

The signed agreement is the customer's own record of what those words are. Printing bullets means they walk away without them. Write {{response.password}} and {{response.duress}} plainly.

Preview and save​

Preview with sample data renders the real PDF — the same engine that produces the customer's agreement — and opens it in a new tab; type a journey number first to preview it with that customer's real answers. Save compiles it; Save & activate makes it usable. Saving again after an edit recompiles the PDF and its boxes together — agreements already prepared are untouched, and the next one uses the new text.

Your own company details are real in the sample too: {{vcr.name}}, {{vcr.legal_name}}, {{vcr.registration_number}} and {{vcr.vat_number}} come from your profile and default billing entity — the same place the letterhead does — so the preview never names another company in the body. If one of them prints blank, that is what the real agreement will print: fill it in under Settings → Profile or on the billing entity. The customer, site, keyholders, fees and banking in a sample are made-up stand-ins, because a sample has no customer behind it.

The standard agreement is a starting point

The built-in agreement covers the usual ground — parties, services and fees, term, escalation, payment and debit order, keyholders and response words, access, cancellation, POPIA and a signature block. Two parts of it carry weight beyond their wording.

Clause 10, Limitation of liability, is set apart as a bordered callout headed Limitation of liability · Consumer Protection Act s49, opening "Read this clause before signing — it limits the Company's liability", and it ends with an Initial box captioned Customer's initials — clause 10 under the line "By initialling here, the Customer confirms that this clause was specifically drawn to their attention before signature." That box is the s49 record that the clause was drawn to the customer's attention, not decoration — edit the wording freely, but delete the box and you lose the record.

Acceptance sits on its own page as a two-column signing block: For the Customer — signer's name, signature and sign date — beside For the Company, which states that the agreement is accepted when the service is activated and needs no signature from the company (clause 12.4). The declaration above it says the customer has read and understood the agreement including clause 10.

It is still a starting point, not legal advice. Edit it to match how you trade, and have your own attorney check it before you rely on it.

A markdown template's boxes are shown read-only in the box editor (press Boxes on its row) — to move or change them you edit the text. If you ever need a layout the markdown cannot express, Convert to a fixed PDF on the box editor keeps the boxes exactly where they are and hands them to you to edit by hand, like an uploaded PDF; the text is kept for reference but no longer drives the template.

Which step uses which template​

Below the template list, Which step uses which template has three pickers, each listing only active templates of a fitting kind:

  • Service agreement — the seeded Sign your service agreement step, on journey kinds whose Paperwork profile is New contract.
  • Amendment — the Sign your amendment step, on kinds set to Amend the existing contract (add-ons).
  • Debit-order mandate — the signed (e-sign) mandate. Leave it empty to keep the generated mandate PDF; with a mandate template, the banking details the customer typed are stamped into its boxes instead.

A picker nobody has touched fills itself: the first time an agreement, amendment or mandate template is active while its picker is still empty, that template is chosen for the step. A choice somebody made is never replaced. Where a company has templates but the step still has none chosen, the journey workspace's Agreement not prepared hold lists them as Use “template name” buttons — pressing one chooses it here and prepares that journey's agreement from it in one move.

Each picker's default is the behaviour described in Preparing the service agreement and Signing the debit-order mandate. Choices apply to agreements prepared from then on.

What happens on a journey​

With an agreement template chosen, the Sign your service agreement step on the customer's Getting Started page reads "We'll prepare your agreement once your details are checked" and names what is still to come. The agreement is prepared automatically — no one presses Prepare — the moment all of this is true:

  • the journey has its customer (onboarding has been opened);
  • every form step the agreement fills in from — Who the account is for, Confirm your details, Your people — is verified, waived, or was captured by staff on the customer's behalf;
  • and, when the company's mandate mode is Signed mandate (e-sign) and the journey has a Set up your debit order step that is still open, the customer's banking details are in — because the mandate then goes into the same document as the agreement. Until then the step says so: "enter your banking details first — then you sign your agreement and your debit order together, with one signature." Waiving the debit-order step lets the agreement go out on its own.

Within a minute of that, the agreement (or the agreement and the mandate, as one PDF) appears on the page as Read & sign now — the usual OTP-verified e-sign flow, with the signature placed into the template's boxes. Signing it completes the Sign your service agreement step, and — when the mandate was included — the Set up your debit order step too, creating the debit-order mandate record exactly as a separately signed mandate would (subject to the Activate mandate gate). The debit order's own signed-PDF record is this same document.

On the journey's Paperwork tab the agreement row says what it is waiting for, offers Prepare now anyway (prepare it immediately — boxes for answers still missing print blank, and a debit order entered later is signed on its own), and Prepare again after the customer declined or staff withdrew an envelope. The mandate row notes when it "signs together with the service agreement". Every other Paperwork action — Send, Resend, Copy link, the signed PDF, Withdraw — works on the prepared document as on any other envelope.

Hash-locked, like every e-signed document

The prepared PDF is snapshotted the moment it is built; the signing page re-checks its fingerprint before accepting a signature, and the certificate page records that fingerprint — so an agreement can never silently change between "prepared" and "signed", even though the journey's facts are live.