Solar Operations SOPs: Build Workflows That Don’t Depend on One Person

If one experienced employee has to be available for the process to work, the company does not fully own the process yet.

That problem shows up everywhere in solar operations. One person knows how a certain AHJ likes a correction packet. Another remembers which utility step usually comes after inspection. A project manager knows what “install-ready” really means, but the scheduler only sees a date. A field lead knows which photos finance will ask for later, but that knowledge is never written down.

Standard operating procedures, or SOPs, turn that hidden know-how into a repeatable operating method. The goal is not to create a giant policy manual. The goal is to make routine work understandable enough that another trained person can perform it correctly, know when to stop, and know when an exception needs someone more experienced.

For solar companies, the highest-value SOPs usually sit around the places where work is repeated across many projects: survey, design intake, permitting, correction handling, install readiness, field evidence, inspection, interconnection, PTO, billing handoff, customer updates, and closeout.

What does “tribal knowledge” mean in solar operations?

Tribal knowledge is simply undocumented operating knowledge that exists mainly in people’s heads, inboxes, personal notes, chat history, or habits. A clearer phrase for most teams is key-person knowledge.

The knowledge itself is not bad. Experienced employees should know things that new employees do not. The risk appears when the business cannot separate the person’s expertise from the normal process.

For example, a strong permit coordinator may know that a particular jurisdiction commonly asks for one additional document. That experience is valuable. But if every other coordinator has to message that person before submitting a project, the company has created a dependency.

A good SOP captures the repeatable part of that knowledge while leaving room for judgment when the project falls outside the normal path.

Why does solar create so much key-person dependency?

Solar projects cross several functions before they are fully closed. Sales, survey, design, engineering, permitting, procurement, field operations, inspection, interconnection, finance, and service may all touch the same project.

At the same time, many external requirements vary by jurisdiction, utility, project type, equipment, and site condition. The Department of Energy notes that local governments use different permitting and inspection requirements, and that administrative errors and backlogs can contribute to delays.

That combination creates a natural temptation to run the company through experienced people rather than through repeatable operating rules. It works at low volume because the right person can answer every question. It becomes fragile as project count, branches, crews, and new hires increase.

The problem is not that every AHJ or utility needs exactly the same SOP. The better design is to standardize the company’s own method for handling variation: where requirements are stored, who verifies them, what evidence is required, how exceptions are recorded, and what happens when a rule changes.

An SOP is not the same as a checklist, policy, or automation

Solar teams often use these words interchangeably, but each one has a different job.

This distinction matters because a company can write a perfect checklist and still have no clear process for what happens when an item fails. It can also automate a task before the team has agreed on the SOP behind it.

The SOP should define the normal path and the exception path. The checklist proves that a specific gate was satisfied. Automation can then carry the predictable parts of that procedure.

Which solar processes should you document first?

Do not begin by documenting every process in the company. Start where inconsistency is already costing time, creating rework, slowing onboarding, or making one person impossible to replace.

A simple priority test uses four questions: How often does the process happen? What happens when it is done incorrectly? How much does the method vary between employees? How dependent is the company on one or two people to make it work?

If a workflow is rare, low-risk, and already handled consistently, it can wait. The SOP program should begin where repeatability has the highest operational value.

What should a useful solar SOP contain?

An SOP should be short enough to use while work is happening but complete enough that a trained employee can follow the normal process without asking the author to translate it.

A practical Solar Operations SOP can use nine fields.

1. Purpose and scope. State what process the SOP controls and where it starts and ends.
2. Trigger. Define the exact event that starts the process.
3. Owner and backup role. Identify who owns the process and which role can perform it when the normal owner is unavailable.
4. Required inputs. List the data, approvals, files, site information, or prior milestones required before work begins.
5. Normal steps. Describe the shortest repeatable path for the majority of projects.
6. Decision points. Show where the employee must choose between defined paths.
7. Evidence and exit criteria. Define what proves the work is complete enough to move forward.
8. Exception and escalation path. Explain what to do when the normal procedure cannot be completed safely or correctly.
9. Version owner and review trigger. Record who maintains the SOP and which business changes require it to be reviewed.

The Department of Energy’s operational-control guidance uses a similar principle in another operational context: procedures, work instructions, checklists, and other controls should make the operating criteria clear and accurate to the responsible people. The exact format matters less than whether the right person can apply the correct rule at the moment of work.

Do not write the SOP from memory in a conference room

The fastest way to create a useless SOP is to ask a manager to describe the process from memory and then turn that description into a polished document.

