Why ‘We’re Working on It’ Is Not a Useful Solar Sales Update

Consider an illustrative inbox. A customer asks where the proposal stands, and the rep replies, “We’re working on it.” Inside the company, that sentence could mean design has accepted the request, design returned a missing-input question, an approver has not reviewed the current revision, or nobody owns the next action. The customer receives the same sentence for four materially different states.

The reply sounds reassuring because it contains motion. It does not contain status. The customer cannot tell what changed, whether anything is needed from them, what controls the next step, or when another useful update will arrive. The sales manager cannot later prove which internal state the message represented.

A useful solar sales update is a small release from the project record. It states what the company knows now, how it knows it, who owns the next action, which condition controls progress, what remains uncertain, and what event will produce the next message. It never turns hope into a date or an outside party’s pending action into an approval.

This page owns that operational update record. The broader solar sales conversion guide covers funnel and selling activity, while the internal queue guide diagnoses how work gets stuck. This guide begins when someone must communicate one current project state without making it sound more complete than it is.

Why isn’t “we’re working on it” a useful solar sales update?

“We’re working on it” is not a useful solar sales update because activity does not identify the project’s current state, accepted evidence, owner, blocker, next action, timing basis, or uncertainty. The phrase cannot tell a customer what has changed, and it cannot help the internal team reconstruct which facts or commitments the message represented.

Activity and state are not synonyms. A designer can be active while waiting for an account boundary to be resolved. A permitting coordinator can be active while the submission remains unaccepted by the receiving authority. A buyer can be comparing supplier information while no item has been technically approved. The motion is real, but it does not answer the customer’s decision.

The phrase also hides the subject. Who is “we”? What is “it”? The sales rep may mean that a request is in a queue. The design owner may mean that a revision is under review. The customer may hear that the proposal is nearly complete. Every listener supplies a different missing noun.

Digital.gov describes plain language as clear and easy to understand and says content should be created, designed, and tested for its specific audience. That government digital-content context does not prove that a solar customer understood an update. It supports a narrower practice: write the status for the decision the recipient needs to make, not for the sender’s desire to close the conversation.

The internal damage appears on the next update. If the first message was not tied to an active revision and source state, another rep may send a contradictory statement. One person sees “proposal in progress” in the CRM, another sees “waiting for usage clarification” in a design queue, and a third sees an old PDF marked final in email. The customer communication becomes a fifth project state rather than a faithful view of the current one.

NASA describes configuration management as making product state known, distinguishing versions, controlling and tracking baseline changes, and keeping products consistent with information about them. That is a process analogy, not a prescribed solar system. It explains why an update should point to the active project version instead of floating free in a message thread.

The repair is not a longer paragraph full of project vocabulary. A useful update can be brief if every sentence carries a controlled field. “Design review is open against revision C; the design lead is resolving the meter-scope conflict; we will update you after that decision is recorded” gives a state, version, owner, blocker, and trigger without inventing completion.

What should a useful solar customer update include?

A useful solar customer update should include the identified project, active revision, current state, supporting event or evidence, completed work, open condition, responsible owner, next action, timing basis, uncertainty, customer action, next-update trigger, and escalation path. The message should reveal only what the recipient may receive and only what responsible owners have accepted.

Build the update from fields before writing prose. Free-form writing invites the rep to smooth over gaps because a complete sentence feels better than an incomplete record. A field can remain explicitly unknown. The message then explains the consequence of that unknown rather than hiding it.

Project and recipient identity

Name the project, site, account, request, or proposal revision clearly enough that the customer and team know which work the update describes. For portfolio, commercial, or multi-meter customers, a company name alone may be insufficient. The record can include the site identifier, account, meter group, proposal label, or customer reference used by the current process.

Confirm the recipient and their role under the company’s applicable communication, privacy, contract, and account rules. A facilities contact, property owner, tenant, finance reviewer, lender, general contractor, and installer contact may be entitled to different details. Do not solve access authority through guesswork because the message feels routine.

NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk while protecting individuals’ privacy. It is not a law, consent rule, recipient authorization, retention period, or compliance finding. The company still needs a responsible process for deciding who may receive which project information through which channel.

Current state and source event

Choose a state that represents a decision or recorded event, not a feeling. Examples might include request received, intake returned for evidence, design accepted, technical review open, revision required, customer decision pending, external submission recorded, response received, or release approved. Each company defines its own vocabulary and authority.

