Solar Sales and Design Alignment: 6 Warning Signs

A proposal says the customer selected the larger option. The design workspace says that option is preliminary. Sales believes the latest bill is attached; design modeled the earlier usage file. Both teams can open a record with the same address and customer name, yet they are no longer solving the same project.

That is the awkward part of solar sales and design alignment. The disagreement rarely arrives as a loud argument. It appears as two reasonable descriptions that cannot both be true at the same time.

This page owns the diagnostic and reconciliation job. The informal handoff error guide explains how context gets lost while work moves between people. The sales-to-design handoff guide defines an ideal input packet. Here, the packet has already arrived, work has begun, and the manager needs to determine whether sales and design are carrying incompatible versions of customer intent, evidence, scope, assumptions, and release state.

What breaks solar sales and design alignment?

Solar sales and design are out of sync when their working records describe incompatible decision-grade facts about one project. A normal role difference becomes a project-model conflict when the customer decision, evidence, scenario, assumption, revision, or approval state differs and that difference can change a proposal, design output, commercial statement, review request, or next release.

A project model is the set of recorded facts, choices, assumptions, and states a team uses to decide what to produce next. Sales may organize the model around the buyer’s decision. Design may organize it around the site, equipment, geometry, inputs, and technical review. Those views should differ in emphasis. They should still point to the same accepted project.

The phrase “different versions” does not mean two PDF filenames alone. One team can hold version C of a layout while another holds version B and still work safely if version C is visibly preliminary and version B remains the accepted proposal basis. The dangerous condition is semantic: the two teams give the same field different meanings, or give different fields the same status word.

NASA’s requirements-management guidance is written for NASA programs, not solar sales operations. It describes control of stakeholder expectations and requirements, bidirectional traceability, consistency between requirements and design, and impact review when baselines change. The useful analogy is that a customer expectation should be traceable into the design response, and a design change should be traceable back into every affected customer and commercial statement.

NASA’s interface-management guidance also describes defining interface characteristics, maintaining compatibility, and retaining configuration information when work is divided among parties. Again, this is a process analogy rather than a solar standard. Sales and design form an interface. The project model is compatible only when both sides can identify what crossed that interface and what the receiving team accepted.

The U.S. Department of Energy’s solar soft-cost overview includes customer acquisition, permitting, financing, installation labor, supplier payments, and company overhead among non-hardware solar costs. DOE does not measure the cost of a sales/design mismatch on this page. It supplies a useful boundary: coordination and company process sit inside solar project economics, even though they are not modules or inverters.

Use one practical test. Ask sales and design separately, without showing either team the other’s answer, to state the customer decision, selected scenario, active evidence, assumptions, current revision, and next allowed release. Different wording is fine. Incompatible meaning is the warning.

What six signs show sales and design are solving different projects?

Six signs reveal a split project model: the teams describe different customer decisions, assign different values or owners to the same field, use status words differently, lose scenario identity, let customer artifacts disagree with technical revisions, or expose assumptions and missing evidence to only one role. Each sign needs a comparison, an owner, and a release consequence.

1. Sales and design describe different customer decisions

Ask sales, “What is the customer deciding now?” Then ask design, “What question is this design meant to answer?” The answers should connect. If sales says the customer selected a larger system while design says it is testing whether the larger system fits, a possibility has become a commitment somewhere between the two records.

Customer intent often begins as ordinary language: reduce operating cost, use the available roof, prepare for a vehicle, compare storage, meet a budget, or understand a production range. Design needs a bounded question, not an implied promise. Record the customer’s words, the decision stage, the requested scenarios, the evidence supplied, and what remains subject to technical, commercial, financial, legal, utility, or customer confirmation.

Do not force design to infer the customer’s decision from a target module count. Do not force sales to infer customer readiness from a finished-looking layout. Trace the decision into the design request and trace the response back into the proposal statement.

Proof test: can each team point to the same recorded customer choice and distinguish it from an internal recommendation, a modeled option, and a later approval?

2. The same decision-grade field has different values or owners

The project address matches, so the teams assume the project matches. Then one record points to the main building and another to an outbuilding. One uses the latest usage file, another uses a value copied from a lead form. One lists the selected equipment, another lists the default catalog item.

