Skip to content

CleanCore · Quality & KPIs

Cleaning KPIs and abatement, computed rather than compiled

The KPI is worked out on the server from the inspections and non-conformances that exist, and the abatement arithmetic is shown to the customer in full.

Book a demo See pricing

The problem this solves

Every serious cleaning contract has a quality KPI and a financial consequence for missing it. The monthly argument about that number is rarely about the cleaning. It is about the spreadsheet: whose figure, from which population, over which month.

CleanCore removes the spreadsheet. Non-compliance is counted from the inspections and the non-conformance register, split so that a fleet KPI and a facility KPI never divide by one another, and measured against the target the contract sets for that month.

The abatement is then calculated from the month’s invoiced value — derived from the contract and the invoices, not typed in — and the customer is shown the working: the rate, the target, how far over, what it was applied to, and what it came to. A number a customer can query is worth more than a number you have to defend.

Worked example

A month closes over its contract target for non-compliance.

  1. 1

    The population is fixed first

    Inspections and non-conformances for that contract month, with the fleet and facility KPIs kept apart so one cannot inflate the other.

  2. 2

    The basis is derived

    The month’s invoiced value comes from the contract and the invoices, so the internal screen and the customer’s screen cannot disagree.

  3. 3

    The arithmetic is written out

    The rate, the target, how far over, what it was applied to and the cap — as a sentence on the customer’s own screen, not as a figure in an email.

  4. 4

    Root cause is attached

    Each finding carries a root cause from a fixed taxonomy and traces back to the walk that found it and the clean it is about.

The month is priced by the system against itself before the invoice goes out, which is a different conversation from being billed for a breach after it.

Capabilities

What quality & kpis gives you

6 of these 7 are in the product today; the rest carry a badge saying what they actually are. Each one names what it is built on.

Inspection templates from real standards

Live

Reusable templates per area type drawn from ISSA CIMS and APIC, so a walk grades the same way whoever does it.

First included in the Pro tier

Defect capture and closure

Live

A failed line raises a defect on the spot, assigns it and closes it, with a work order behind it when the fix is remedial work rather than a re-clean.

First included in the Pro tier

Contract KPIs, computed not compiled

Live

Non-compliance against inspections, split so the bus KPI and the facility KPI never divide by each other, measured against the target the contract sets for that month.

First included in the Pro tier

Abatement worked out, and shown working

Live

The contract penalty calculated from the month’s invoiced value on the server, with the arithmetic written out for the customer: the rate, the target, the overshoot, the cap.

First included in the Pro tier

Non-conformance register with root cause

Live

Findings carry a root cause from a fixed taxonomy and trace back to the walk that found them and the clean they are about.

First included in the Pro tier

Statistical sampling with a stored seed

Roadmap

Inspections drawn to an AQL rather than chosen by whoever is walking, with the randomisation seed stored so the sample can be defended.

On the roadmap. It is not built, not scheduled, and not something to plan a contract around.

First included in the Enterprise tier

Complaints, and the answer that went back

Live

Every complaint, compliment and survey in one register, each linked to the non-conformance and the corrective action it caused, and each carrying the date a response went back — so the register warns on "nobody has answered", not on "still open".

First included in the Pro tier
What backs these claims

Each capability names the decision record, module, route or table it is built on. Ask us for any of them in an evaluation and we will walk you through the code.

Inspection templates from real standards
src/server/imss-inspection-library.ts · /imss/inspection-library · v3 cleaning_inspection
Defect capture and closure
src/server/api/imss/cleaning-defects/PATCH.ts · migration 0014
Contract KPIs, computed not compiled
src/server/api/imss/cleaning-kpi/GET.ts · computeCleaningKpi
Abatement worked out, and shown working
src/server/imss-cleaning-kpi-basis.ts · client-portal/cleaning-kpi
Non-conformance register with root cause
imss_cleaning_non_conformances · NC_ROOT_CAUSES
Statistical sampling with a stored seed
docs/research/cleancore-roadmap.md G33
Complaints, and the answer that went back
ADR 0053 · src/server/imss-qms.ts respondToFeedback · imss_customer_feedback · /imss/customer-feedback

Where this sits

Back to

CleanCore — every capability in one place

The whole module: what is live, what is committed, what is only on the roadmap.

Read next

Prove the cleaning was done — and who did it

Every clean, verification, exclusion and defect is written once, in the same transaction as the act itself, so the record cannot be edited into a different past.

Twenty minutes on a real contract.

Real data, four logins, nothing typed on the day — including the parts we have not built, which we will point out ourselves.

Book a demo See pricing