For every state, retain the event that supports it. That could be an accepted request, reviewer disposition, customer response, submission receipt, supplier response, signed document, site record, or superseding revision. The source proves the status within its boundary. A submission receipt proves submission, not acceptance or approval.

NASA describes technical assessment as monitoring progress through periodic reviews and technical indicators and says the resulting status information supports technical decisions. The source prescribes no solar measure or update schedule. Its useful analogy is that status comes from reviewable indicators and events, not from the volume of activity.

Completed work and open condition

State what became complete since the previous released update. Use a specific event: customer evidence received, site record reviewed, design revision issued for review, reviewer comments consolidated, application transmitted, supplier response recorded, or another company-defined milestone. Avoid calling a task complete when a downstream owner still must accept it for the stated purpose.

Then state the open condition that controls the next transition. It may be missing evidence, conflicting information, technical review, customer choice, commercial approval, external response, field confirmation, equipment information, or document correction. Name which output the condition blocks and which work can continue.

Owner and next action

The work owner and communication owner can differ. A technical reviewer may own the project decision while sales owns the customer message. Record both. Sales should not rewrite the technical state to sound simpler, and the technical owner should not assume someone else will translate a returned exception for the customer.

Write the next action as an observable verb with an object. “Follow up” is weak. “Sales will ask the customer to confirm which meter belongs to the proposed scope” is reviewable. “Engineering will review the revised equipment input against the active design” is reviewable. The update does not need to expose internal detail that the recipient should not receive.

Timing basis and next-update trigger

Use an accepted date only when the responsible owner and current evidence support it. If a reliable completion date is unavailable, name the condition that controls the date and commit only to a customer update event the company owns. An update trigger can be a recorded reviewer decision, receipt of requested evidence, external response, scheduled internal review, or escalation threshold under company policy.

Do not turn the next-update date into a project-completion promise. “We will update you after the technical review meeting” describes communication. “Your proposal will be complete after that meeting” claims an outcome that may still depend on the review.

Uncertainty, customer action, and escalation

Name material uncertainty beside the affected statement. A date may depend on an unconfirmed scope. A production scenario may depend on usage evidence. A technical response may depend on site confirmation. An external review may have no company-controlled completion date. State what is known, what remains open, and which conclusion is unavailable.

If the customer must act, request one clear item and explain why it changes the next state. Avoid a broad “send everything you have.” If no customer action is needed, say so. Customers should not have to infer whether silence from them is blocking work.

Escalation is a controlled route, not dramatic language. Identify the condition, owner, and permitted decision. Escalation may occur when states conflict, an accepted internal date is at risk, a customer commitment lacks an owner, a privacy or contract question appears, or an outside dependency passes an internal review condition. It should not manufacture authority that the project lacks.

How should a solar update handle blockers and unknown dates?

A solar update should name the blocker, its effect, the owner, the action underway, and the event that changes the state. When no reliable completion date exists, say so plainly and give the next customer-update trigger the company controls. For outside dependencies, report submitted and received evidence without predicting approval, delivery, inspection, funding, or interconnection.

Teams often fear that admitting uncertainty will sound disorganized. The opposite problem is easier to verify: a confident date with no owner or basis becomes a commitment that later teams must explain. A bounded unknown is operationally useful because it identifies what must happen before a stronger statement becomes available.

Separate internal blockers from external dependencies

An internal blocker belongs to a company owner. Examples may include an unresolved scope question, incomplete review, conflicting artifact, missing approval, or unassigned task. The update should name the responsible role and internal action. Do not hide an internal ownership gap behind “waiting on the process.”

An external dependency belongs to another party’s process or decision. The company may still own submission quality, evidence requests, response logging, follow-up under policy, customer communication, and escalation. Report those controlled actions. Do not predict the outside party’s conclusion or timing unless a current, authoritative source supports the statement and the responsible owner accepts its use.

Use a due condition when a due date is unsupported

A due condition explains what must become true before the work can advance. It may be “after the meter scope is confirmed,” “after the responsible reviewer accepts the revision,” or “after an external response is recorded.” The condition should have an owner and a review path, or it becomes another form of waiting.

Pair the condition with the next communication event. For example: “A completion date is not yet supported because the site-scope question remains open. The design owner is reviewing the supplied plan, and sales will update you after that disposition is recorded.” The sentence does not sound dramatic. It gives the customer something real.

Escalate contradictions before writing around them

If the CRM, design queue, project record, email, and customer statement disagree, do not choose the most favorable status. Preserve the conflicting states, identify the authority for the affected decision, and restrict the customer update until the conflict is resolved or expressed accurately.

