The Solar Partner Enablement Checklist

Partnership announcements are easy. Joint customer work is where the nouns become verbs. Someone has to qualify the lead, explain what is being offered, collect bills and site data, request design, present assumptions, contract, schedule, install, answer complaints, and preserve the record. If those verbs have no owner, the customer discovers the gap.

Partner enablement is the operating work that makes two companies capable of acting as one clear experience without pretending they are one organization. It defines authority, evidence, handoffs, claims, systems, and exceptions before volume arrives.

This checklist covers referral, sales, design, installation, finance, equipment, service, and other solar partnerships. Legal structure, licensing, privacy, marketing consent, tax, employment, finance, and regulated activity vary by jurisdiction and need qualified review.

Start with the partner’s actual role

“Channel partner” is too broad to govern behavior. Name the activities the partner may perform and the decisions it may make.

Common roles include:

One organization can perform several roles. Give each role its own authority and readiness evidence. A referral agreement does not authorize someone to make production or savings claims. Product training does not qualify a partner to make engineering decisions.

Write a role charter with included activities, prohibited activities, jurisdictions, customer groups, systems, data, claims, decision authority, required competence, and escalation. Have responsible legal and compliance reviewers reconcile it with the agreement.

The solar partnerships guide provides ideas for partner categories. This article begins after the category is chosen and asks whether the relationship can operate.

Define the joint customer promise

Write what the customer should experience from first introduction through the end of the partner’s role. Use observable actions rather than brand adjectives.

The promise should answer:

• Who contacts the customer and under which identity?
• What can that person explain or offer?
• Which company receives and protects data?
• Who prepares and reviews technical or commercial outputs?
• Who signs and delivers the contract?
• Who owns questions, complaints, changes, and aftercare?

Identify transitions where the customer will meet another organization. Do not hide the relationship. Commercial and consumer disclosures should be visible and reviewed for applicable requirements.

The U.S. Federal Trade Commission’s advertising and marketing guidance provides federal resources on truthful advertising and related business obligations. Companies should obtain advice for the claims, channels, audiences, and jurisdictions involved. Operationally, every partner needs a current source for approved statements and a route for questions.

Test the promise with a difficult but ordinary customer situation. The customer changes scope after design. A bill is incomplete. Equipment availability changes. A complaint arrives during a handoff. If both companies point at each other, the promise is not ready.

Build the responsibility map down to the decision

A RACI chart can help, but broad rows such as “sales” or “installation” hide the decisions that cause conflict. Break the path into outputs and releases.

Map:

1. Lead capture and consent record.
2. Qualification and acceptance.
3. Site and load evidence collection.
4. Design or estimate request acceptance.
5. Model assumptions and technical review.
6. Proposal content and commercial approval.
7. Customer presentation and revision.
8. Contract, payment, and finance steps.
9. Delivery handoff and customer communication.
10. Change, complaint, service, and closeout.

For each, name preparer, reviewer, release authority, customer communicator, system of record, and exception owner. Do not allow “both” as the only answer. Shared work still needs one accountable release.

Preserve limitations. A salesperson can communicate an approved preliminary model without becoming the structural or electrical reviewer. A software output can support a design workflow without becoming authority approval.

The solar project handoff checklist can be adapted to company boundaries. Add acceptance at the receiving side. A handoff is complete only when the next role can identify the customer decision, evidence, current version, commitments, and open conditions.

Set lead registration and conflict rules

Lead disputes can damage the partnership before a project reaches design. Define what constitutes a registerable lead, required evidence, duplicate window, existing-customer treatment, territory, named-account rules, acceptance time, rejection reasons, ownership duration, inactivity, reassignment, and dispute authority.

Do not let a CRM timestamp decide everything. A partner may submit a public company name with no contact or permission. Another may have an active customer conversation. The rule should reflect legitimate contribution and applicable contact requirements.

Use statuses:

• Submitted: record received, not yet accepted.
• Accepted: minimum criteria met and owner assigned.
• Returned: missing or conflicting information identified.
• Duplicate or existing: routed under the conflict rule.
• Qualified: customer and project meet the next-stage criteria.
• Deferred or closed: trigger or reason recorded.

