8 Solar Processes to Fix Before a Second Branch

Illustrative operating risk, not a measured company case: A first branch can depend on unwritten knowledge. A veteran designer knows which surveyor’s notes need a follow-up. The sales manager recognizes a risky promise by tone. Operations knows which utility form changed. Open a second branch and those private shortcuts stop looking like experience. They become two versions of the company.

Standardization before expansion is therefore an exercise in decision control. The second office does not need a binder describing every click. It needs a shared answer to harder questions: What work may start? Which evidence controls release? Who can commit price or scope? What happens when a local condition does not fit the default?

The U.S. Small Business Administration’s location-expansion guidance asks businesses to update the marketing plan, confirm financial readiness, consider laws and taxes, and evaluate the new market. Those are company decisions, not proof that a particular solar territory will succeed. This guide stays inside the operating layer that makes those decisions executable.

It is written for founders, operations leaders, and branch managers preparing a residential or commercial solar expansion. It does not replace local legal, tax, employment, safety, engineering, authority, utility, insurance, or contractual review.

Standardize controls, then document local variation

Photocopying the first branch is a fragile expansion method. The original team may have built its process around one utility, one permitting office, familiar roof types, a known supplier, and people who fill gaps through conversation. A different territory can change each condition. The control should remain consistent while the method adapts.

Use four parts for every company process:

This distinction stops headquarters from confusing sameness with control. Requiring the same file name in every territory may add little. Requiring every released design to identify its source imagery, site evidence, equipment basis, and reviewer protects a meaningful boundary.

Map current work before writing policy. Follow several ordinary projects and at least a few awkward ones from lead through handoff. Record where a person interprets an unwritten rule, where a document is copied, where approval happens in a private message, and where a local office will need different knowledge. Those observations become the expansion backlog.

Process 1: market-entry and service-scope approval

A branch should not learn its service boundary one sale at a time. Before marketing begins, leaders need a written market hypothesis and a gate for changing it. Define the customer segments, project types, geography, delivery model, partners, exclusions, and evidence used to approve the launch.

Separate commercial appetite from delivery authority. A salesperson may find demand for a roof or financing structure the first branch has never handled. Interest does not add competence. The branch needs a route to determine whether the company can survey, design, price, contract, permit, procure, install, and support that work under the relevant local requirements.

Build a service matrix. Each row names a project type and the conditions under which the branch may qualify it. Columns can include customer segment, system range, roof or site category, electrical scope, storage involvement, financing route, authority/utility readiness, partner dependency, and required specialist review. Label any unverified market assumption with an owner and expiry date.

For a U.S. expansion, SBA advises checking licensing, permit and zoning requirements in the new location and confirming whether existing permissions apply. A company launch decision cannot carry a license or utility approval from one territory into another. Record the actual local source and responsible reviewer.

The gate should produce one of four outcomes: approved, approved with a stated limit, pilot under additional review, or outside current scope. Avoid a vague “management approval” status. A future reviewer should be able to see which evidence supported the decision and what would trigger reconsideration.

Process 2: qualification and customer commitment

Qualification has to mean the same thing in both branches. If one office calls any scheduled homeowner qualified while another requires decision access and suitable project evidence, shared pipeline numbers describe different realities. Define qualification through observable conditions rather than rep confidence.

The conditions should fit the business model. A residential team may record confirmed property, customer objective, decision participants, relevant consumption evidence, site constraints known so far, finance interest, and the next agreed event. A commercial team may add tenancy, procurement path, facility stakeholders, interval-data status, site portfolio, budget cycle, and internal approval needs.

Standardize customer commitments with equal care. Reps need approved language for preliminary layouts, production scenarios, timing discussions, surveys, pricing validity, and authority-dependent work. The wording should name what is known and what remains subject to review. A branch manager should see exceptions early, before a confident conversation becomes an impossible delivery promise.