An escalation record should contain the conflict, sources, affected message, current restriction, owner, requested decision, and customer-update consequence. The customer may still receive a short message that a specific review is underway. The internal record must show why no stronger statement was released.

Which solar status-update failures create hidden commitments?

Solar status updates create hidden commitments when they convert activity into progress, forecasts into accepted dates, submissions into approvals, drafts into current artifacts, or external dependencies into company-controlled outcomes. Other failures include conflicting channels, missing owners, stale recipient lists, buried uncertainty, blame, and automatic messages triggered by a status nobody verified.

The message does not need the word “promise” to create an expectation. “Everything remains on schedule” implies a current schedule basis and accepted exception state. “The permit is in progress” may imply the authority accepted it when the record only proves an internal draft. “Your equipment is being arranged” may imply availability or allocation that procurement has not confirmed.

The FTC’s advertising FAQ for small businesses says United States advertising must be truthful and non-deceptive and objective claims need evidence. That is general guidance, not legal advice or approval of a project update. The operational lesson is limited: bind objective customer-facing statements to current evidence and route legal questions to the responsible reviewer.

Failure: translating every state into good news

A returned design request becomes “final checks.” A rejected document becomes “minor revision.” An unknown schedule becomes “moving ahead.” The rep may intend to protect the relationship, but the euphemism strips away the condition the customer needs to understand.

Use neutral state language. A revision can be open without being catastrophic. A customer action can be needed without blaming the customer. An external response can be pending without implying that the company controls it.

Failure: giving a date because the message feels incomplete

A date is not decorative punctuation. It needs a source, scope, owner, assumptions, and change process. If any controlling condition is unresolved, state the limitation and next-update trigger. Do not move an unsupported completion date into the future every time the customer asks.

Failure: sending the right update from the wrong revision

A technically accurate sentence about an old proposal can still mislead. The layout, equipment, usage scenario, price, finance inputs, review state, or customer decision may have changed. Every update should point to the active project and artifact revisions that support it.

Failure: letting channels disagree

Email says review is open, the portal says complete, the CRM says proposal sent, and the rep says approval pending. Customers and teams then choose whichever status serves the immediate conversation. Define which project record is authoritative and how each channel receives a released update.

Failure: exposing internal detail without recipient review

More detail is not automatically more transparent. Internal technical notes, commercial deliberation, personal data, supplier conditions, other customer information, privileged review, or staff commentary may be inappropriate for a customer message. Release only the fields the recipient should receive, phrased for the decision they face.

Failure: automation that outruns the underlying event

A message trigger may fire when someone moves a card, uploads a draft, or selects a status to clear a queue. If that action does not represent an accepted project event, the automation scales the error. Test every trigger against the source event, revision, exception route, recipient, and rollback behavior.

The customer-commitment handoff guide goes deeper on promises that must survive into delivery. This page stops earlier. It makes sure a routine update does not create a new commitment by accident.

How should a solar sales team build the update workflow?

A solar sales team should build customer updates as controlled releases from the current project record. Capture the update trigger, identify the active revision, obtain state confirmation from the responsible owner, resolve conflicts, draft from required fields, review claims and recipients, release one version across channels, and preserve the superseded message plus the next-update event.

The workflow needs a route back from sales to the state owner. Otherwise the communication owner will fill gaps with interpretation. It also needs an exception for urgent corrections, because a wrong message should not remain active while the usual review meeting approaches.

1. Define the update event and audience. Record why an update is due, which customer decision it supports, who may receive it, and which channel will carry it. A routine cadence, customer question, state change, missed internal condition, returned review, external response, or correction can each trigger a different message.

2. Freeze the active project and artifact identities. Name the project, site, account, request, design, proposal, or submission revision that the update describes. Mark prior customer-facing versions as historical so the writer cannot quote a stale state by accident.

3. Request state confirmation from the responsible owner. Ask for the current state, source event, completed action, open condition, next action, timing basis, uncertainty, and escalation need. The owner confirms only the decisions within that role’s authority.

4. Reconcile conflicting sources. Compare the authoritative project record with CRM, design queue, portal, email, attachments, and the latest customer statement where applicable. Preserve conflicts and route them to the authorized decision owner. Do not select a status merely because the message is due.

5. Draft from the required update fields. Write current state first, then the meaningful change, next action, controlling condition, uncertainty, customer action, and next-update trigger. Remove internal jargon and any statement the evidence does not support.