Compensation should tie to defined events in the written agreement and qualified tax, legal, and accounting review. A “lead fee,” commission, revenue share, and reseller discount can have different consequences. Do not let the enablement deck become the commercial contract.

Audit lead quality and customer experience together. A partner sending many unqualified names creates follow-up work and consent risk, even if volume looks healthy.

Establish data ownership, access, and security review

List every data class the partnership creates or shares: contact details, consent evidence, bills, interval data, site photos, drawings, identification, finance information, contracts, designs, proposal records, service history, and support messages as applicable.

For each class, define purpose, controller or responsible entity as advised, collection notice, authorized users, transfer method, system of record, retention, correction, export, deletion, incident route, and termination treatment. Requirements depend on jurisdiction and relationship, so involve qualified privacy, security, and legal reviewers.

NIST’s Cybersecurity Framework supplies a structure for managing cybersecurity risk. CISA’s Software Acquisition Guide supplies software assurance questions. These sources do not certify a partner or product. Use them to inform the actual review and keep written evidence.

Apply least-necessary access based on role. A referral partner may not need design files. A designer may not need finance records. Review access when roles change and at termination.

Test data corrections and deletion, not only initial transfer. If a customer changes an address or withdraws permission, which systems and partners receive the update? A one-way integration can create stale records that continue to drive communication.

Give partners a controlled claims library

Create approved statements by category: company identity, partner relationship, product and service scope, process, pricing, demo or access, equipment, production modeling, financial modeling, incentives, timelines, warranties, and customer outcomes. Many categories may prohibit specific public claims without case-level evidence.

Each approved entry needs source, date, jurisdiction, exact boundary, owner, and expiry or review trigger. Include examples of language that overstates the evidence. Make old versions inaccessible or clearly superseded.

Never authorize a partner to invent savings, production, accuracy, approval, time reduction, close-rate, profit, or customer-result claims. Customer-specific models need source inputs and limitations. Tax, incentive, tariff, legal, finance, code, and utility claims require current authority and appropriate review.

The Federal Trade Commission provides consumer solar guidance for the U.S. market. Use it alongside current law, contract review, and company policy. General federal guidance does not settle every transaction, jurisdiction, or business model.

Use role-play. Ask the partner to answer a buyer requesting a guarantee, a current incentive explanation, and a competitor comparison. Evaluate whether they stay inside the source and route the question.

Define qualification and handoff evidence

Partners need a short, role-specific intake. A referral partner should not be forced to collect technical data beyond competence or customer expectation. A sales or survey partner may need a deeper controlled brief.

Define the evidence required for each output. An inquiry needs identity, contact basis, customer interest, site, and next action. A preliminary design request needs a decision purpose, accepted source files, project type, known constraints, and assumptions allowed. A final technical release requires a separate evidence and review path.

Use an acceptance response. Accept, return with a specific request, narrow the output, route to survey or specialist review, defer, or stop. “Bad lead” and “incomplete design” are not useful reason codes.

Track handoff returns by category. If one partner repeatedly omits meter identity, adjust training and form design. If all partners struggle with one request, the central rule may be unclear. If the data is hard for customers to obtain, create an alternate evidence route rather than demanding repeated follow-up.

The solar sales-design handoff guide can support internal routing. For partners, add relationship identity, customer consent, commercial owner, and disclosure fields.

Train for decisions and exceptions

Feature tours are insufficient. Partners need to understand the customer’s decision, the evidence boundary, and when to stop.

Build training around cases:

• One ordinary accepted opportunity.
• One incomplete record that should be returned.
• One customer request outside approved claims.
• One project requiring specialist escalation.
• One revision that changes design and proposal outputs.
• One complaint or handoff failure.

Assess behavior, not attendance. Ask the partner to perform the task, explain the evidence, identify the boundary, and route the exception. Record permitted scope and review dates. Refresh when products, claims, processes, regulations, jurisdictions, or roles change.

The Department of Energy’s solar workforce development resources address broader solar training and career needs. Inside a partner program, competence should be tied to specific authorized work and evidence, not a generic certificate created by the vendor.