The DOE homeowner guide to going solar covers consumer questions across suitability, costs, agreements, and contractor selection. Use it as general consumer context. It does not supply a contract term, site conclusion, or state-specific requirement for a live customer.

Train qualification with cases, not slides. Give both branches the same borderline enquiries and compare their disposition. Discuss why an item is accepted, returned, escalated, or declined. The disagreements reveal hidden criteria faster than another policy paragraph.

Process 3: project intake and site-evidence custody

Every project entering design should carry an identifiable purpose, source material, assumptions, and open questions. Without that discipline, the new branch sends fragments to the established design team, receives a request for clarification, and blames distance for a problem caused by intake.

Create acceptance rules for each deliverable. A sales concept, survey plan, preliminary layout, proposal, engineering review, and construction package require different evidence. The intake owner checks completeness for the requested purpose and returns one precise list when the package is deficient.

Evidence custody deserves an explicit rule. Record who supplied each bill, drawing, photo, measurement, equipment file, authority note, or utility message; when it was received; which site it belongs to; and whether a later item superseded it. Avoid downloading attachments into private folders that the other branch cannot inspect.

The branch also needs a privacy and access policy appropriate to the records it handles. Restrict customer and project data to people with a business need, follow applicable retention rules, and involve qualified counsel for jurisdictional requirements. Operational convenience does not justify indiscriminate access.

Use the solar project intake process as the detailed handoff model. The branch version should add local evidence requirements without changing the shared labels for confirmed input, planning assumption, and item required before release.

Process 4: design review, release, and revision control

Design work spreads quietly across locations. One branch may prepare early roof models while a central team handles electrical review. A contractor may produce a drawing. A salesperson may request a revision directly from a designer. Without one release process, the customer, permit coordinator, procurement team, and installer can each receive a different version.

Every design state needs an allowed purpose. “Draft” may support internal discussion but not customer delivery. “Preliminary” may support a qualified conversation but not procurement or construction. “Released for engineering review” should identify the responsible reviewer and open conditions. Labels need definitions that both branches teach and enforce.

The review record should connect layout, equipment, energy model, bill of materials, electrical representation, and proposal where those outputs apply. A module-count change cannot end at the drawing if the proposal and procurement record still use the previous quantity. A changed inverter selection can affect several downstream documents.

Solar Designing describes SurgePV’s approved scope across 3D roof modeling, array layout, shading analysis, energy-yield modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Revision requests should identify what changed, why, which released version is affected, who requested it, and which outputs need reconsideration. Do not accept “customer wants an update” as a complete instruction. The branch receiving the request owns clarification before design work begins.

Process 5: pricing authority and contract change

Price variation between branches can be legitimate. Labor, travel, permits, engineering, equipment availability, partner costs, and commercial terms differ. Hidden variation is the problem. Standardize how cost inputs enter a quote, who may approve margins or discounts, and when a quote expires or returns for review.

Build the price record around source and authority. Equipment and subcontract inputs should carry a date and supplier basis. Labor assumptions should identify the branch or crew basis. Allowances should state what they cover. The customer-facing quote should distinguish included scope, optional scope, exclusions, dependencies, taxes where applicable, and terms that require confirmation.

Do not let a salesperson solve a design change by editing price only. More modules, a different service condition, a battery option, revised structural work, or a new trench route can affect design, procurement, installation, and contract scope. Route the change through the roles that control those outputs.

Use an approval table based on decision type rather than job title alone. A branch manager may approve a defined commercial discount but cannot waive an engineering review. A technical leader may accept a design method but cannot change customer payment terms. Where local law or licensing defines authority, the local requirement controls.

The DOE solar soft-cost overview identifies multiple nonhardware categories around a project. It supports examining more than equipment cost. It does not establish a correct margin, price, or staffing allowance for either branch.

Process 6: permitting, interconnection, and authority ownership