6. Review claims, commitments, recipients, and limits. Technical, schedule, commercial, privacy, legal, contract, finance, permitting, utility, procurement, or other responsible reviewers confirm affected statements. Check that the message does not turn a pending action into completion or disclose information outside the recipient’s scope.

7. Release one identified update across controlled channels. Store the final text, release time, sender, recipients, source revision, approvals, and channel destinations. Where a portal or CRM displays status, update it from the same released record or flag the difference visibly.

8. Register the next trigger and supersede the old update. Name the next customer-update event, owner, and escalation condition. When the state changes, create a successor instead of editing history. If the prior message was wrong, issue a clear correction and preserve both records.

AHRQ describes flowcharts as visual representations of process steps and lists uses including examining handoffs and identifying responsible people, groups, or departments. That healthcare workflow analogy prescribes no solar process or result. It is useful for exposing exactly where state ownership passes to communication ownership and back.

The design request workflow can supply the active revision and open-condition record upstream. The value-adding follow-up guide addresses a different job after a proposal: commercial messages that help a buyer think. An operational status update should not be disguised as a sales prompt.

Copy-ready solar customer update record and message

Use this copy-ready operating asset as a starting point. Adapt the fields, approval route, customer language, recipient rules, channel policy, schedule treatment, and retention requirements to the company and jurisdiction. The internal record carries more detail than the customer message because the team must preserve why each sentence was safe to release.

SOLAR CUSTOMER UPDATE RELEASE RECORD

Update identity
- Project, site, account, or request ID:
- Update record revision:
- Trigger for this update:
- Prepared by and time:
- Communication owner:
- Intended recipients and roles:
- Approved channel or channels:

Active project state
- Current stage and state:
- Active design, proposal, application, or project revision:
- Source event supporting the state:
- Source issuer, location, and time:
- Work completed since the last released update:
- Prior update superseded:

Open condition
- Blocker, dependency, or unresolved question:
- Output or decision affected:
- Internal or external classification:
- Work that may continue:
- Work or claim restricted:
- Responsible decision owner:

Next action and timing
- Next observable action:
- Action owner:
- Acceptance or closure condition:
- Supported completion date, if one exists:
- Source and owner of that date:
- If no date is supported, controlling due condition:
- Next customer-update trigger:
- Communication owner for that trigger:

Uncertainty and escalation
- Facts known:
- Facts unknown or conflicting:
- Assumptions visible to the customer:
- Escalation condition:
- Escalation owner and permitted decision:
- Correction route if the released update becomes wrong:

Release review
- Technical statements reviewed by:
- Schedule statements reviewed by:
- Commercial or contract statements reviewed by:
- Privacy, legal, or recipient review:
- External-party statements checked against:
- Product or automation statements checked against:
- Final approver and time:
- Released message location:

The customer-facing message can follow this copy-ready structure:

Subject: Update on [project or request]

Current state
[Name the active stage and the evidence-based event now recorded.]

What changed
[State what became complete or different since the prior update.]

What happens next
[Name the next action and the responsible company role.]

What controls timing
[Give the accepted date and basis, or name the condition that must be resolved before a date can be accepted.]

What we need from you
[Request one specific action and explain its effect, or say that no customer action is needed now.]

Next update
[Name the update date or event the company controls, plus the communication owner.]

Correction and questions
[Give the approved contact and correction path.]

The template is deliberately calm. It can carry progress, a blocker, bad news, an unavailable date, or a correction without changing its structure. The team does not need a positive-sounding version and a problem version. It needs one record that respects the current state.

Illustrative workflow: design review returns one unresolved input

This illustrative workflow is not a customer case. It contains no claimed response time, conversion result, trust effect, schedule outcome, approval, production figure, financial result, or product performance.

A customer asks whether the proposal will be ready for an internal discussion. The CRM says “design in progress.” The design queue shows that a preliminary layout exists, but review found that the supplied usage record may belong to a different meter than the stated project scope. The proposal file in email was generated before that conflict appeared.

Sales could reply that final checks are underway. That would imply progress toward an accepted proposal while the input controlling the scenario remains unresolved. Instead, the communication owner opens an update record against the active design request and asks the design owner to confirm the state.

The design owner records: preliminary layout prepared, usage-to-scope conflict open, proposal release restricted, customer evidence needed, design review to resume after identity confirmation. Sales checks the intended recipient and asks for one specific confirmation about the relevant account. The company has no supported proposal-completion date because the controlling input is unresolved.