Do not invent partner credentials. Where licenses or professional roles are required, verify them through current appropriate sources and responsible review.

Align the commercial mechanics with the workflow

Document how registration, acceptance, qualification, proposal, contract, payment, cancellation, change, and service affect compensation. Define who invoices whom, what event earns payment, how taxes are treated, how disputes are resolved, and which records support the event, subject to qualified review.

Avoid incentives that reward raw submission volume while central teams absorb qualification. Avoid paying for a signature before the agreement’s cancellation, finance, or acceptance rules are understood. The correct model depends on the relationship and jurisdiction.

Make customer pricing authority explicit. Can the partner present a fixed price, approved range, configured offer, or no price? Which discounts require approval? What happens when equipment, scope, or site evidence changes?

Commercial terms should not force technical shortcuts. A response-time promise to a partner must begin when an accepted brief enters the queue, not when any name is submitted. A commission deadline should not encourage premature customer signatures.

Confirm current pricing, product access, implementation scope, and contract terms in written quotes. Marketing decks and training slides are not the governing agreement.

Run a controlled launch

Choose a narrow initial scope: a defined partner role, market, customer class, project type, and capacity limit. Assign named contacts on both sides. Agree how active customers will be protected if the test pauses.

Before launch, verify:

1. Role charter and agreement align.
2. Customer identity and disclosures are clear.
3. Lead and data rules are tested.
4. Claims and templates are current.
5. Qualification and handoff cases pass.
6. Commercial events and records agree.
7. Exceptions, complaints, and incidents have routes.
8. Capacity exists for the expected work.

Review every early case. Observe customer communication, handoff acceptance, correction, support, and exceptions. Do not publish success claims from a tiny uncontrolled launch.

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.

This limitation applies when partners use SurgePV outputs too. The software record supports their defined workflow. The responsible parties still own verification, professional judgment, and external decisions.

Operate the partnership with evidence

Hold an operating review separate from relationship celebration. Use a balanced record:

• Submitted, accepted, returned, qualified, deferred, and closed opportunities under stable definitions.
• Handoff returns and corrections by reason.
• Customer response and complaint themes.
• Claim, data, access, and scope exceptions.
• Queue age and capacity by work stage.
• Contract and payment events under finance-approved definitions.
• Training, support, and competence renewals.

Do not rank partners from raw lead count. Normalize role, market, project mix, data quality, and time in program. Use metrics for diagnosis and contractual administration, not public performance claims without a retained evidence basis.

Assign one improvement at each review. It may be a clearer qualification question, corrected template, new case exercise, access change, commercial clarification, or pause. Publish controlled changes with effective dates.

Create an exit plan before it is needed. Identify customer communication, active-project ownership, data export or deletion, access removal, record retention, unpaid commercial events, warranties or service, and public claims. Follow the agreement and applicable requirements with qualified guidance.

What should a solar partner operating charter contain?

A solar partner operating charter should contain each party’s role, shared customer promise, lead and territory rules, evidence ownership, approved claims, qualification standard, handoff acceptance, technical and commercial boundaries, incident routes, support model, payment events, exit duties, and review triggers. Every responsibility needs a decision owner and a visible limit. That shared record makes the relationship testable after controlled launch.

The charter is an operating record, not a celebratory partnership announcement. It should answer what happens when a lead overlaps, site evidence is incomplete, a proposal claim needs review, customer information must cross systems, or the partner stops operating. If those decisions remain in email, the relationship will depend on whoever remembers the launch meeting.

Do not assume one charter can fit every partner type. A referral source, dealer, installer, finance relationship, design partner, and software integration carry different decisions. Reuse the field structure, then write the actual roles and boundaries for the relationship being launched.

How should partner readiness be tested before launch?

Test solar partner readiness with representative lead, qualification, evidence-transfer, customer-communication, exception, support, and exit scenarios. The partner should complete each handoff using the shared records and approved language without private rescue. Launch remains limited when either party cannot identify the owner, acceptance rule, permitted release, or escalation route. The controlled test should fail visibly whenever ownership or required evidence disappears.

