Home Automation Proposals: Scope, Device Lists and Support Terms With AI

Turn your site-visit notes into a discovery summary the client can correct, write the scope room by room, list every device with its connection type, name the exclusions, and set support terms with response windows. AI drafts each part from your notes. You check compatibility yourself, because AI cannot know your stock, the firmware or the wiring behind the plaster.

Sample proposals on document sites show you a layout. They do not show the sentences that cause arguments six months later: "networking not included", "support included", "compatible with your existing system". Those are the lines to get right, and they are where an AI draft sounds most confident and is most often wrong, because it fills gaps in your notes with plausible detail.

Follow me on Instagram@sagnikteaches

Site-visit notes to a discovery summary the client can correct

Everything else in the proposal rests on the discovery summary, so draft it first and send it before you price anything. It gives the client a cheap chance to say "that is not what I meant", and it gives you a record of what was agreed when a scope argument comes later. The example house throughout is a four-bedroom family home being retrofitted: lighting scenes in five rooms, separate heating control upstairs and down, a video doorbell, and remote checking while away. These are the installer's notes, typed on the doorstep (illustrative):

Connect on LinkedInSagnik Bhattacharya

Thurs visit. 4-bed detached, built 1998, family of 5 (2 teens, 1 young child).
Wants: lights in lounge, kitchen, hall, landing, master bed to dim. "Evening" and "night" buttons.
Heating upstairs separate from downstairs. See who is at the door. Check heating from phone when away.
Current: ISP router in hall cupboard, wifi poor upstairs. Gas boiler in utility, wired stat in hall.
Switch boxes: NO neutral at hall + landing (checked). Lounge, kitchen, master: neutral present (checked 3 only).
Loft access easy. No data cabling anywhere. Apple phones x3, one Android (dad).
Budget "around 6-8k", not firm. Wants it done before school holidays (about 10 weeks).
No cameras inside. Dad worried about "cloud" and monthly subscriptions.

Give the AI those notes with a tight instruction: write a discovery summary in three parts (what we heard, what we found, not yet decided), use only what is in the notes, and say so where a note is partial. That last clause is the difference between a summary and a story. A first pass produces something like the following, with the problems left in.

Subscribe on YouTube@sagnikteaches

What we heard. You want lighting scenes ("Evening" and "Night") in the lounge, kitchen, hall, landing and main bedroom; separate heating control for upstairs and downstairs using smart radiator valves; a view of who is at the front door; and the ability to check the heating when you are away. You would prefer no indoor cameras and want to limit monthly subscriptions.

What we found. The router is in the hall cupboard and Wi-Fi is weak upstairs. The boiler is in the utility room with a wired thermostat in the hall. Neutral wires are present at all other switch boxes; the hall and landing do not have one. There is no data cabling and loft access is easy.

Targets. Handover before the school holidays, about ten weeks away, within a fixed budget of $6,000 to $8,000.

Three things in that draft would cause trouble, and each is typical. First, "neutral wires are present at all other switch boxes" turns "checked 3 only" into a claim about every box. Second, "using smart radiator valves" is a heating method nobody decided; the notes only said upstairs and downstairs should be separate. Third, "a fixed budget" has lost the words "not firm", which changes how the client reads the price later. Fix all three before the summary leaves your desk. The corrected lines read: "neutral confirmed at the lounge, kitchen and main bedroom; remaining boxes to be checked on survey", "heating method to be agreed" and "budget around $6,000 to $8,000, not fixed".

Send the corrected summary with one sentence: "Please reply with any corrections; once you confirm, this is the basis for the price." A "looks right" in reply is sign-off, and it stays with the proposal file. If the client corrects something, the correction is now free information rather than an expensive surprise at installation.

Room-by-room scope written as outcomes the client can test

Scope written as devices ("install eight smart dimmers") leaves the client unable to judge what they are getting, and leaves you exposed when a scene does not do what they pictured. Outcome wording gives both sides something to test at handover. Each row says what the household will be able to do, what work is included, and what the row depends on.