The real process is usually different. Employees take shortcuts. External portals fail. A project arrives missing information. A correction affects equipment. An inspector asks for something unusual. The experienced person often handles these exceptions automatically and forgets to mention them when describing the normal workflow.

A stronger capture process is: watch the work, ask the employee to narrate why each decision is being made, record the exceptions that appear, draft the SOP, then have another trained employee run the process using the draft without coaching.

If the second employee still needs to ask the expert what the document means, the SOP has not captured enough of the process.

Example: a permit correction SOP

A weak SOP might say: “Review correction, update plans, and resubmit.” That describes the topic, but it does not control the work.

A stronger permit-correction SOP starts when the AHJ response is received and attached to the project. The permit owner classifies the correction, identifies every affected document, checks whether the comment changes equipment, engineering, customer scope, interconnection information, or schedule, and routes each required response to the right owner.

The SOP then defines what must be reviewed before resubmission, which revisions belong in the new packet, who can release the packet, how submission is confirmed, and what next follow-up is created.

The important part is the exception rule. If the correction changes a material technical or commercial assumption, the procedure stops being a simple permit task. It becomes a cross-functional decision that needs the appropriate design, engineering, procurement, operations, finance, or customer owner.

This keeps the SOP from pretending every correction is the same while still making the normal path repeatable.

Example: an install-readiness SOP

Install readiness is another place where tribal knowledge can hide. One scheduler may treat permit approval as ready. Another checks equipment allocation. A third knows that site access, current plans, customer confirmation, and an unresolved field issue also matter.

The SOP should convert that experience into explicit readiness conditions. The company defines the normal gate for its project types, then identifies which conditions can be verified automatically, which require evidence, and which exceptions need an authorized override.

The scheduler should not need to know every story behind every project. The procedure should tell the scheduler whether the job is ready, what remains open, and who can resolve an exception.

Safety and technical judgment should not be reduced to a generic SOP

SOPs are useful operating tools, but they do not replace training, licensing, engineering judgment, manufacturer instructions, applicable codes, or legally required safety programs.

OSHA identifies serious solar-work hazards including falls, electrical shock, arc flash, lifting, heat, and other construction risks. It also notes that employers may be required to implement safe work practices and worker training requirements that apply to the work being performed.

That means an operations SOP can say who must verify that required safety controls, qualifications, permits, equipment, or training are in place. It should not invent a simplified technical procedure that overrides the actual safety or electrical requirements.

A good SOP makes the boundary visible: follow the standard path when the conditions match; stop and escalate when they do not.

The best SOP is used inside the workflow, not stored in a folder

Many companies already have SOPs. The problem is that the SOP lives in a PDF, wiki, or shared drive while the actual work happens somewhere else.

A permit coordinator should not need to leave the permit workflow, search for “Permit SOP Final 2026,” read five pages, and then return to the project. The important instructions, required inputs, checklist, decision points, and escalation path should appear where the work is being performed.

This does not mean turning every sentence into software. It means moving the procedure closer to the task.

A system can require the right fields before permit submission, show the current AHJ requirement source, create the correction task, require field evidence before completion, or block an install-ready state when a required condition is missing. The SOP remains the operating logic; the software helps employees follow it consistently.

Standardization works best when exceptions stay visible

The purpose of an SOP is not to make every project identical. Solar projects are not identical.

A useful SOP standardizes how the team handles the normal case and how it recognizes that the normal case no longer applies. That second part is what keeps standardization from becoming rigid bureaucracy.

For permitting, the exception might be a correction that changes the electrical design. For procurement, it might be a proposed equipment substitution. For the field, it might be an unsafe or materially different site condition. For finance, it might be a change order or disputed billing condition.

The SOP should not tell an employee to guess. It should identify the exception, capture the evidence, route it to the right role, and prevent the project from silently continuing on a bad assumption.

Use process owners, not document owners only

Every important SOP needs a process owner who is accountable for whether the procedure still works in real operations.

That person does not need to perform every instance of the process. Their job is to monitor recurring exceptions, update the procedure when the operating reality changes, and make sure the SOP still matches the systems, roles, AHJ requirements, utility processes, equipment, and business rules it depends on.

The experienced employee who originally taught the process can be a subject-matter expert without becoming the permanent bottleneck for every decision.

Review SOPs when the process changes, not only when the calendar says so

A stale SOP can be worse than no SOP because employees may trust it.

