How to Run a Co-Branded Solar Opportunity

Co-branding can make a solar offer look more complete while making responsibility harder to see. A trusted local brand may generate the inquiry. An installer may qualify the property. A design team may prepare the concept. A finance or equipment partner may appear in the proposal. If the customer cannot tell who is speaking, using their data, making the claim, or owning the next action, the partnership has created friction rather than trust.

The solution is an interface contract that follows the customer. Every page, form, call, design, proposal, revision, signature, and support message should identify the company acting, the role it is performing, the records it received, the decision it owns, and the commitments it can make.

This guide is operational, not legal, privacy, contract, financing, tax, advertising, licensing, utility, engineering, or consumer-protection advice. Partner roles and data permissions depend on the actual companies, agreements, audience, channel, and jurisdiction. Qualified reviewers must approve the live arrangement.

The solar channel marketing guide covers broader channel strategy. The partner enablement checklist covers materials and partner readiness. Use this guide for the customer-facing roles, accepted handoffs and co-branded opportunity record.

What should a customer understand at every partner step?

At every co-branded step, the customer should identify the companies involved, why each is present, which company is communicating, where the customer’s information came from, what permission or request supports the contact, which offer and project state applies, who owns the next decision, and where questions or complaints go. Logos and a generic “our team” label are not enough.

Start with identity. Use the current legal or approved trading name, customer-facing brand, relevant relationship, and contact channel. If a local association introduces an installer, say that. If a marketplace passes an inquiry to a provider, explain the route. If a design service supports the installer behind the scenes, decide whether and how that relationship is material to the customer and have qualified reviewers approve the disclosure.

Then define the current role. “Partner” can mean referrer, advertiser, reseller, installer, designer, lender, equipment provider, operations contractor, or support provider. Those roles carry different authority. A referral source may not control system scope. A designer may not set contract terms. An installer may not approve a lender’s decision.

The FTC’s advertising guidance for small businesses says United States advertising must be truthful and non-deceptive and objective claims need evidence before dissemination. It also considers implied meaning. That source does not approve a partnership or campaign. It supports the narrow discipline that the combined experience, including identities, visuals, omissions, and handoffs, must not create a misleading impression.

Write a customer-facing relationship sentence for each step. It should be short enough to use in the page, form confirmation, email, and call opening, yet specific enough to explain the actor and purpose. Do not hide the relationship solely in a footer or privacy page when it materially affects why the customer is hearing from a new company.

How should partner responsibilities and permissions be mapped?

Map the partnership as interfaces rather than a shared mission. For every customer and project transition, name the sending owner, receiving owner, accepted inputs, purpose, permission, required evidence, service level, decision authority, failure response, support route, and change rule. Keep marketing, data, technical, commercial, contract, delivery, and complaint responsibilities separate. Unknown authority stops the handoff.

NASA’s interface-management guidance applies to NASA systems work, not commercial solar partnerships. It describes defining interface responsibilities, maintaining and controlling internal and external interfaces, and managing changes. The transferable idea is that two capable components can still fail at their boundary. The partner handoff needs its own accepted inputs, outputs, responsibilities, and change process.

Build seven interface maps:

1. Brand interface. Approved names, logos, visual hierarchy, relationship language, asset permissions, and retirement rules.
2. Marketing interface. Audience, offer, claims, qualifiers, channels, campaign ownership, and lead-source record.
3. Data interface. Purpose, notice, permissions, fields, transfer, access, use, retention, correction, deletion, security, and incident owner.
4. Sales interface. Qualification fields, contact order, discovery, follow-up, decision authority, pricing boundary, and CRM record.
5. Technical interface. Accepted site and energy inputs, design state, assumptions, reviewer, version, output, and escalation.
6. Commercial interface. Quote, financing, equipment, contract, signature, payment, change, cancellation, and customer obligations.
7. Delivery and support interface. Scheduling, access, permitting, installation, inspection, utility, warranty, complaint, and long-term contact.

Do not collapse these into one RACI chart with “both” in every cell. Shared participation is not shared authority. Name one owner for the decision and show required consultation or approval separately.

The FTC’s relationship-disclosure guidance for social media influencers says people should disclose financial, employment, personal, family, or value-based relationships with a brand when endorsing through social media. This is United States staff guidance for endorsements, not a general partnership contract. It illustrates why a material relationship should be obvious where the message appears rather than assumed to be understood.

Data needs a field-level contract. A partner may need a name and preferred contact route to complete an introduction. A design owner may need an address, imagery, consumption record, or equipment preference for a later authorized task. That does not make the whole CRM record portable. Qualified privacy and legal owners should define the actual basis and notice.