To draft this table, give the AI the agreed summary and your survey notes with a clear instruction: one row per area, outcomes someone could test at handover, and a "depends on" entry wherever my notes do not settle whether the work is possible. Then read the dependencies column first. AI drafts tend to leave it thin, because "depends on" sounds like hedging. If the hall and landing rows come back with no dependencies, reject the draft and say why: the notes say there is no neutral wire there.

The device list: columns that expose compatibility problems early

A device list that says "8 x smart dimmer" is a shopping list. One that says what each device connects with, what it needs from the house, and who supplies it is a compatibility check you can read in a minute. These columns catch most surprises. The model numbers are yours to fill in from the datasheet, which is why the table below leaves them as a column you complete rather than something the AI invents.

A little background helps you read the "connects by" column and explain it to clients. Matter is a standard meant to let devices from different makers work together. It runs over Wi-Fi, Ethernet and Thread, which is a low-power mesh network. Thread devices need a border router to reach the rest of the home network, and a home can have more than one. Zigbee and Z-Wave devices can join a Matter setup through a compatible bridge. The Connectivity Standards Alliance describes Matter as a local connectivity technology: devices talk to each other inside the home, and control from outside it needs an internet-connected controller such as a hub or smart speaker. The Alliance also publishes a directory of certified products. Treat all of that as the general picture, and check each product's own page for what it supports.

The AI's job with this table is formatting and plain-English description: turning your rough list into rows, drafting the one-line explanation a client sees ("a switch that dims the lights and can be controlled from a phone"), and flagging any column you left blank. Its job is not to pick the model, to say which protocol a product uses, or to certify that two products work together. Those are facts on a datasheet, and an assistant that has not read that datasheet will still produce a fluent answer.

Eight compatibility checks AI cannot do for you

Run these on every line of the device list before the proposal goes out. None needs special software, only the datasheets and a survey notebook, but each one has sunk a job somewhere.

1. Protocol and controller. Does every device talk to a controller you are supplying, directly or through a bridge? Write the answer in the "connects by" column rather than in your head.
2. Border routers. If devices use Thread, is there at least one border router, and is it somewhere with a wired connection? Extra border routers add resilience, so decide whether the proposal includes one.
3. Neutral wire and box depth. Many smart switches and dimmers need a neutral wire at the switch box, and some need a deeper box. Note it per location, not per house, as the example's hall and landing show.
4. Lamp load. A dimmer's datasheet gives minimum and maximum load and the lamp types it supports. LED lamps are the usual trouble, so list the lamp types in each room.
5. Network capacity. Count the Wi-Fi devices against what the router and access points are meant to carry, and say whether devices sit on the client's main network or a separate one.
6. Cloud dependence. For each device, note which features need the maker's service or an account, and what keeps working if the internet drops.
7. Firmware and certification. Check the version you will install supports the feature you are promising, and look the product up in the certification directory if you are claiming Matter support.
8. Who does regulated work. Anything touching boiler controls, mains circuits or the consumer unit is done by suitably qualified people. The proposal says who, and by when.

A realistic slip shows why these checks stay with you. Say the draft for the example house contains the sentence "all devices continue to work if the internet goes down". It reads well and is true for some devices and false for others. In the example house, the wall buttons and the schedules held on the controller should carry on, but the doorbell's phone notifications and remote viewing need the internet. The fix is to replace the sentence with a short table of what works locally and what needs a connection, filled in from the datasheets.

You can still use AI on this stage, as a checklist writer. Ask for questions, never answers, and keep the datasheets in front of you while you tick them off:

For each device in the list below, write the three facts I must confirm on its datasheet or the maker's page before it goes into a client proposal. Use my columns: connects by, needs from the house, supplied by. Do NOT state any of the facts yourself, and do not say whether any two devices are compatible. Output a table: Ref | Fact to confirm | Where to look (datasheet section, certification directory, maker's support page).

The output is a tick-sheet. A good one says things like "minimum and maximum load in watts, by lamp type" for the dimmers and "whether live view works without the maker's subscription" for the doorbell. You then spend your time confirming rather than remembering what to ask.

Exclusions that name the thing, not "networking not included"

