Concept
BayNorth Heating & Cooling Concept
Service-business product concept
Every caller asks the same three questions before they book. This concept answers all three in about fifteen seconds, without anyone picking up the phone.
BayNorth Heating & Cooling Concept is a fictional business created to demonstrate what this kind of software can do. It is not a real company, and nothing on the concept site describes a real one.
The problem
A fictional residential heating and cooling company — and every real one like it.
A residential service business answers the same three questions all day: do you cover my address, what will it cost, and when can you come. Those calls are unavoidable overhead, most of them do not become jobs, and the owner is usually the one taking them.
The conventional response is a website with a phone number and a contact form, which does not answer any of the three. It just moves the conversation to a slower medium.
What I built
A concept for what the interface could be instead: enter an address, get a real coverage answer, a real service window, and a real price for the visit — before anyone is asked to make contact.
BayNorth Heating & Cooling is a fictional business. The software underneath is not: addresses are geocoded against the US Census geocoder, coverage is computed by testing the result against real service-area polygons, and availability is derived from a schedule configuration rather than written into the page.
- Address geocoding and coverage determination
- Service-zone polygon matching
- Availability derived from a schedule configuration
- Cost estimation with stated assumptions
- A qualified service request that arrives with context attached
Why not a template
A conventional small-business website presents information: hours, a phone number, a form. This concept makes the website part of the business workflow — the address gets geocoded, tested against a real service boundary, and answered with a real appointment window, instead of just displaying a page about the business and waiting for a call.
What it demonstrates
- 01Geospatial computation — geocoding and polygon matching
- 02Scheduling and availability logic
- 03Conversion design driven by the questions customers actually ask
- 04Configuration-driven architecture, deployable for another business
- 05Tested business logic, not just a tested interface
What this could become
Every business-specific fact in the concept — the service area, the fees, the hours, the lead time, the services offered — is configuration rather than markup. Nothing about heating and cooling is written into the interface.
That means the same system can be set up for a plumbing, electrical, roofing, excavation or septic business by changing the configuration, not by rebuilding the site. The demonstration is one business; the thing underneath is not specific to it.
For a real deployment, the schedule configuration is the piece that would be replaced. The concept computes availability from a fixed weekly template, which is honest for a demonstration and insufficient for a working business — a real one would read from whatever the office already uses, whether that is a dispatch system, a shared calendar, or a spreadsheet.
- Connect availability to the real scheduling system, whatever it is
- Route qualified requests into the existing CRM or inbox
- Set the service-area polygons from where the trucks actually go
- Set the fees and estimate assumptions from real job history
- Reconfigure for a second trade without rebuilding
Tell me what you're trying to build.
Tell me about your business and what's getting in the way. You'll get a straight, specific reply back, usually within one business day.