Define acceptance and rejection at each interface

A handoff is not complete because one partner sent an email or changed a CRM owner. The receiver should test the package against written acceptance conditions. Missing identity, customer purpose, permission state, current project version, required input, or promised next step should produce a visible rejection or exception rather than an apparently active opportunity.

Define four possible interface responses:

1. Accepted. The receiver has the required records and authority for the named next action.
2. Accepted with condition. A specific non-blocking condition, owner, due event, and customer effect are recorded.
3. Rejected to sender. The package cannot support the requested action and returns with the exact missing or conflicting record.
4. Stopped. Permission, authority, customer request, relationship, safety, legal, technical, or commercial evidence prevents continuation.

The customer-facing state should remain compatible with the internal state. If the receiver rejects the handoff, an automated email should not announce that a design is underway. If a customer withdraws the applicable request, the next partner should not continue contact from a stale task. If the proposal basis changes, the partner presenting it should not keep the previous financial summary attached.

Set acknowledgment rules as evidence, not universal time promises. Record when the sender packaged the handoff, when the receiver observed it, which version was reviewed, what decision was made, and when the customer was notified. Different project classes may require different owners and review depth. Do not invent one response-time target for every interface.

Test duplicate and conflict handling before launch. The same person may enter through both partner sites, use a different email address, or ask two companies different questions. Define how identity is reviewed without unsafe automatic merging, how conflicting consent or preference records are handled, who contacts the customer to clarify, and which source remains authoritative for each field.

Finally, test termination. A partner relationship can end while customers and projects remain active. The agreement and operating record should identify who retains which lawful records, who completes or transfers open commitments, how access is revoked, which assets are retired, what customers are told, and where future support goes. A termination plan is part of customer clarity, not merely contract administration.

What process keeps the co-branded opportunity coherent?

Keep the opportunity coherent by approving one customer path, freezing compatible brand and claim assets, capturing permission at the right step, creating a controlled lead identity, transferring only accepted records, confirming every handoff, linking technical and proposal versions, and maintaining one customer-visible support route. Test exceptions before launch and record material changes through successor versions under the approved access and retention policy.

Use this nine-step process:

1. Define the joint customer job. State the audience, problem, offer, deliverable, exclusions, service area, qualifying conditions, and customer decision. Do not begin with logos.
2. Approve the partner role contract. Name each legal entity, customer-facing brand, role, authority, compensation or material relationship, agreement owner, and prohibited representation.
3. Build the customer path. Map advertisement, landing page, form, confirmation, contact, discovery, technical work, proposal, decision, delivery, support, correction, and complaint states.
4. Freeze claims and assets. Bind objective claims and visuals to evidence, owners, audiences, jurisdictions, qualifiers, versions, expiry, and change triggers.
5. Approve the data route. Define notices, permissions or other reviewed basis, exact fields, recipients, purpose, access, security, retention, correction, deletion, and incident handling.
6. Open one opportunity identity. Use stable customer and project references, source attribution, duplicates policy, current owner, status, next decision, and complete transfer history.
7. Execute confirmed handoffs. The sender packages accepted records; the receiver acknowledges them, accepts or rejects the state, and becomes visible to the customer before acting.
8. Control designs and proposals. Link the proposal to the accepted design, model, equipment, financial assumptions, commercial terms, partner roles, and approvals. Changes reopen affected reviews.
9. Monitor the combined experience. Test contact identity, message consistency, missing data, duplicate leads, partner failure, complaints, corrections, opt-outs, project changes, and relationship termination.

The DOE homeowner solar guide says there is no universal solar solution and discusses roof suitability, estimates, installers, contracts, financing, and consumer questions. It does not approve a co-branded workflow. It shows why customer questions span several decisions and why each partner should answer only within a verified role.

Illustrative example: a community organization and installer

Illustrative workflow, not a real partnership, endorsement, customer, permission, contract, lead result, savings result, or legal conclusion. A community organization promotes a solar education session. An installer will respond to people who separately request a property review. The first draft places both logos on one form and says, “Our solar team will contact you.”

The interface review finds several gaps. The form does not identify which company receives the property request, why it receives the data, which fields move, or who will contact the person. The organization has not approved the installer’s savings language. The installer cannot answer questions about the organization’s membership program.

The partners split the steps. The education registration remains with the organization. A separate, clearly identified action lets an attendee request contact from the installer under reviewed notice and permissions. The confirmation names the installer, the data transferred, the expected next step, and both support routes. The installer uses its approved proposal and does not imply that the organization guarantees the project.