Vague exclusions protect nobody. A client reading "networking not included" cannot tell whether the access points in the device list are covered, and in a dispute a vague line tends to be read against the person who wrote it. Specific exclusions cost you ten minutes and save an argument. Six examples follow, each shown before and after.

Notice the square brackets in the third row. When you ask an AI to turn vague lines into specific ones, tell it to put anything it had to assume in square brackets, so that you can see what still needs a fact. A draft with no brackets in it has hidden its assumptions rather than made none.

Support terms, clause by clause, with wording to adapt

Support terms are where AI drafts do the most damage, because the natural thing for an assistant to write is generous and reassuring: "we will respond to any issue promptly", "ongoing support". Both are promises, and neither has a number. Good terms have limits you can keep and figures you chose. A home automation proposal needs eight clauses.

1. Included support period, and what happens after it.
2. Response windows by severity. Response, not repair.
3. Support versus change. What is free and what is quoted.
4. Updates and firmware. Who applies them, and when.
5. Cloud services, accounts and subscriptions. Who owns the accounts and who pays.
6. Remote access. How you connect, and only with the client's consent.
7. Client responsibilities. Keeping the router on, telling you before changing it.
8. End of support. What happens when a maker withdraws a product or its service.

Wording for three of them follows, in plain English, with square brackets where you set the number. These are examples to adapt, and a solicitor should read your standard version once.

Included support. For [90] days after handover we answer questions and fix faults in the equipment and set-up we installed, at no charge. After that, support is available on a monthly plan or at our standard hourly rate.

Response, not repair. The times below are the time to a first reply from a person, not a time to fix. Where a fault needs a part or a visit, we will agree a date with you.

Changes. Adding a scene, moving a button or connecting a new device is a change, not support, and is quoted separately.

A severity table makes the response windows concrete. The numbers below are placeholders that show the shape. Set windows you can keep with your real diary, because a window you miss twice is worse than a longer one you meet.

When you ask the AI to draft this section, give it your approved standard terms and the numbers above, and tell it to use only those, to put [CHECK] after anything it assumed, and not to add any promise that is not in your text. Then count the [CHECK] markers. Each one is a decision you had not made, and finding it in a draft costs less than finding it in a dispute. Every proposal that goes out should use the same approved clauses with different numbers, rather than newly invented legal wording each time.

There are two clauses worth a second look. Cloud services need the most thought because a device that relies on its maker's service can lose features if that service changes. Say which devices are affected, and say that you do not control the maker. End of support needs similar candour: you can promise to tell the client when a maker announces a withdrawal, and to quote a replacement, but you cannot promise the product will work for ever.

One prompt that drafts the whole proposal from your notes

After you have done each part by hand once, you can chain them into one instruction. Keep the output in separate sections so you can review each one, and keep the facts in your hands.

You are helping a home automation installer write a client proposal. Use ONLY the material below. Where something is missing, write [CHECK] and a short question instead of guessing.

MATERIAL: (1) my site-visit notes, (2) the agreed discovery summary, (3) my device list with model numbers and datasheet notes, (4) my standard support terms and response windows, (5) my standard exclusions.