The second branch needs named owners for local authority and utility knowledge before its pipeline fills. A copied checklist from the first territory can be worse than no checklist because it looks finished. Record each jurisdiction, responsible authority, utility, application route, current forms, submission owner, inspection steps, and last verification date.

Code references need edition and adoption context. The NFPA page for NFPA 70 is an official source for the National Electrical Code development record, but an official national standard page does not prove which edition or amendment a local jurisdiction applies. Confirm adoption and interpretation with the relevant authority and qualified professional.

Separate knowledge from approval. A branch coordinator can maintain the source register and confirm that required files are present. The responsible designer, engineer, electrician, authority, or utility makes decisions within their role. Software should not convert a populated field into a claim of code compliance or permit readiness.

Track returns by stated reason and source. A rejected submission may reflect a missing document, a design issue, a naming mismatch, a changed form, or an authority-specific interpretation. Those categories lead to different corrections. “Permit delay” tells management almost nothing.

The solar permit package checklist provides a deeper document-control framework. Adapt its source and review fields locally, then keep the company release definition consistent across branches.

Process 7: procurement and installation handoff

Procurement should receive a released basis, not a screenshot from the sales conversation. Standardize the handoff from design and contract to purchasing, delivery, field planning, and installation. The package needs current quantities, approved equipment, substitutions status, delivery site, storage needs, schedule dependencies, and unresolved conditions.

Substitution control is the difficult part. A locally available module or inverter may appear equivalent in a purchasing view while affecting layout, stringing, electrical documentation, structural assumptions, energy modeling, proposal language, warranty handling, or authority records. The requester should state why the substitution is proposed and route it through every affected owner.

Installation handoff also includes site access, customer communication, crew competence, task planning, and safety responsibilities. The Occupational Safety and Health Administration’s employer-responsibilities page summarizes U.S. federal employer duties such as providing a workplace free from serious recognized hazards and complying with applicable standards. Branch leaders need current location-specific professional guidance and a functioning safety program, not a paragraph copied into an operations manual.

Create a hold process anyone can use without fear. If the field condition conflicts with the released package, the crew records the condition, protects the site, and escalates through a named route. Production pressure must not turn a stop-and-review decision into an unofficial field redesign.

Process 8: branch review, exceptions, and learning

Headquarters needs a shared review system before the new office opens. Otherwise, the first management meeting becomes a debate over whose spreadsheet is correct. Define a small set of operating questions and the records that answer them.

Review queue age, returns, release exceptions, revision causes, customer commitments at risk, safety escalations, authority feedback, procurement substitutions, and work waiting for a named decision. Counts require a denominator and stable definition when used for comparison. A raw return total is meaningless if one branch handles a different volume or project mix.

Do not turn branch review into a performance theater. The purpose is to see where the process fails and decide whether the response is coaching, capacity, a local variation, a company-rule change, or a narrower service scope. Invite the local owner to explain mechanism and context before assigning blame.

Create an exception register with the default rule, observed condition, temporary decision, approving role, affected projects, expiry, and proposed permanent resolution. Some exceptions expose a bad local practice. Others reveal that headquarters wrote a rule around conditions unique to the first branch.

The DOE solar workforce development material treats training and employer needs as connected. Use role qualification and recurring instruction as part of branch review. Do not assume a process is standardized because staff attended the same launch meeting.

What should a second-branch launch record contain?

A second-branch launch record should contain approved services, market and customer boundaries, required roles, customer promises, qualification rules, evidence custody, design and commercial release routes, pricing authority, permitting and interconnection ownership, procurement and installation handoffs, exception queues, shared-system access, continuity plans, blocking conditions, and post-launch review triggers. The final launch decision must remain fully inspectable after the office begins operating.

The record is the branch’s acceptance packet. It records the evidence from tests of qualification, delivery, review, handoff and support. A completed packet does not itself prove competence or permission to operate. A launch date and staffed office do not establish that operating state.