The example produces no conversion or trust claim. Its value is that the customer can see when the relationship changes.

How should messages, designs, and proposals stay aligned?

Keep a compatibility register linking the approved relationship statement, claim set, campaign assets, form and permission language, sales scripts, technical basis, proposal template, commercial terms, and support route. Each item needs a version, owner, permitted scope, expiry, and change trigger. If one partner changes an input or role, reopen every affected customer-facing asset before reuse.

NASA’s configuration-management guidance discusses baselines, visibility and control of changes, version distinction, and consistency between a product and its information. It is a NASA process source, not solar marketing guidance. The useful analogy is that a proposal and its co-branded promises must point to compatible project and relationship versions.

Create compatibility rules before launch:

• the campaign offer must map to an active fulfillment definition;
• the form must collect only the fields needed for that accepted step;
• the first contact must match the identity and purpose presented at collection;
• the discovery record must retain lead source and promises already made;
• the technical output must state its inputs, assumptions, exclusions, and review state;
• the proposal must link to the accepted design and current commercial owner;
• the contract must identify the actual parties and reviewed obligations;
• support messages must send customers to the current responsible company;
• retired partner assets must not remain live after the relationship changes.

Do not “fix” a mismatch by adding both brands to every document. More logos can make ownership less clear. Use the visual hierarchy to show which company owns the current step and explain the other company’s role in plain language.

Copy-ready co-branded opportunity record

Use the solar differentiation framework when partners need to decide what each brand genuinely contributes. Use the solar RFP response guide when the relationship moves into a formal multi-party procurement process.

Where can software support the partner handoff?

Software can preserve a shared project identity and connect accepted site, layout, shading, yield, financial, electrical, material, and proposal records. It cannot establish legal data roles, authorize brand use, approve a disclosure, decide who may contact a customer, create contract authority, or transfer liability. Partner agreements and qualified owners must govern every commercial and customer decision.

Evaluate the offered solar design workflow with a sanitized partner handoff. Confirm which design and proposal outputs, revision records, exports and access controls are available, which depend on configuration and which need manual handling. A product demonstration does not authorize the partner relationship or validate customer permissions.

Test the implementation with failure cases. Send an incomplete record, revoke a permission under the approved process, change an equipment assumption, supersede a proposal, remove a user, end a partner’s access, and route a complaint. Verify exports, audit history, role permissions, duplicate handling, retention, and recovery. A happy-path demonstration does not prove that customer ownership stays clear when the partnership changes.

Also inspect customer-visible exports. A proposal, email attachment, or downloaded report can outlive the system session that created it. Confirm that the file names the responsible company, project and document versions, relevant assumptions, relationship boundary, support route, and current review state without exposing internal or partner-only information.

The most useful co-branding question is not whether the two logos look balanced. It is whether a customer can reconstruct the path: who invited them, who received their request, who prepared the project information, who made the commercial offer, who accepted the contract, and who remains responsible now.

Frequently Asked Questions

Which brand should contact a co-branded solar lead first?

Use the contact route the customer saw and accepted. The first message should name the contacting company, the partner relationship, the source of the inquiry, why the company has the customer’s information, the promised next step, and the support route. Do not assume that permission to hear from one brand automatically authorizes another brand or channel.

Who should own the co-branded solar proposal?

Assign proposal ownership in the written partner interface. Name who accepts project inputs, develops and reviews the technical basis, controls pricing and commercial terms, presents the proposal, approves revisions, signs the contract, and answers later questions. Both logos on a document do not create shared authority, liability, or approval unless reviewed agreements actually establish it.

How should partner claims stay consistent?

Maintain one approved claim register with exact wording, evidence, permitted audience, jurisdiction, channel, owner, qualifiers, expiry, and change triggers. Map each advertisement, landing page, form, script, email, visual, and proposal to that version. When the offer, product, equipment, model, pricing, service area, or partner role changes, reopen affected approvals before reuse.

Can partners share every solar lead record?

No general permission is established by a commercial partnership. Define the lawful purpose, notice, consent or other approved basis, fields, recipients, access, use, retention, correction, deletion, security, and incident route for the actual jurisdiction and channel. Share only the records required for the accepted customer step after qualified privacy and legal review.

Where can SurgePV support a partner handoff?

Evaluate the offered SurgePV configuration with a sanitized partner handoff and confirm available design and proposal outputs, revision records, exports and access controls. Partners still approve identity, permissions, claims, pricing, contracts, customer communications, technical review, support and delivery. Software does not authorize a relationship or commitment.