Write these sections, each under its own heading:
A. Discovery summary (client's words, then facts found, then not yet decided).
B. Scope by area: a table with What the household can do / Included work / Depends on. Outcomes must be testable at handover.
C. Device list: Ref / Device / Qty / Connects by / Needs from the house / Supplied by. Do not change my models or protocols.
D. Exclusions, each naming the specific thing excluded.
E. Support terms, using my wording and numbers only.
F. A list of every assumption you made about the client's existing equipment, each with the sentence it appears in.

Rules: plain English, no marketing language, no claims about compatibility, security or reliability that are not in my material, no promises of response or repair times beyond those in my terms.

Strip personal details before you paste anything in. Use "the client" or a first name, and leave out the address, door and alarm codes and Wi-Fi passwords, which a proposal never needs. Use a business or team plan where the vendor says content is not used for training by default (ChatGPT Business and Claude Team both say so), or switch off the training setting on a personal plan. Setting labels change, so check yours rather than trusting a screenshot.

A second pass that finds gaps between scope and device list

The most useful AI check on a finished proposal is a different instruction on the same document: compare the sections and report mismatches, without fixing anything. Paste the scope table, the device list and the exclusions, and ask for four lists: devices tied to no room or outcome, outcomes with no device, every assumption about the client's existing equipment (with the sentence it appears in and whether the notes support it), and numbers that differ between sections. The result for the example house might read like this (illustrative).

Five findings from one pass, and the first one alone would have put a false statement in front of the client. This is the point where an AI is more useful as a reviewer than as a writer, because it is good at holding two tables in view at once and weak at knowing what is true of your equipment. Run the pass again after you make the fixes, since edits create new mismatches.

A quick sum: where the hours go with and without a draft

Do not expect AI to shrink every part. The writing parts shrink, and the checking part does not. An illustrative comparison for one proposal of this size follows, in hours, with a note on why each line moves or stays put. Time your own next two proposals rather than relying on these numbers.

At a blended $60 an hour (an illustrative rate), 3.7 hours is $222 of time per proposal. The more useful number is the one that does not appear in the table: the cost of one wrong device or one loose exclusion on a job. A free return visit to swap a dimmer, with the drive and the call-back, usually costs more than the time the drafting saved.

If you quote for commercial work too, the same habits carry over to bids; the home automation tenders tutorial shows how to build a requirement matrix and compliance table for those. For the wording of scope and exclusions in neighbouring trades, see the AV proposal scope tutorial and the electrical proposal tutorial. For the checking habit that catches invented figures, see how to catch made-up figures in AI-drafted proposals.

Two last jobs sit outside the document. Plan the cabling honestly: if the proposal needs runs to the loft or between floors, the data cabling quote tutorial covers counting drops and runs. And agree the service level in numbers, not adjectives: the service level agreement tutorial goes through response times and remedies in more detail than a proposal section can.

Questions installers ask about AI-drafted proposals

Should AI choose the devices for a proposal?

No. Let it format and describe the devices you have chosen, but pick the models yourself from datasheets and your own stock list. AI does not know which firmware a product ships with, which hub the client already owns, or whether a dimmer suits the lamps in the house. A wrong device in a proposal becomes a free site visit later.

Can AI write the warranty clause?

It can restate wording you have already approved, but it should not invent warranty terms. Your workmanship warranty is your own promise, and product warranties come from the manufacturers. Have a solicitor review your standard terms once, then let AI adapt the project-specific parts from that approved text rather than writing legal terms from scratch.

What if the client wants to supply some devices?

List them in the device list marked as client-supplied, check each against the rest of the system, and state that you give no warranty or support commitment on them beyond connecting what you listed. Without that line, a faulty client-supplied sensor becomes your problem the first time the lights misbehave.

How long should a home automation proposal be?

Long enough that a client can read the exclusions and support terms in five minutes. A one-page discovery summary, a scope table, a device list, a short exclusions list and the support terms usually do it. If a section needs paragraphs of explanation, the underlying scope is probably still unclear.

Further reads

• CCTV Maintenance Contract: Remote Health Checks and Renewals With AI — Support-plan wording and renewals for a related installed system.
• Alarm Installer Quote Template: Zones, Detectors and Monitoring With AI — Zone-by-zone scope wording from a neighbouring trade.
• AI Proposal Mistakes That Cost You the Job — The proposal errors that lose jobs, and how to spot them.
• How to Mention AI Use in Client Contracts and Proposals — How to mention your use of AI in proposals and contracts.
• How to Write Business Proposals Faster With AI — General proposal drafting steps for the sections not covered here.
• CCTV Installation Quote Template: A Worked AI-Drafted Walk-Round Quote — A worked walk-round quote for camera systems.
• AV Installation Checklist: Commissioning Tests and Punch List With AI — A grouped AV commissioning checklist with the tests to record, then AI steps for a room test sheet, a punch list from walkthrough notes and the sign-off page.
• AV Scope of Work: Draft It From Discovery Notes With AI — Number the discovery notes, let AI sort them into a requirements record, draft scope lines from confirmed items, then have the designer check the design.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Connectivity Standards Alliance Matter page and Matter FAQ; OpenThread Border Router guide; Thread Group overview; OpenAI and Anthropic business-plan data-use pages.