The Quickler Format.

Version 0.1 · Published April 2026 · Last revised 2026-05-26 · Maintained by Quickler Ltd, Scotland · Contact hello@quickler.co · Licensed under CC-BY-4.0.

Why a format

Field compliance work - van checks, gas tightness tests, structural inspections, retrofit verifications, and any inspection or checklist, not just one trade - is recorded by people whose phone is the only computer they carry. The format is rooted in UK compliance but works anywhere WhatsApp does, and is used across English-speaking markets including the UK, Ireland, the United States, Canada, Australia and New Zealand. (Quickler works in any country.)

A lot of that data is captured in WhatsApp messages, voice notes and photos that never become structured records. The systems that do capture it often use proprietary apps engineers do not install.

The Quickler Format is an open specification for how a compliance check should be recorded over messaging, and how the resulting report should be structured, so that:

• Engineers do not need to install or learn an app
• Office managers receive a consistent, machine-readable record
• Building control officers, insurers and certifying bodies can read the report without a vendor-specific viewer
• Any vendor can implement it; clients are not locked in

This document is a working draft. Comments and pull requests are welcome.

Scope

The format covers three things:

1. The check definition - what the engineer is asked
2. The capture conversation - how the engineer responds
3. The report artefact - the PDF or JSON the office and third parties receive

It does not cover scheduling, pricing or how engineers are dispatched - those are the vendor's problem.

1. Check definition

A check is a JSON object describing one repeated process. Example:

{
  "id": "weekly-van-check-2026-04",
  "name": "Weekly van check",
  "owner": {
    "firm": "Example Trades Ltd",
    "firm_id": "GB-CH-12345678"
  },
  "fields": [
    { "key": "tyres",        "label": "Tyres OK?",        "type": "boolean", "required": true },
    { "key": "lights",       "label": "Lights working?",  "type": "boolean", "required": true },
    { "key": "fluid_levels", "label": "Fluid levels OK?", "type": "boolean", "required": true },
    { "key": "odometer",     "label": "Odometer photo",   "type": "photo",   "required": true },
    { "key": "fault_notes",  "label": "Any fault?",       "type": "text",    "required": false }
  ]
}

Field types

• text - free text
• boolean - yes / no
• number - numeric (whole or decimal)
• photo - one or more JPEG/HEIC images
• voice - one audio clip; transcribed automatically
• signature - captured as an SVG path or PNG

2. Capture conversation

The engineer is messaged via WhatsApp (or any other compliant transport). The system asks one question per field, in order. The engineer replies in any combination of text, photo, voice. The system parses the reply into the typed value.

Compliant implementations MUST:

• Allow the engineer to skip non-required fields with a single reply (e.g. "skip" or "n/a")
• Allow the engineer to correct a previous answer at any time before finalisation, by sending the field name and a new value
• Respect WhatsApp's 24-hour session window - pre-approve a Meta Business template for any conversation that may span longer

3. Report artefact

Each completed check produces a PDF report rendered from a deterministic template, containing:

• Firm name, registration number, branding
• Engineer name, mobile number (E.164), date and time of completion
• Each field's label, value and any attached media (rendered inline)

The specification reserves space for two additional features that are not required in v0.1 implementations and are not yet present in the reference implementation:

• A SHA-256 hash of the underlying JSON record, printed in the report footer (intended to make the report tamper-evident).
• A JSON sidecar with the raw structured record, embedded in the PDF as an attachment per ISO 32000-1 §7.11.

Both are tracked as open questions for v0.2.

Compliance levels

A vendor can claim:

• Quickler-Format Capture - supports section 1 and section 2
• Quickler-Format Reporting - supports section 3
• Quickler-Format Full - supports all three

Reference implementation

A reference implementation is maintained by Quickler Ltd. To request access or discuss commercial use of the Quickler-Format mark, email hello@quickler.co.

Open questions for v0.2

• Schema for non-photo evidence (CAD files, IFC models)
• Multi-engineer sign-off (one capture, two engineers attesting)
• Localisation beyond English (multi-market: Welsh, Gaelic, Polish, French, Spanish and others, spanning UK and international trades languages)

This document is © 2026 Quickler Ltd, released under CC-BY-4.0. Forks and derivative formats welcome - please cite the source.

Conformance declarations

Vendors implementing the format are listed here once a declaration is filed:

• None yet - be the first.

Implementing the spec?

Send a conformance declaration to hello@quickler.co.