Run the test as work, not a knowledge quiz. A partner can remember training slides and still fail to provide the evidence the receiving team needs. Give the participants a realistic packet with one ordinary case and one common exception, then observe the customer and data handoffs through acceptance.

1. Register a lead and resolve a deliberate overlap scenario.
2. Qualify the opportunity using the agreed evidence fields.
3. Transfer customer and site information through the approved system.
4. Prepare a customer message using the controlled claims library.
5. Route a technical or commercial condition to the correct reviewer.
6. Open an incident through the appropriate response path.
7. Simulate reassignment or exit for one active opportunity.

Use this copy-ready launch record:

Partner type and permitted activities:
Representative scenario:
Lead ownership result:
Qualification evidence accepted or returned:
Data transfer and custody check:
Customer language reviewed:
Exception and assigned reviewer:
Support or incident route tested:
Active-work continuity test:
Private rescue required:
Launch status and limitations:
Next review trigger:

Private rescue is a finding. Some launch support is expected, but it should match the published support model. If one internal employee rebuilds every intake or rewrites every proposal, the partner is not yet performing the claimed role. Narrow the launch, improve the evidence request, or revise the responsibility map.

How should a partnership handle an operating incident?

A solar partnership should handle an operating incident by identifying the customer or project risk, preserving the source record, assigning the correct safety, service, privacy, technical, commercial, or contract route, and controlling customer updates. The incident owner resolves the case while a separate review decides whether the charter, training, system, or partner status must change. Customer protection precedes program optimization.

Illustrative example, not a partner case: A dealer sends a customer a projected-savings statement that falls outside the approved claims library. The receiving company discovers the message during proposal review. The incident record preserves the exact statement, source, project basis, recipient, and current customer decision.

The immediate response is not a general partner retraining session. The authorized commercial and compliance owners decide how to correct the live customer communication. Technical or financial reviewers address any affected model or scenario. The partner-support owner then investigates whether the cause was missing training, inaccessible approved language, unclear authority, or deliberate bypass.

If the gap is systemic, update the claims library, workflow control, and launch test. If the partner ignored a clear rule, the contract and governance owners decide the relationship response. The article cannot determine legal responsibility or remedy, but the operating record prevents those decisions from being made on incomplete recollection.

Use incident trends carefully. One case can justify a project response without proving a broad pattern. Define incident types, preserve confirmed causes, and review repeated mechanisms before changing the entire program. A rise in reporting may indicate better visibility rather than worse partner behavior.

Publish the partner support catalogue

Partners need to know which questions belong to enablement, operations, product support, technical review, finance, contracts, service, or incident response. A single contact address can still route work internally, but the acceptance rules and response owners should be visible.

Define response commitments only when the organization can support them. Avoid inventing a universal service level inside the charter. The catalogue should name how urgency is assessed, which requests block customer issue, and what the partner may do while waiting.

Review rejected support requests. Repeated missing fields may show that training or the handoff form is weak. Repeated requests outside the partner’s role may show that the operating model is unclear. Fix the mechanism before adding more reminders, then test whether the next request arrives with a usable decision.

Keep case records connected to the partner and customer opportunity. A support answer in a private thread can change a claim, configuration, or release without updating the shared project. The responder should record the decision and affected output where the next role can find it.

The final enablement gate

A partner is ready only when both sides can run representative work and explain the boundary. Use this final check:

• The partner can state its role and prohibited activities.
• A customer can understand which company does what.
• Leads can be accepted, returned, duplicated, deferred, and closed consistently.
• Data can move, change, and exit under approved controls.
• Claims trace to current sources and exceptions route correctly.
• Handoffs include the evidence the receiving role needs.
• Training demonstrates competence on normal and exception cases.
• Commercial events match the agreement and operational records.
• Complaints, incidents, and pauses protect active customers.
• The launch scope matches available capacity.

Partner enablement is complete enough to launch when the ordinary path works and the exception path is trusted. It is never finished permanently. Products, people, markets, evidence, and external requirements change. The operating record must change with them.

A good partner program does not erase organizational boundaries. It makes them legible to the people doing the work and to the customer. That clarity is what allows the relationship to grow without every new opportunity becoming a negotiation about who was supposed to do what.