A decision-grade field is any field capable of changing scope, output, price, customer language, required review, or release state. It needs a value, source, observation or decision date, evidence state, owner, and affected objects. “Roof confirmed” is too small a record if the confirmation does not identify which roof, by whom, from what evidence, for which use.

The conflict may be about authority as much as value. Sales may own the customer’s stated future load, while design owns how that input enters the technical model. Neither owner should silently overwrite the other. Preserve the submitted value, the accepted interpretation, and the person who made that interpretation.

Proof test: for every field that differs, can the manager name the source owner, object owner, acceptance owner, and release owner without giving one person authority over all four?

3. “Approved,” “final,” and “selected” mean different things

Status language causes trouble because it sounds precise while hiding the object and authority. “Customer approved” could mean the customer liked the visual, selected a commercial option, confirmed an address, or accepted contract language. “Design final” could mean ready for proposal use, ready for a technical review, or frozen after an external decision.

Replace free-floating status words with an object, revision, decision, actor, conditions, and effect. “Layout L3 accepted by proposal owner for customer comparison, pending site evidence and qualified technical review” carries more information than “final layout.” It does not inflate a narrow acceptance into engineering, permitting, utility, construction, or financial approval.

For United States advertising context, the Federal Trade Commission’s small-business advertising guide says advertising must be truthful and non-deceptive and that advertisers need evidence to support claims. This article is not legal advice, and other jurisdictions may impose different requirements. The operational lesson is conservative: proposal language should reflect the actual evidence and decision state, not the most optimistic reading of an internal status word.

Proof test: can the team reconstruct the exact question answered, the object reviewed, the revision, the responder’s authority, any conditions, and the downstream release that response permits?

4. Scenario identifiers and option states disappear

Solar projects branch. A customer may compare roof areas, equipment, storage, vehicle load, usage cases, commercial terms, or schedules. If the branches are called “small,” “large,” “old,” and “new,” the names will eventually detach from the inputs that created them.

Give each scenario a stable identifier and explicit state such as requested, modeled, reviewed, presented, selected, rejected, expired, or superseded. The identifier should follow its customer decision, design basis, usage source, equipment, assumptions, model output, commercial record, proposal image, and customer link. A selected commercial scenario may still require technical or external review.

The assumption-visibility guide explains why a persuasive proposal needs its basis visible. Scenario identity adds another control: every value and image must belong to the same named branch.

Proof test: if the proposal shows option S2, can the manager retrieve the S2 decision, layout, model inputs, equipment, assumptions, commercial basis, review state, and active customer artifact without guessing from timestamps?

5. Customer-facing artifacts and technical revisions disagree

A proposal can show the current module count with an older roof image. A new layout can feed a proposal while its production statement remains tied to the earlier arrangement. An updated equipment choice can appear in copy while the bill of materials still reflects the prior selection.

The DOE PV system design overview describes modules, mounting, orientation, inverters, storage, and other balance-of-system technologies as connected design elements. That does not prescribe a proposal workflow, but it explains why one changed object can affect more than one visible field.

NASA’s configuration-management guidance says configuration management makes product state known, distinguishes versions, controls baseline changes, and keeps a product consistent with information about it. This is another analogy, not a solar mandate. Its value is the parity question: does the customer-facing description match the active product state?

Proof test: can the release owner trace every proposal image, count, equipment statement, production statement, assumption, and price basis to the current accepted source object?

6. Assumptions and missing evidence are visible to only one team

Design may know that an obstruction is uncertain, an image is stale, a roof face needs verification, or a production input is provisional. Sales may know that the customer expects a future load, has not confirmed a tariff, wants an option excluded, or interpreted a range as a commitment. The project model splits when those conditions live only in a person’s notes or local tool.

DOE’s solar radiation basics says solar radiation reaching a location varies with geography, time of day, season, local surroundings, and local weather. The source does not validate any project dataset. It shows why a location value or production assumption must retain enough context for another role to judge its intended use.

Record an assumption as an assumption. Name the affected output, evidence needed, owner, review trigger, permitted preliminary work, and blocked release. Missing information should not become a default value merely because the next form requires a field.

Proof test: can sales see the technical conditions that qualify customer language, and can design see the customer and commercial assumptions that qualify the design request?

Use this diagnostic table during a live review:

What records prove which project version is current?

