AI Agents for Solar Installers: From First Lead to Service

AI agents for solar installers work best as a coordination layer across the four places a job lives: the lead inbox, the site survey notes, the permit file and the service log. The agent reads those records, drafts the next message or task, and flags what is stuck, while people keep decisions on design, pricing, safety and customer promises. The result is that each customer has one current story instead of four partial ones.

Key takeaways

• A solar job loses time at handoffs, not at installation. An agent layer is most useful where information moves from one person or tool to the next.
• Start with one role, such as a project coordinator assistant, and define the records it may read, the drafts it may write and the actions that always need a person.
• Every status the agent reports should carry a source and a date. A permit is approved only when there is a document that says so.
• Service history is the same record continued, not a separate system. What was installed, substituted and promised should still be findable years later.
• Measure the agent by something observable, such as how many open jobs have a current next step and an owner.

Where do solar jobs lose their thread?

Solar work crosses many hands over a long stretch. A homeowner or business makes an inquiry, someone qualifies it, a surveyor visits the roof or site, a designer prepares the layout, a quote goes out, a contract is signed, permits are filed, the utility reviews interconnection, a crew installs, an inspector signs off, and later the system needs monitoring and occasional service. Each step tends to have its own tool or inbox, and each handoff depends on someone remembering to write things down.

The failures are ordinary. A survey note says the main panel is crowded, but the quote was built from a phone call. A permit comment arrives by email to one coordinator who is on leave. A customer asks why nothing has happened and three people answer from three different memories. Years later a service technician arrives without knowing which inverter was substituted during procurement.

None of this needs a brilliant system. It needs one current record per job, kept honest by something that reads every source and does not lose track. That is a job an agent can do, provided its limits are written down in advance.

What is an agent layer for a solar company?

An agent layer is not a chatbot placed on a website. It is a defined worker with an identity, a memory of your jobs, access to specific tools and a list of things it may and may not do. The design questions are the same ones you would ask when hiring a coordinator.

For a solar company the layer usually has five parts:

• Identity: a clear role description, such as project coordination assistant, with the tone and wording your company uses with customers.
• Memory: a per-job record that holds the lead history, survey findings, design versions, quote terms, permit status, equipment installed and service events.
• Channels: the email inboxes, messaging tools and forms where customers, authorities and subcontractors actually write to you.
• Tools: read access to the CRM, the shared drive with survey photos, the permit tracker and the monitoring or ticketing system, plus narrow write access such as adding a note or creating a task.
• Permissions: a written boundary. For example, the agent may draft a customer update but a coordinator sends it, and the agent may never edit a quote or submit an application.

The discipline here matches the advice in Anthropic's guidance on building effective agents: use the simplest structure that works, give the agent clear tools, and add autonomy only where you can observe the results. The record is also worth designing carefully, because what the agent sees at the start of each task determines the quality of its output.

How should lead follow-up work without sounding automated?

Lead follow-up is the easiest place to begin, because the cost of silence is plain and the rules are easy to state. The agent should do the work that is slow and repetitive, and leave the relationship to your people.

In practice, a good follow-up routine looks like this:

• The agent reads each new inquiry and the history already on file, so it never asks a returning customer for facts they gave before.
• It drafts a first reply that answers what was asked, names the next step and asks only for what is missing, such as a recent utility bill, roof photos or the location of the main panel.
• It proposes a time for a call or survey based on the calendar it can see, and a person confirms.
• It writes a short summary into the job record: what the customer wants, what they are worried about and what is still unknown.
• If a lead goes quiet, it prepares a gentle follow-up on the schedule your team set, and stops when the customer says no.

The boundary matters more than the drafting. The agent does not quote prices, promise savings, describe incentive eligibility or state what a system will produce. Those statements belong to a person who has seen the site and knows the rules that apply. If you want a comparison with another field service business, the same pattern appears in AI for HVAC companies, where the website, answering and dispatch roles hand off to staff at defined points.

How do survey notes and permit status become shared memory?

Site survey notes are where the facts about a job first appear, and they are often the least structured. A surveyor may leave voice memos, a folder of photos and a few lines in a message. The agent can turn those into a consistent record, using a template your designers agree on.