Treat an unknown as a status, not a blank. Some questions may be resolved during a bounded pilot, while others block customer commitments. The launch owner should state which work may proceed and which remains prohibited until the appropriate evidence or professional review exists.

How should local variation be documented?

Document local branch variation with the central rule affected, local evidence, jurisdiction or operating context, proposed change, reviewer, permitted scope, effective date, current-work impact, and retirement trigger. A local exception should not silently become company policy, and a central rule should not override verified local requirements merely for reporting consistency. The record keeps local evidence separate from mere company preference.

Start with the shared company control. Ask what fact prevents the branch from using the normal path. Supplier availability, workforce coverage, customer process, property practice, authority requirements, or another local condition may change how work is performed. The appropriate qualified reviewer determines what the evidence requires.

1. Name the central process and exact decision affected.
2. Attach the local source and observation date.
3. State whether the condition is legal, technical, commercial, operational, or still unknown.
4. Propose a bounded local treatment.
5. Assign the reviewer and permitted release.
6. Identify current projects and shared outputs affected.
7. Set the review or retirement trigger.

Use this copy-ready variation record:

Branch and market:
Central rule affected:
Local evidence:
Decision required:
Proposed treatment:
Reviewer and authority:
Permitted projects and release levels:
Shared systems or templates affected:
Current work requiring reconciliation:
Effective date:
Review or retirement trigger:

Do not label a preference as a requirement. “The branch has always done it this way” is useful discovery, not evidence that the company standard must change. Conversely, headquarters should not dismiss a verified local condition because it complicates the template. The record separates the source from the treatment so both can be challenged.

How should the company test branch readiness?

Test second-branch readiness with representative qualification, intake, design review, pricing, external-path, procurement, installation-handoff, exception, customer-update, and continuity scenarios. The branch passes only when the receiving roles can use the shared evidence, apply local variation correctly, and route unresolved decisions without recurring private rescue from the first office. Every unplanned rescue becomes a visible launch finding with a specific assigned owner.

Illustrative example, not a branch result: A new branch receives a commercial rooftop lead. The launch test requires the team to qualify the customer decision, preserve the electricity and site records, request a preliminary design release, apply local pricing authority, and route an external-path question to the assigned owner.

The intake reaches design with no source date for the roof imagery. The branch does not fail because it returned the work; the return shows that this missing-source test exercised the acceptance rule; it does not validate every rule or project. It fails if staff quietly choose an image, message a headquarters designer privately, or send a customer layout without the preliminary release boundary.

After correcting the intake, the branch completes the handoff and simulates the local manager’s absence. Another authorized owner can find the project, customer commitment, current revision, open condition, and next action. That continuity test is stronger evidence than a completed training attendance sheet.

Use the multi-location solar operating model after the second branch opens. That guide covers pooled capacity, cross-branch learning, and company-wide control; this checklist owns the narrower launch decision and acceptance packet.

Record every rescue during the test. Planned central specialist support is valid when it appears in the capacity and handoff design. Unplanned reconstruction is evidence that the branch process or readiness assumption is incomplete. Fix it before volume turns rescue into the normal operating model.

Run a first-week failure drill

The launch test should include conditions that ordinary opening-day enthusiasm tends to hide. Use controlled scenarios, not real customer disruption, and tell participants which actions are simulated. The purpose is to verify ownership and recovery paths.

Use a drill record with scenario, participants, expected route, actual route, rescue, decision, corrective owner, and retest date. A passed drill means the workflow produced a controlled outcome, not that every person remembered the ideal answer immediately.

Correct the underlying control before retesting. If the branch could not find the current revision, improve source-of-truth visibility. If the backup owner lacked permission, fix access and authority. If the intake allowed a missing field to appear complete, update the acceptance rule. A reminder email is not enough when the system still permits the same failure.

Keep launch limitations visible after opening. The branch may be approved for defined project types or preliminary releases while a specialist, service, or external path is still maturing. State the boundary in customer-facing and internal records. Expansion into another service becomes a new readiness decision, not an automatic consequence of the office being open.