Govern co-marketing as an operating process

Joint webinars, landing pages, proposal inserts, email sequences, events, and social posts can create customer expectations before operations sees the opportunity. Put co-marketing assets through a release path that checks identity, relationship disclosure, claim sources, audience, jurisdiction, offer scope, data capture, follow-up ownership, and expiry.

Create an asset record with the owner at each company, approved copy, design file, destination, campaign period, lead route, source claims, required disclosures, and withdrawal date. A screenshot in a partner’s drive is not a controlled asset. When pricing, product scope, program terms, equipment, or external rules change, identify every live asset affected.

Do not allow a partner logo to imply certification, endorsement, exclusivity, or capability beyond the written relationship. Define logo use, naming, public announcements, case studies, and customer references in the agreement and brand rules. Obtain consent and retain evidence before identifying a customer or publishing an outcome.

Test lead routing before launch. Submit records from each form and market variation. Verify consent evidence, source attribution, duplicate handling, notification, ownership, and response. A campaign is not ready because the page renders correctly if the customer record disappears into the wrong queue.

Give campaign staff an escalation script for technical, finance, incentive, schedule, and performance questions. The script should name the responsible destination and response expectation. It should not supply a confident answer beyond the approved source merely to keep a live event moving.

Design partner support around incident type

One partner inbox can hide very different events. Define routes for customer urgency, lead conflict, data access, product support, technical question, claim approval, commercial dispute, complaint, safety concern, security or privacy incident, and active-project delivery issue. Each route needs an owner, backup, evidence required, and response rule.

Create severity definitions from consequence. A request to update a brochure is ordinary work. A customer receiving an inconsistent price or an unauthorized performance promise needs faster commercial review. A possible data or safety incident must follow the responsible company’s approved incident process immediately.

Train partners not to investigate beyond their role. Preserve the original report, time, people, systems, customer impact, and actions already taken. Avoid speculative blame in customer communication. Qualified leaders should coordinate the response under the agreement and applicable requirements.

Review support records by recurring cause. Several “software questions” may actually arise from unclear qualification policy. Repeated proposal corrections may trace to one uncontrolled template. Frequent escalation to a founder may expose missing partner-management authority. Fix the source of the issue, then update training and controlled materials.

Publish a partner contact directory with role names rather than relying on one friendly employee. Include backup and transition rules. When people leave, access, customer ownership, open tickets, and undocumented commitments need explicit transfer. Partnership continuity should not depend on private messaging history. Give partner-released solar proposals the same source and review controls.

Frequently Asked Questions

What should a solar partner onboarding pack contain?

Include the joint customer promise, authorized and prohibited activities, role and responsibility map, lead and data rules, current approved claims, qualification and handoff criteria, training and competence evidence, commercial process, exception contacts, complaint route, versioned templates, launch scope, and scheduled review. Keep controlled sources separate from promotional material.

How long should solar partner enablement take?

There is no useful universal duration. Time depends on partner role, jurisdiction, customer contact, data access, technical responsibility, integration, training, and contract complexity. Define evidence-based readiness gates. A referral partner may need a narrower path than a partner representing offers, collecting site data, or performing regulated work.

Who owns the customer in a solar partnership?

Replace the phrase “owns the customer” with specific rights and responsibilities. Define who may contact the customer, store data, make claims, schedule work, issue offers, sign contracts, resolve complaints, and communicate after handoff. The agreement and customer notices should reflect applicable privacy, marketing, consumer, and contract requirements.

How should partner-generated solar leads be accepted?

Use a documented acceptance rule covering identity, contact permission, site and market fit, customer objective, minimum context, duplicates, required disclosures, and next action. Return or reject records with a reason. Do not pay or report a lead as accepted merely because a form submission entered the CRM.

When should a solar partner program pause?

Pause when a partner operates outside authorized scope, uses unsupported claims, mishandles customer data, repeatedly fails handoffs, lacks required competence, bypasses review, or creates unresolved customer harm. Preserve evidence, protect active customers, follow the agreement and applicable law, and resume only after the responsible reviewers accept a documented treatment.