Instead of relying only on a quarterly or annual review date, define change triggers that force review. Examples include a new AHJ requirement, utility process change, new equipment family, changed software workflow, new contract rule, repeated field failure, new branch, new project type, or an exception that appears often enough to become part of the normal process.

The document should show the current version, process owner, effective date, and what materially changed. Employees should not be expected to compare two long SOP documents line by line to understand a revision.

Can standardization really improve solar operations?

Standardization by itself does not guarantee faster projects. A bad standardized process is still bad. But well-defined inputs, rules, ownership, and exception paths can remove avoidable variation.

NREL’s O&M best-practices guide makes a similar point for installed PV assets: a more standardized approach to planning and delivering O&M has the potential to reduce costs and make those costs more predictable. The article you are reading applies the operating principle to installer back-office and project-delivery work rather than claiming that the same O&M result automatically applies to every installation company.

SolarAPP+ provides another useful example of what structured rules and inputs can do in a narrow solar workflow. In 2024, 861 installers submitted 37,393 permits through SolarAPP+, and the 2026 performance review found that a typical participating project was permitted and inspected 12 business days sooner than projects using traditional processes.

Those are SolarAPP+ results, not SOP results and not Solar1 results. The relevant lesson is that structured, repeatable operating rules can remove avoidable manual interpretation when the workflow is well defined.

How do you measure whether SOPs are creating value?

Do not measure success by the number of SOPs written. Fifty documents nobody uses are not an operating system.

Measure what changed in the work. Useful internal metrics include first-pass completion, correction or rework rate, time from trigger to completion, recurring exception reasons, number of questions escalated to the process expert, onboarding time to independent execution, SOP bypass rate, and the percentage of active SOPs that have a named owner and current review status.

An illustrative key-person interruption example

Suppose one experienced operations manager gets six process questions per day from the team. If each interruption takes about eight minutes to understand the project, answer the question, and return to their own work, that is 48 minutes per day.

48 minutes × 5 days = 240 minutes, or 4 hours per week.

Across 50 working weeks, that would be about 200 hours of experienced-management time. This is an illustrative scenario, not an industry benchmark. SOPs will not eliminate every question, and many escalations are valuable. The useful target is the repeated question that already has a repeatable answer.

A practical 30-day SOP rollout

A small installer does not need a six-month documentation project. Start with a narrow operating test.

1. Week 1: Identify the three workflows causing the most repeated questions, rework, or key-person dependence.
2. Week 2: Observe the real work, record the normal path and exceptions, and draft the SOP with the employee who actually performs the process.
3. Week 3: Have another trained employee execute the process using the SOP. Capture every point where the document is unclear, missing a condition, or requires hidden knowledge.
4. Week 4: Move the checklist, evidence requirements, and escalation points into the actual workflow where possible, then measure questions, rework, and exceptions.

Once those procedures work, move to the next few processes. The company builds an SOP library from proven workflows instead of trying to document the entire organization before anyone gets value.

How is Solar1 being designed around repeatable work?

Solar1 is being built as a complete solar-specific ERP for installers and EPC companies. Its product direction includes turning repeatable operating rules into project templates, stage gates, role ownership, required evidence, checklists, approvals, exception queues, and workflow events across sales, survey, design, permitting, interconnection, procurement, inventory, field operations, finance, PTO, service, and warranty.

The goal is not to replace experienced employees with rigid software. It is to make the normal process visible enough that teams can execute consistently, while unusual technical, safety, commercial, or customer situations are routed to the people qualified to decide them.

A permit workflow, for example, can carry the required inputs, ownership, evidence, correction path, and follow-up logic instead of relying on one coordinator to remember every step. An install-readiness workflow can show exactly which conditions are still open. A field checklist can capture proof at the point of work. A billing handoff can require the evidence finance needs before the milestone becomes invoice-ready.

Solar1 is still under development. This describes the operating model the product is being designed around and does not mean every SOP template, embedded instruction, stage gate, approval, training, or workflow-control feature described here is currently production-ready.

The goal is not more documentation. It is less dependence on memory.

A solar company should not need its best project manager in every meeting, its best permit coordinator in every submission, or its most experienced field lead on every job just to make routine work happen correctly.

Capture the repeatable part of their knowledge. Define the trigger, inputs, normal steps, decision points, evidence, and exception path. Put those rules close to the work. Then use experienced people where experience actually matters: exceptions, improvement, judgment, and coaching.

A strong SOP does not make people less important. It stops wasting their expertise on questions the company should already know how to answer.

Use the Solar Operations SOP Template to document one high-friction workflow and test whether another trained employee can run it without depending on the person who wrote it.