Compliance is a date problem

Ask a contract-services operator what keeps them awake and they rarely say "we do not know who is certified". They say "I do not know whose certificate runs out next month". The information exists. It is in a folder, a spreadsheet, and the memory of one supervisor who is on leave.

We built a business management system for a company with more than three hundred staff across many sites. The useful insight came early: almost every compliance problem in that business is a date that nobody was watching.

A record that cannot expire is not a compliance record

The common design is a staff profile with a checklist of documents. It answers "does this person have X?" — a question nobody is actually asking. The question is "who will stop being eligible, and when, and which sites does that affect?"

So the unit of data is not the document. It is the validity window: this person holds this qualification, from this date, until this one. Everything useful follows from storing it that way:

• A list of what expires in the next thirty, sixty, ninety days
• A site view that shows coverage gaps before they happen, not after an audit
• A roster that will not let you assign someone whose certification ends mid-contract

Attendance is evidence, not surveillance

Attendance in this kind of business is usually framed as checking up on people. In practice its job is to answer an invoicing question and a dispute question: who was on this site, on these days, for how long — and can we show it when a client challenges a line on the invoice?

Designed as evidence, attendance needs to be simple to capture, hard to fake and easy to export in a form a client will accept. Designed as surveillance, it grows features nobody uses and everybody resents.

The bid calculator is where the money is

The feature that changed the most for this customer was not compliance tracking. It was a calculator that prices a new contract from real cost data — staff rates, site hours, consumables, margin — instead of from memory and an old spreadsheet.

Two things made it work:

• It uses the same cost figures the rest of the system uses. A calculator with its own private numbers is a spreadsheet with a login screen.
• It shows the assumptions beside the result. The output of a bid tool is a number someone has to defend in a meeting. A number without its workings will not be trusted, and should not be.

One place, or it does not get used

Staff, sites, attendance, invoicing and bidding were five separate habits in this business before the system existed. The temptation when building is to deliver five good modules. The thing that actually determines adoption is whether the supervisor can do their whole morning in one place. A module that forces someone back into a spreadsheet for one step loses to the spreadsheet entirely.

What we would tell someone scoping this

• Find the dates. Every compliance system is a calendar wearing a different hat.
• Ask what each record has to prove, and to whom. That tells you the export format, which tells you the data model.
• Build the thing the owner personally checks every week first. That is what gets the system opened daily.
• Count the places a user has to leave your software to finish a task. Drive it to zero for the core workflow.