CRM HVAC — Customer 360
A CRM proposal for Airzone: from lead to warranty in one system
- Product, business analysis and AI-directed development
- September 2026
Demo environment with fictional data. Independent proposal: not official Airzone software and contains no confidential information.
Overview
A Customer 360 CRM that connects the sales cycle with the installed base of climate-control equipment: leads, quotes, installations, warranties, tickets and field technicians.
Proposal / demo built with public industry information and fictional data. It is not official Airzone software.
- data models (Prisma)
- 93
- screens
- 134
- roles, permissions enforced in SQL
- 14
- E2E tests passing
- 1344/1344
Built with a Claude coding agent steered by project rules (CLAUDE.md), a spec and tests. Inside the product, a Claude-powered assistant summarises, suggests the next action and classifies — but never modifies business data.
No public demo: this project runs locally.
A product that lives for ten years in someone else’s building.
A climate-control manufacturer does not sell once and move on: its product is installed in someone else’s building, wired to another manufacturer’s machine and fitted by a third-party installer. The customer relationship continues for years of warranties, maintenance and renewals.
I put this proposal together for Airzone using public industry information only. The goal: show what a CRM that actually understands that business would look like, instead of a generic CRM forced to fit.
Generic CRMs model customers and deals. That’s not enough here.
A standard CRM organises customers, opportunities and tickets. In HVAC the other half is missing: which equipment is installed, where, with which control system, under which warranty and with what technical history.
Without that seam, sales and support work from different data, equipment compatibility is assumed rather than verified, and maintenance or renewal opportunities are lost.
Two worlds and the seam between them.
The system models the sales cycle and the installed base as a single journey.
Lead
Capture and scoring
Opportunity
Staged pipeline
Configuration
Verified compatibility
Quote
Immutable versions
Installation
Site · HVAC system · assets
Warranty
Activation and coverage
Ticket
SLA and work order
Renewal
Maintenance and upsell
Three rules that define the product.
- Compatibility is verified data
- If no rule is registered for a machine model and a product, the status is “pending validation” and the configuration cannot be approved.
- Commercial history is immutable
- A sent quote version is never edited: the next one is created. The customer accepts or rejects it through a public tokenised link.
- Authorisation is enforced in SQL
- Every query is scoped to the role. If a permission is missing, the query returns zero rows, not all of them. 14 roles, from super admin to read-only.
What you can do with it.
Stills from the demo walkthrough (fictional data).
A complete system, not a mock-up.
- CRM and sales
- Scored leads, contacts, companies with a 14-tab 360 view, Kanban pipeline, quotes with approvals, and orders.
- Installed base
- Sites, installations, HVAC systems, assets, warranties and a compatibility matrix.
- Support and field
- SLA-tracked tickets, work orders, technician scheduler, a “My day” mobile view and a CalDAV calendar.
- Telemetry
- Remote diagnostics for connected installations over MQTT, with a clearly labelled gateway simulator.
- Marketing and analytics
- Campaigns, GDPR consents, sales/customer/support analytics, a province map and a report builder.
- Administration
- Users, roles, teams, CSV import, automations, HMAC-signed webhooks and an append-only audit trail.
Layers with strict responsibilities.
Next.js App Router on PostgreSQL. Every external service follows an interface + mock + real adapter pattern.
guard
Authentication and authorisation required on every request.
domain
Pure, tested business rules.
services / actions
Queries and mutations through Server Actions.
providers
Swappable integrations, all runnable locally with Docker.
I direct; AI executes; tests decide.
The code was written by a Claude agent. The decisions, the boundaries and the definition of done were mine.
Spec
Business, roles, flows and Definition of Done
Rules
CLAUDE.md: fixed stack, never invent confidential information, never expose secrets
Build
11 phases with a progress log
Evaluation
Review with the real toolchain: 62 bugs logged and fixed
Verification
typecheck, lint, unit, build and E2E before anything counts as done
A real example: reviewing the CalDAV integration showed any user could read the calendar; authentication was added to Radicale.
Verified, not promised.
Engineering figures recorded in docs/testing.md on 24/09/2026. These are not business metrics: it is a demo.
- unit tests across 34 suites
- 258
- E2E tests passing, two consecutive runs
- 1344
- access matrix: routes × roles
- 126 × 8
- screens audited with axe (WCAG 2.1 AA)
- 28
AI writes fast. Judgement is still human.
A coding agent is extremely fast, but only useful if the problem is well defined. The most valuable part was not asking for screens: it was setting verifiable business rules and a definition of done that cannot be skipped.
I also learned to distrust “all green”: evaluating with the real toolchain surfaced security issues (IDOR, scope leaks, login throttling) that only appear when permissions are tested for real.