The current project version is proved by a connected set of records, not the newest timestamp: stable identity, customer decision, scenario state, source evidence, accepted field values, active design objects, assumptions, reviews, and release history. Each record needs an owner and a relationship to the outputs it controls, including any superseded customer-facing artifact.

Start with the solar design source-of-truth guide if field authority itself is unclear. A source of truth does not mean one person or database gets to decide every matter. It means each field has a defined authority, evidence path, change rule, and consumer.

The active state should answer four different questions. What did the customer decide? What did the evidence support? What did the responsible role accept? What may be released next? Combining them into one “project status” field makes the record look simple while pushing ambiguity into conversations.

Copy-ready sales/design project-model comparison record

Complete each side independently before the reconciliation meeting. Paste links or identifiers rather than retelling the evidence from memory.

Do not fill the accepted column by majority vote. Each conflict goes to the owner of that decision. A customer choice returns to the recorded customer decision. A design interpretation returns to design and any qualified reviewer required for that matter. A commercial input returns to its business owner. The release owner verifies parity but does not expand another person’s authority.

Keep the old values and their superseded relationship. Erasing the losing value makes a future audit harder and can leave detached artifacts live. The design revision management guide covers formal revision naming and lifecycle control after the team has identified which objects changed.

How should sales and design reconcile two project versions?

Reconcile two project versions by freezing the next affected release, comparing both models field by field, classifying each difference, routing it to the correct owner, tracing the accepted change into dependent objects, and recording a bounded release decision. The meeting ends only when every material conflict is resolved, visibly conditioned, or assigned with an explicit release restriction.

Use this process:

1. Name the affected release. State whether the conflict touches a proposal, preliminary layout, model output, bill of materials, review package, contract attachment, customer link, or internal decision. A vague “project issue” creates a vague response.
2. Freeze only what the conflict can corrupt. Stop the affected release and its dependent claims. Let unrelated work continue when its inputs remain valid and the exception is visible.
3. Capture both working models independently. Sales and design complete the comparison record before discussing the answer. This prevents the louder or earlier explanation from overwriting the evidence of divergence.
4. Classify every difference. Use identity, customer decision, evidence, accepted value, scenario, design object, assumption, review, commercial input, or release state. Classification determines who can resolve it.
5. Separate fact, interpretation, and decision. Preserve the submitted source, the role’s interpretation, and the acceptance event. One field should not pretend those are the same thing.
6. Route the conflict to the correct owner. Ask a bounded question that names the object, revision, evidence, options, decision requested, conditions, and downstream effect.
7. Run an impact trace. List every proposal field, design object, model output, commercial item, review, customer statement, and active link that consumes the changed value.
8. Update the connected objects. Change the source record first, then its dependent objects. Mark prior artifacts superseded without deleting the history that explains them.
9. Reconcile the customer-facing version. Check identity, scenario, image, count, equipment, production language, assumptions, exclusions, commercial basis, and next verification against the accepted state.
10. Issue a bounded release decision. Record who released which object and revision, for what use, with which conditions. Do not translate proposal release into engineering, utility, permitting, financial, legal, safety, or construction approval.
11. Tell the customer when the decision changed. If the correction affects what the customer saw, selected, or could reasonably infer, assign the communication to a named owner and preserve the updated artifact.
12. Fix the earliest failed control. After release, ask which missing field, role rule, or system check could have exposed the split before two full versions developed.

A reconciliation meeting should feel a little mechanical. That is useful. The team is not debating who remembered the call better. It is comparing objects, sources, interpretations, decisions, and effects.

Ownership and release matrix

What should the team do when project information is missing?

When project information is missing, preserve the gap as a controlled state: name the absent evidence or decision, show which outputs it affects, assign an owner and request, define permitted preliminary work, and block releases that would turn the gap into a claim. Never make the models match by copying an unsupported value into both systems.

“Unknown” is useful when it is specific. “Target building not confirmed between parcel address and sales-selected roof” tells the next person what to obtain. “Roof unclear” does not. “Current usage source predates the customer’s stated load change” names why the existing record cannot answer the new question.

Distinguish four treatments:

An assumption can support exploration when the responsible role accepts that use. It cannot quietly become evidence. If design needs a temporary value to compare layouts, label the scenario preliminary. If sales needs to discuss a range before a site check, describe what the range depends on and keep it out of any guarantee or approval language.