Review the first live cases against the drill assumptions. Real work may expose different waits, customer questions, or local evidence. Update the launch record without erasing what the test originally covered. That history shows whether the branch expanded deliberately or drifted into new responsibilities.

Prove the process before opening day

A signed procedure does not prove that work can cross roles. Test the branch with scenarios and a small controlled project set where authorized. Include missing evidence, a customer revision, an authority-specific requirement, an equipment substitution, a schedule conflict, and a field condition that requires a hold.

Run each scenario through these steps:

1. Start from the real trigger and source documents.
2. Ask the branch owner to choose the permitted next state.
3. Transfer the work to the next role without verbal repair.
4. Introduce one realistic exception.
5. Check whether the correct person receives the decision.
6. Inspect what the customer and downstream team would see.
7. Update the rule only when the failure reveals a missing control.

Record whether the problem came from training, missing ownership, unsuitable software configuration, a weak acceptance rule, unavailable local expertise, or a faulty expansion assumption. Those remedies are not interchangeable.

Workforce planning should cover role competence and supervision, not merely seats. Define who may qualify projects, accept site evidence, release designs, approve prices, maintain authority knowledge, approve substitutions, lead field work, and close exceptions. Then identify deputies for absences. A process with one indispensable person is still a branch dependency.

Keep a single company record without erasing the branch

Shared systems should let leaders trace a project across branches while preserving the local facts that control it. Use common identifiers, decision statuses, release states, and document relationships. Add local fields only where a real authority, utility, market, partner, or operating condition requires them.

Avoid forcing every territory into free-text notes. Structured fields make current states visible, but notes still matter for unusual context. The balance is a shared decision vocabulary plus an attached evidence trail. Managers should be able to distinguish a local variation approved by the company from a habit no one has reviewed.

Solar proposal standardization before scaling goes deeper on one customer-facing output. A second-branch program should treat that proposal process as one node inside a wider chain, not the whole expansion system.

Frequently Asked Questions

Should both solar branches use exactly the same process?

Both branches should share decision definitions, evidence rules, release controls, and escalation paths. Local execution may differ because authorities, utilities, labor conditions, buildings, and customer expectations differ. Document each approved local variation beside the company control so adaptation stays visible instead of becoming an unofficial branch habit.

Which process should a solar company standardize first?

Start with the process whose failure can commit money or create customer risk before another reviewer notices. Pricing approval, design release, contract change, and safety escalation often meet that test. Sequence the rest by downstream impact, current variation, and whether the second branch already has a qualified owner.

Can software make two branches follow one workflow?

Software can hold required fields, versions, status changes, and approval records. It cannot decide whether local evidence is sufficient or whether an exception is acceptable. Configure the tool after leaders define ownership and review rules, then test it with real branch variations before treating the workflow as operational.

When is a second solar branch ready to open?

Readiness means the branch has an accountable leader, enough qualified local roles, approved market assumptions, working handoffs, current authority and utility knowledge, and a tested escalation route. It also requires financing, insurance, employment, tax, property, and legal review appropriate to the location and expansion plan.

How should headquarters review the new branch?

Headquarters should review exceptions, rework causes, overdue queues, release evidence, and customer commitments using shared definitions. The review should ask where the local process needs support or an approved variation. A league table built from unlike territories can encourage cosmetic reporting and conceal the operating issue management needs to see.

A second office should expose fewer unwritten rules

Expansion will reveal exceptions the first branch never saw. That is useful information if the company has a way to receive it. Keep company-wide release and authority boundaries firm. Let local people document where market conditions demand another method. Review the evidence before changing either one.

The best opening-day test is simple: can a new branch employee explain what they may decide, what evidence they need, who receives an exception, and which record the rest of the company will trust? If the answer depends on calling a founder, the process still lives in the first office.