Apex Climate Solutions: automating intake and operations for a heating and cooling company

A small HVAC shop loses time in three places: sorting incoming requests by hand, technicians hunting for answers, and problems noticed only after they cost a job.

• Intake. Requests arrive by phone, web form and WhatsApp, and a person reads each one, so a no-heat emergency can sit behind a routine maintenance request.
• Field knowledge. Refrigerant procedures, city permit rules and warranty terms live in people's heads. Technicians phone the office or guess.
• Oversight. Overdue jobs, empty truck stock and permits stuck in pending too long come to light only after they cause a missed job.

I set three constraints: one simulated client; free tiers wherever they held up; and, once the free plan proved too small, a ceiling of 10,000 Make.com operations (billed workflow steps) a month.

Three things reach a customer before a person sees the request: the voice agent's live conversation, which follows a set script to gather the caller's details; the WhatsApp acknowledgment; and the form confirmation email. After that, each request is recorded and checked by fixed rules, unknown senders also pass the junk filter, and real requests are rated and posted to Slack, where a person reviews and decides.

Here is one request, step by step:

1. Saved first. The message is written to the database before anything judges it, which also catches duplicates.
2. Screened by rules. A rule-based filter checks it, then the sender is looked up by exact match against known customers.
3. Junk check, for unknown senders only. A message from someone who isn't a customer goes through the junk filter (an AI call).
4. Read and rated. One AI call pulls out the name and equipment, and another rates the urgency. A fixed format check inspects every AI reply.
5. Handed to a person. The request is posted to #urgent or #normal-triage in Slack, where a person reviews and decides.

I made each choice against a named alternative, for a stated reason. Model choices link to the test behind them.

• Urgency rater on the most capable model. It started on the cheaper Sonnet 5, which matched on all 43 test cases. Two prompt versions later, it missed six emergencies, so I moved the rater to Opus 5.5.
• Junk filter on the cheapest model that passed. I compared four models on the same 48 messages. Haiku 5.5 kept every real request at about one-eighth the cost of Haiku 4.5, the model it replaced.
• Technician answers on a small, free-tier model, Gemini 3.5 Flash Lite. On the free tier, the larger Flash models were capped at 20 requests a day; Flash Lite allowed 500. An answer that cites nothing is blocked, and the technician sees the source it cites, so a bigger model would buy little. I fixed every failure by changing the prompt.
• AI where judgment is needed, fixed rules everywhere else. I weighed running intake as a single AI agent, with a prompt listing the steps and the agent interpreting them and choosing a tool for each. I rejected it: no intake case needs an agent's loop of searching and retrying, and fixed steps keep each decision testable and auditable, with a plain record of every step and no risk of runaway cost. Intake instead runs on fixed rules wherever the logic is predictable, and reserves three single-purpose AI calls for the steps that need judgment: screening junk, extracting details and rating urgency. Every request still reaches a person before the company acts on it.
• Make.com over Zapier and n8n. Make bills per operation, has visual branching, and lets one workflow (a Make "scenario") call another directly. Self-hosting n8n adds a server to run and secure.
• Directus over Baserow for the office screen. When I checked during the build, Baserow couldn't sit on the existing database. Directus reads it as it is and limits each person to the columns they need.
• Watchdog as one database function. My first design looped through every open job in Make, which would have cost about 57,000 operations a month, more than five times the 10,000 budget. I moved the checking into the database instead. One function applies every rule, from overdue jobs to stalled permits, and returns each neglected job with its reason; Make just calls it every 30 minutes through the working day. The rules live in one place, and I tested their time limits and stock thresholds on a copy of the database with a fixed test clock, without spending Make credits.
• Prompt caching, adopted after measuring it. Caching lets the AI provider reuse the unchanging part of a prompt at a lower price. Testing it on a copy of the workflow found two silent problems: the original Make template couldn't carry a cache marker, and automatic caching would have marked the customer's message, which changes every time. I built a new template with the marker on the fixed instructions, then compared the 5-minute and 1-hour cache options and adopted the 1-hour one. It cuts the urgency rater's token cost by an estimated 63 to 73% (modeled, not yet measured over a real month).

Most failures take a safe default or reach a person in Slack; the few that don't are named as accepted limits in the technical as-built. I designed the tests to find the AI's mistakes.

One failure route: if the urgency rater returns a reply that fails the format check, no job is created; the raw request is posted to #urgent for a person. Operational alerts use a fixed six-line format.

What the tests caught

• The cheaper urgency model rated six "elderly relative, system fully down" messages as level 4 instead of 5.
• An independent check of the first junk-filter prompt found 7 of 36 replies added text after the expected reply, which would have broken the next step. My own tests had missed it.
• The junk filter's original model wrapped 140 of 144 replies in code formatting. A cleanup step had been hiding it.
• Asked about a Lennox furnace, the answer step replied from a generic furnace entry. Two prompt versions later, it leaked one of its own instructions into a reply. The AI judge, a second model that grades each answer, caught it.
• A test with a forged request crashed the check that verifies incoming messages, because the message body was empty. I fixed it the same day.

Only intake counts as essential. I asked of each component what would break if it were switched off. Intake is the only step where a delay costs a customer within minutes. For the watchdog the cost builds over days, and technicians can call the office, so I treat those two as important but not critical.

I kept two records. Design decisions went into the charter's dated decision log with the reasoning at the time; where a setting's date or reason was never recorded, the record says so rather than filling it in afterwards. From mid-September, every open item went into a Jira backlog with a definition of done: what had to be true to close it.

The public charter holds the scope, the architecture, the list of what's built, designed only or declined, and the decision log. How I run this kind of work, from charter to map to backlog to build and test, is on the How I build automation page.