Escalation should preserve the disagreement. A manager can decide who must answer, which release waits, and which preliminary work may continue. A manager should not choose the technically convenient value merely to clear the queue.

Illustrative workflow: a future load creates two project models

Illustrative workflow, not a customer case, measured result, technical approval, financial claim, or time-saving claim. A customer mentions a future electric vehicle during a sales call. Sales records “include EV” and presents a larger option. Design receives the larger target but not the customer’s statement, charging assumption, usage source, or whether the customer selected the option.

The sales working model says the customer chose the larger system. The design working model says the team is testing a possible future-load scenario. The proposed layout looks finished enough to enter a proposal, so the difference can remain hidden.

During comparison, the manager separates the original customer statement from the sales interpretation. The larger branch receives a scenario identifier and a proposed state. The existing usage evidence remains linked to the current-load scenario. The future-load input is labelled as an assumption pending confirmation, with an owner and a visible effect on customer language.

Design then records what the site and equipment model can support under that preliminary basis. Sales can present an intentional comparison if the release owner verifies that both options use coherent inputs and that the future-load condition is explicit. A later customer selection changes the scenario state. It does not become engineering, utility, financial, permitting, legal, safety, or construction approval.

No one had to prove the other team wrong. They had to identify the decision that never became a shared record.

Where does SurgePV support solar sales and design alignment?

SurgePV can support solar sales and design alignment by keeping roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation in a connected workflow. It does not decide customer intent, validate missing evidence, assign professional authority, or replace technical, financial, legal, safety, utility, permitting, and jurisdictional review.

Use the verified solar proposal workflow against the six failure cases in this article. Change the target building. Introduce two usage sources. Create two named scenarios. Revise equipment after a proposal image exists. Add a provisional assumption. Record a conditional review response. Then inspect whether sales and design can see the same active objects, states, differences, and release conditions.

SurgePV’s verified product scope includes 3D roof modeling, solar array layout, shading analysis, energy-yield and financial 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 but do not replace approval by the responsible engineer, authority, lender, insurer, or utility. Pricing, access, implementation scope, and contract terms require confirmation in a written quote.

A shared workspace does not create shared meaning by itself. The organization must still define field owners, scenario states, revision relationships, evidence standards, review authority, and release rules. Software can make a conflict visible and carry an accepted change into connected work. People decide what the conflict means and whether the resulting project is ready for its next use.

Frequently Asked Questions

How can a solar sales manager tell whether sales and design are out of sync?

Ask each team to describe the customer decision, selected scenario, active evidence, open assumptions, current design revision, and next permitted release without seeing the other answer. Differences that affect scope, output, price, customer language, or review state show that the teams are operating from incompatible project models rather than merely using different vocabulary.

Is a different project version always a problem?

No. Sales and design legitimately hold different working views because their responsibilities differ. The problem begins when those views disagree on a decision-grade field and the difference is hidden, unowned, or allowed into a release. A labelled preliminary design and a customer-selected proposal can coexist if their relationship and limitations are explicit.

Who decides which solar project version is correct?

No single role should decide every field. The recorded customer controls customer choices, sales owns the faithful capture of commitments, design owns its model and technical assumptions, commercial owners control pricing inputs, and qualified reviewers control decisions within their authority. A release owner reconciles those accepted states without expanding anyone’s approval.

What should happen when sales and design cannot resolve a conflict?

Record both values and their sources, identify the affected outputs, assign the evidence or decision request, and restrict releases that would turn the dispute into a customer or technical claim. Preliminary work may continue only under a visible assumption when the responsible owner accepts that treatment. Escalation should preserve the disagreement, not erase it.

Can software keep solar sales and design aligned automatically?

Software can connect project objects, expose current revisions, and make differences easier to review. It cannot determine what a customer meant, validate missing site evidence, decide professional authority, or approve every technical, financial, legal, utility, safety, and jurisdictional issue. People still need to own inputs, resolve conflicts, and authorize releases.

Two teams can work quickly, communicate often, and still construct incompatible projects. The cure is not another general reminder to collaborate. Compare the actual models. Put customer decision, evidence, scenario, revision, assumption, review, and release state side by side. Resolve each difference through its real owner, then let the next artifact represent one accepted project.