One system to manage your entire workforce, from recruitment to allocation to compliance.
❌ Spreadsheet chaos: operative data scattered across files
❌ Compliance risk: expired CSCS cards slip through
❌ Manual recruitment: hours spent on unqualified applicants
❌ No visibility: who's working where, when?
❌ Slow allocation: phone tag to fill urgent gaps
❌ Database poaching: staff leave and take contacts
Central labour control with one key principle: Reallocation First
All labour allocation flows through a single point (Liam). Site Managers, PMs and Directors request through him via WhatsApp.
Before external recruitment: 1) Reallocate finishing workers 2) Search internal database 3) Only then raise adverts.
Every allocation checks skill requirements against qualifications. Rate matrices enforced automatically.
No operative works without valid RTW, Photo ID, and in-date CSCS. System blocks non-compliant allocations.
| Skilled Landscapers | CSCS Green |
| General Labourers | CSCS Green |
| Groundworkers | CSCS Green |
| Pavers / Kerb Layers | CSCS Green |
| Plant Operators | CPCS/NPORS |
| Drainage Operatives | CSCS Green |
| Carpenters | CSCS Blue |
| Bricklayers | CSCS Blue |
| Stone Masons | CSCS Blue |
| Steel Fixers | CSCS Blue |
| Site Managers | CV + Quals |
| Project Managers | CV + Quals |
| Engineers | CV + Quals |
| Supervisors | CV + Quals |
| Design Managers | CV + Quals |
| Document Controllers | CV + Quals |
| Quantity Surveyors | CV + Quals |
| H&S Officers | CV + Quals |
White collar: CVs searchable, full compliance docs collected when role offered.
Four ways in, one central brain, secure storage.
/api/operatives
Manage workers
/api/allocations
Assign to sites
/api/ncrs
Log issues
/api/webhooks
Receive messages
/api/documents
Store files
Watch how data flows between the apps in real-time scenarios.
Applicant applies → Sophie qualifies → Liam reviews
Liam sends shift offer → Operative accepts
Operative assigned → Arrives at site
Site Manager manages arrivals + performance
NCRs and problems → Escalate to Liam
Every technology chosen for reliability, security, and long-term support. Here's what we're using and why.
What it is: A managed database service built on PostgreSQL, the same database technology used by Instagram, Spotify, and Netflix.
Why we chose it:
What it is: A cloud hosting platform that runs your web application. Think of it as the "building" where your software lives.
Why we chose it:
What it is: The framework that builds the actual web application: the screens, buttons, and interactions Liam will use daily.
Why we chose it:
What it is: Where all the code is stored and versioned. Like a filing cabinet that tracks every change ever made.
Why we chose it:
What it is: The official way for businesses to send and receive WhatsApp messages programmatically.
Why we chose it:
What it is: The AI technology powering Sophie, your recruitment assistant who qualifies candidates 24/7.
Why we chose it:
All technologies use open standards. If you ever want to move providers, your data and code come with you. You own everything.
Watch a labour request flow through the system.
Before any external recruitment, the system follows this priority:
Why this matters: Agencies make money on placement fees. This system prioritises your existing workers first, cutting external recruitment costs by maximising internal utilisation.
10 core tables with full referential integrity.
Operatives: Names, phone numbers, day rates, skills, certifications, ratings
Documents: CSCS cards, RTW proof, photo IDs, with expiry dates
Sites: All your work locations with addresses and postcodes
Allocations: Who's working where, when, and for how long
NCRs: Non-compliance reports with severity levels
Communications: Full log of every WhatsApp message sent/received
CREATE TABLE operatives ( id UUID PRIMARY KEY, first_name VARCHAR(100) NOT NULL, phone VARCHAR(20) UNIQUE, day_rate DECIMAL(8,2), rtw_verified BOOLEAN DEFAULT false, cscs_expiry DATE, avg_rating DECIMAL(3,2), status VARCHAR(50) );
Sophie qualifies candidates 24/7 via WhatsApp. Here's what the conversations look like:
Before any operative can be allocated to a site, the system automatically checks:
If any check fails → Allocation blocked automatically
| Document | Alert Days | Action |
|---|---|---|
| Right to Work | 30, 14, 7, 0 | Blocks |
| CSCS Card | 60, 30, 14, 0 | Blocks |
| CPCS/NPORS | 30, 14, 7 | Warns |
No overrides. System enforces at database level.
The system enforces UK labour law automatically on every shift assignment:
System tracks weekly hours across all sites. Warns at 44hrs, blocks at 48hrs (unless opt-out on file).
Minimum 11 hours between shifts enforced. System won't allow back-to-back assignments that violate rest periods.
6+ hour shifts require 20min break. System calculates and records break compliance automatically.
Workers can only be assigned to equipment they're certified for:
System matches job requirements to operative certifications. No cert = no assignment to that equipment.
Every operative has a performance score that influences future allocation priority:
Site managers rate operatives via WhatsApp at end of assignment:
System tracks workers who shouldn't be rehired:
| Active | Available for work |
| Caution | Requires approval |
| Do Not Rehire | Blocked permanently |
When filling a labour request, the system automatically ranks candidates by:
Best performers get offered work first. Poor performers drop to bottom of queue.
function canStart(operative) { const blockers = []; if (!operative.rtwVerified) blockers.push('Right to Work'); if (operative.cscsExpiry < today) blockers.push('CSCS Expired'); if (operative.status === 'blocked') blockers.push('Blocked'); if (weeklyHours(operative) >= 48) blockers.push('Working Time Limit'); return blockers.length === 0; }
Each user only sees their own organisation's data. The database enforces this automatically, making it impossible to access another company's operatives.
Per BOS Bible: Controls in place to ensure the operative database cannot be bulk exported. Your data stays in the system.
-- Users only see their organization's data CREATE POLICY "org_isolation" ON operatives FOR SELECT USING ( organization_id = ( SELECT organization_id FROM users WHERE id = auth.uid() ) );
Requirements, database, auth setup.
2 WeeksOperatives, sites, allocations, compliance.
6 WeeksWhatsApp, Sophie AI, NCR flow.
3 WeeksTesting, training, go-live.
3 Weeks✓ Database live
✓ Auth working
✓ Dashboard shell
✓ Operative management
✓ Document tracking
✓ Allocations
✓ WhatsApp connected
✓ Sophie live
✓ NCR via WhatsApp
✓ UAT complete
✓ Training done
✓ Go-live
Cold Lava maintains comprehensive insurance coverage and built-in safeguards to protect your investment at every stage.
Review the technical architecture. Confirm this matches your operational requirements.