A useful survey record includes roof type and condition, orientation and shading observations, main panel details, available space for equipment, access constraints, customer preferences and open questions. The agent fills each field from what the surveyor provided, marks fields it could not find as unknown rather than guessing, and compares the result with the quote. If the quote assumes a simple roof and the notes mention a second layer of material or a crowded panel, the agent raises that to the designer before the contract is signed.

Permit tracking follows the same logic. The agent watches the inbox and the places you check for permit and interconnection updates, and records what it finds in a fixed format:

• Application type and where it was submitted.
• Last known status, with the date and the source document or message.
• Any comments or corrections requested and who owns the reply.
• The next expected event and the date to check again.

The agent does not mark anything approved on the basis of an inference. If an email is ambiguous, it says so and asks a coordinator. When the check date passes without news, it drafts a status inquiry for a person to send. This keeps the customer-facing answer to the question of where things stand short and truthful.

One security point deserves attention. Emails and uploaded documents from outside your company are untrusted text, and they can contain instructions that look like commands. The agent should treat them as data to summarize, never as orders. The OWASP guidance on prompt injection prevention is a good checklist for this, and so is its authorization guidance: give the agent the narrowest access that lets it do the job.

What does service history change after the system is live?

Most solar companies treat commissioning as the end of a project, but for the customer it is the start of a long relationship with equipment on the roof. When the job record continues into service, every later question starts from a complete file instead of a search through old emails.

The agent can keep a service history that lists installed equipment with any substitutions, inspection and commissioning documents, warranty information as supplied by manufacturers, customer reports and technician visits. When a customer writes in about a monitoring alert or a drop in production, the agent finds the job, summarizes the equipment and previous events, and prepares a ticket with the facts a technician needs. Diagnosis and any statement about warranty coverage stay with your service team.

An illustrative scenario: a small installer receives an email from a customer whose monitoring app shows an inverter offline. The agent finds the job file, notes that the inverter model differs from the original design because of a supply change, and sees that the customer previously reported a loose conduit cover during the first visit. It drafts a reply acknowledging the report, creates a service task with the equipment details and earlier note attached, and places the draft in the coordinator's queue. The coordinator edits one sentence, sends it and books the visit. Nobody had to reconstruct the history from memory.

This is where a good record pays back over time, and the same idea appears in other field businesses, such as property management, where maintenance requests depend on knowing what was done before.

How do you start, and what does Be Human handle?

Begin narrow. A company that tries to automate every stage at once ends up with an agent nobody trusts. A single role with a clear success measure is easier to evaluate and to improve.

A practical plan:

• Choose one role, for example the coordinator assistant that keeps every open job current, and write down what a good day looks like for that person.
• List the sources it needs: the inbox, CRM, survey folder, permit tracker and service log. Confirm who owns each and whether read access is enough.
• Define the job record fields once, including source and date for every status.
• Write the approval boundaries: what the agent drafts, what a person sends, and what the agent never touches, such as pricing, design and submissions.
• Run it in review mode first, where every draft goes to a person, and note where the drafts need correction.
• Set one observable success criterion, such as every open job having a current next step, an owner and a dated status.
• Review weekly at first, then on a regular cycle, adjusting instructions and permissions based on what you saw.

Be Human designs, implements and operates this kind of agent infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and the success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, delivered remotely in English and Portuguese. For a closer look at quotes and service in this sector, see AI agents for solar installers: quotes, permits and service, and for the broader pattern of recurring work and reporting, see AI agents for operations teams.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent submit permit applications for a solar company? It can prepare a checklist and draft the cover message, but a person should review and submit anything that goes to an authority or utility. Applications carry legal and technical responsibility, so the approval boundary should sit there.

Will an agent replace my project coordinators? The aim is to remove the searching, copying and chasing that fills a coordinator's day, not the judgment. Coordinators keep customer relationships, decisions and exceptions, and they review what the agent drafts.

What data does the agent need to be useful? It needs read access to the places where job facts already live, such as the inbox, CRM, survey folder, permit tracker and service log. It works better when those records follow a consistent template, so defining the fields is often the most valuable early step.

How do I know the agent is staying accurate? Require a source and a date on every status it records, review a sample of its drafts regularly and track one agreed measure, such as jobs with a current next step and owner. When it makes an error, correct the instruction or the record format rather than only the single output.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.