The released customer message says that the preliminary site work has been prepared, review identified a question about which usage account belongs to the requested scope, and proposal release is paused until that question is confirmed. It names the exact evidence needed and promises only another update after the response is reviewed. It does not say the design is almost done.

When the customer responds, the evidence enters the project record. The responsible owner decides whether it resolves the conflict and records the successor state. Sales issues the next update from that decision. The first message remains historical, so a later reviewer can see why no completion date was given.

Where does SurgePV fit in a customer-update workflow?

SurgePV can support the project inputs and outputs that sit beneath some customer updates. Its verified scope includes roof modeling, layout, shading, energy and financial modeling, electrical workflow support, BOM output, and proposal generation. It does not establish CRM status, automatic customer messaging, recipient permission, schedule control, outside-party action, communication approval, or update accuracy.

The repository record behind SurgePV’s product scope includes 3D roof modeling and solar array layout. It also includes shading analysis, energy-yield and financial models, electrical-workflow support, bill-of-materials output, and proposal generation. The same record says results depend on source data, assumptions, equipment models, configuration, and review, while responsible external approval remains separate.

A team may use connected project artifacts to determine which design or proposal revision an update references. No retained first-party claim proves that SurgePV owns the customer relationship, records lawful communication permission, identifies the authoritative CRM state, controls a schedule, monitors an authority or utility, or guarantees that an automated message matches reality.

If the company connects project events to customer messages, test representative exceptions before relying on the automation. Include returned design requests, conflicting revisions, missing evidence, changed recipients, withdrawn customer requests, external submissions without responses, corrected approvals, unavailable equipment, manual overrides, duplicated triggers, and messages that need retraction.

The software can make the source artifact easier to locate. Responsible people still decide what the artifact means, what may be said, who may receive it, and which commitment the company can support.

Frequently Asked Questions

What should a solar project status update include?

Include the project and active revision, current state, evidence or event supporting that state, completed work, open blocker, responsible owner, next action, controlling condition, uncertainty, customer action if any, next-update trigger, escalation route, recipient, and release time. Include only details the recipient is authorized to receive and the record can support.

The public message can be shorter than the internal release record. It should still name enough of those fields to answer what changed, what happens next, whether the customer must act, and how uncertainty affects timing.

What should sales say when there is no reliable completion date?

State that a completion date is not yet supported, explain the condition that must be resolved before one can be accepted, name the owner and next action, and commit only to the next update the company controls. Do not substitute a hopeful date, describe an external submission as approval, or hide uncertainty behind “on track.”

A due condition plus a communication trigger is useful. It tells the customer what controls progress and when the company will speak again without pretending that the unresolved decision already has an outcome.

Who owns a solar customer update when another team owns the work?

The company should separate work ownership from communication ownership. The technical, permitting, utility, procurement, finance, or operations owner confirms the current state within that role’s authority. The communication owner assembles and releases the customer message. Neither role should change another owner’s decision, deadline, approval, or project evidence merely to complete the update.

The release record should name both roles and provide a return path. If the communication owner cannot support a sentence, the state owner clarifies or escalates the underlying record rather than approving friendlier wording without evidence.

How should a solar sales update describe an outside-party delay?

Name what the company actually submitted or received, the external party involved, the current recorded state, the action the company owns, the event that would change the state, and the next customer update. Avoid predicting the outside party’s action or implying approval, acceptance, inspection, delivery, funding, or interconnection before evidence supports it.

Keep an internal escalation condition even when the external party offers no company-controlled date. The escalation changes the company’s follow-up, review, or communication route. It does not grant authority over the external decision.

Can solar software send accurate customer status updates automatically?

Software can help connect project inputs and outputs, but an automated message is only as reliable as its source state, mapping, permission rules, exception handling, and review. No verified SurgePV claim establishes automatic customer updates, schedule control, external-party tracking, approval, or communication accuracy. Accountable people must define triggers, test exceptions, and review consequential messages.

Automation is best treated as a delivery mechanism for an accepted event, not as the authority that decides the event occurred. Preserve the trigger, source revision, released text, recipients, and correction path.

Treat every customer update as a release

“We’re working on it” survives because it is easy to send and hard to challenge. Nobody can prove it false, but nobody can use it either.

A released update carries a sharper burden. The current state has a source. The next action has an owner. Timing has a basis or a visible controlling condition. Uncertainty sits beside the statement it limits. The customer knows whether to act, and the company knows what event will produce the next message.

That discipline does more than improve wording. It keeps customer communication from becoming a shadow project record with its own dates, approvals, and versions. When the underlying state changes, release a successor and preserve the history.