How to Calculate Manual Solar Proposal Cost

The proposal PDF is the least expensive-looking part of the proposal process.

Behind it, a salesperson cleans the intake. A designer reconstructs the roof and array. Someone checks equipment and modeled output. A manager answers an exception. The proposal comes back because the bill period was wrong. The designer revises the layout after a site note. A new attachment is exported, renamed, uploaded, and explained.

None of those events is unusual. The accounting problem is that they live in different calendars, systems, job codes, and memories. A business owner sees “proposal completed” and tries to estimate the cost from designer time alone.

To calculate manual solar proposal cost, the business has to reconnect those events under one measured boundary.

Manual solar proposal cost needs a wider and more disciplined boundary. The U.S. Department of Energy’s soft-costs research page includes design, siting, permitting, interconnection, financing, sales, general and administrative work, customer acquisition, training, inventory control, and operating overhead among solar non-hardware cost components. A proposal workflow touches only part of that list, but it can cross more roles than the design queue shows.

This guide explains how to measure those roles, allocate shared expenses, calculate rework, validate an illustrative example, and compare a manual baseline with a future operating option. It is an internal cost-measurement method, not accounting, tax, employment, investment, or financial advice. A qualified finance professional should approve the cost definitions and decisions used by the company.

What counts toward manual solar proposal cost?

Manual solar proposal cost includes the labor and outside expenses caused by intake preparation, site and usage review, design, modeling, technical review, commercial assembly, corrections, management exceptions, and release. Shared tools and data need a consistent allocation. Keep opportunity cost, general selling activity, and one-time setup separate unless the decision explicitly requires them.

Start with a causal boundary. Ask whether the cost would exist in the same form if the proposal were not being produced. Designer time usually qualifies. A sales discovery call may serve broader qualification and relationship work, so include only the portion assigned to proposal preparation under the chosen method. General marketing, office rent, or executive time should not drift into the worksheet without an allocation rule approved by finance.

DOE’s solar soft-cost basics describes soft costs as non-hardware costs and names permitting, financing, installation, customer acquisition, supplier payments, and company expenses among them. That category is larger than manual proposal cost. Use it to remember possible cost families, then narrow the ledger to events inside the proposal boundary.

Use these cost classes:

Do not blend booked expense, resource cost, and opportunity cost into one unlabeled total. Booked expense answers what finance records. Resource cost can include allocated employee and shared-system cost. Opportunity cost is a decision model about the value of the next-best use, which requires assumptions and should stay in its own scenario.

The solar project design cost guide addresses what design work can cost at the project level. This article measures the company’s full proposal workflow, including the activities before and after the design task.

Which records are needed before calculating proposal cost?

Use a proposal event ledger, payroll or finance-approved labor rates, subscription and vendor invoices, a proposal-status history, revision and return reasons, and a fixed measurement period. Each event needs a project, role, active time, purpose, output, and cause. Calendar duration alone cannot distinguish work, waiting, interruption, or external review.

The event ledger is the spine. It converts “sales spent time” into a reproducible record without pretending every minute between task creation and completion was active labor.

Record events at the level the business can use:

Choose the measurement period before looking at results. It should be long enough to include normal variation in project type and return cycles, yet short enough that team structure, rates, tools, and definitions remain stable. This article does not invent an ideal duration. Use a period your finance and operations owners can defend.

Define the proposal population as carefully as the costs. Count requested, started, completed, released, abandoned, and returned proposals separately. A cost per released proposal uses a different denominator from cost per started proposal. Both can be useful. Neither should be called “cost per proposal” without the state.

Use the company’s own payroll and accounting records for loaded labor rates. The rate method should state which wage, employer, benefit, paid-time, and allocable overhead components are included, along with its productive-hour denominator. A public salary or job-posting number is not the company’s labor cost.

The U.S. Small Business Administration’s finance guidance says businesses should account for revenue and expenses, recognizes employee and supply costs, and recommends separating recurring and nonrecurring costs in cost-benefit work. Use that bookkeeping discipline without adopting the page’s examples, legal statements, or dollar figures as advice for this calculation.

How do you calculate manual solar proposal cost?

Calculate manual solar proposal cost by summing measured labor by role, measured rework, attributable management or specialist review, allocated recurring tools, per-proposal data or vendor expenses, and any other approved direct cost. Use one documented denominator. Validate every formula with units, reconcile the cost pool to source records, and report unknowns instead of estimates disguised as measurements.

Follow this sequence:

1. Write the cost question. Decide whether you need cost per started, completed, released, or signed project, and whether the view is booked expense or resource cost.
2. Freeze the workflow boundary. List the first included event, last included event, roles, artifacts, and explicit exclusions.
3. Define states and denominators. Name requested, started, completed, released, abandoned, and returned work so the denominator cannot change after the total is known.
4. Capture active labor. Use timers, task events, or another reviewed method. Do not treat elapsed queue time as labor.
5. Approve loaded rates. Have finance document the rate calculation, components, period, and productive-hour basis for each role.
6. Code rework events. Retain the original event and add the correction once, with its initiating cause and output revision.
7. Gather outside cost. Use subscription, data, credit, vendor, and travel records actually attributable to the workflow.
8. Choose allocation rules. Allocate shared period costs across the matching completed or released population, not a convenient forecast with no reconciliation.
9. Separate one-time cost. Keep implementation, migration, integration, and initial training visible rather than burying them inside a recurring unit cost.
10. Validate formulas and units. Hours per proposal multiplied by currency per hour yields currency per proposal. Period cost divided by proposals in the same period also yields currency per proposal.
11. Reconcile the pool. Compare worksheet totals with payroll method, invoices, task records, and proposal-state counts.
12. Report distributions and causes. Show proposal types and return reasons rather than hiding all variation inside one average.
13. Document unknowns. Missing time or invoice allocation remains unknown. It does not become zero.
14. Get finance review. Confirm cost treatment, allocation, and decision use before relying on the result.

Use these formulas:

Role labor cost per proposal = measured active hours per proposal × approved loaded currency per hour

Allocated recurring tool cost per proposal = tool cost for period ÷ proposals in the matching denominator for that period

Manual proposal resource cost per proposal = direct labor + rework labor + management or specialist labor + allocated recurring tools + direct data and vendor cost

If the company measures a whole period rather than a representative proposal, calculate the period cost pool first and divide by the defined state count. This can be more defensible because it includes abandoned and returned work. Keep the individual proposal records so you can see why the average moved.

Proposal work crosses connected technical objects. DOE’s PV system design overview discusses modules, mounting, orientation, inverters, storage, and other technologies in a complete system. The cost ledger should therefore include the real review and revision events that connect site, layout, equipment, modeled output, and customer document. Counting only drafting time cuts the workflow at an arbitrary point.

Illustrative calculation: one manual proposal

Illustrative calculation only, not a SurgePV customer result, industry benchmark, recommendation, or promise. The inputs below were invented as visible worksheet assumptions to demonstrate the method. They were computed by script and are retained in the article run’s validated calculation specifications. A real company must replace every input with its own measured and finance-approved record.

Assume one completed proposal has the following active work and allocated expenses:

The example says nothing about a real team’s performance. It demonstrates why the denominator and labels matter. The tool allocation uses completed proposals in the same month as the cost. The correction is measured as its own event. External data is a direct assumption rather than a derived result. The displayed total is the script-computed sum.

Change the denominator and the question changes. If the month contained additional started proposals that consumed labor but never completed, a company-level cost pool should still contain that labor. Dividing only one representative completed proposal’s events does not capture abandoned work. Use the event-level example to understand the formula, then use a reconciled period dataset for an operating decision.

Do not add an unmeasured “overhead percentage” to the example. If finance has an approved overhead method, declare its components and confirm the same costs are not already inside loaded labor rates or tool allocations. Double counting looks conservative and produces a less truthful number.

Copy-ready manual solar proposal cost worksheet

Create one workbook or database view with a method sheet, event table, cost-source table, state table, calculation output, and exception log. The method sheet should remain versioned so next month’s result does not quietly use a different boundary.

Method sheet

Event and cost table

Summary outputs

Report at least:

• total cost pool for the period;
• proposal counts by requested, started, completed, released, abandoned, and returned state;
• direct labor by role and event;
• rework labor by cause;
• management and specialist review cost;
• tool, data, vendor, and other outside cost;
• one-time implementation or training cost shown separately;
• cost per chosen denominator with the denominator named;
• range or distribution by proposal class where sample quality permits;
• unknown cost fields and records excluded with reason.

Do not force unlike proposals into one conclusion. A preliminary residential concept, a revised site-specific proposal, and a commercial response may involve different evidence, roles, models, and reviews. Use a proposal class field and inspect each segment before applying a general operating decision.

Public data may assist research, but it does not replace project evidence. The U.S. Energy Information Administration’s Electricity Data Browser provides public electricity data. It does not establish a customer’s current account, applicable tariff, contract, or savings scenario. The time spent finding, checking, and applying any data belongs in the event ledger if the proposal workflow caused it.

How do you compare manual cost with another workflow?

Compare a manual baseline with another workflow using the same proposal population, quality rules, cost boundary, state definitions, measurement period, and finance-approved rates. Include implementation, training, subscriptions, integrations, exception handling, review, and remaining manual work. Report observed differences only after reconciliation; do not turn a vendor claim or pilot estimate into guaranteed savings.

Start with the decision, not the product. A business may want more release capacity, fewer avoidable returns, a more consistent customer document, better revision traceability, or lower resource cost. Cost is one dimension. Quality, risk, staff experience, customer fit, and external-review requirements can change the preferred option.

Use a comparison table that preserves the denominator:

The replace-PV-modeling-workflow guide addresses one technical replacement decision. Use this article’s cost method as an input, while retaining model adequacy, review, and project-risk decisions separately.

Do not value “time saved” twice. If lower active hours already reduce labor cost in the calculation, adding the same hours again as opportunity value duplicates the benefit. An opportunity scenario can model additional qualified work or reduced backlog, but it needs an explicit capacity constraint, business value assumption, and separate label.

The revenue per solar lead guide covers acquisition economics. Avoid dividing proposal workflow cost by revenue and calling the difference margin without reconciling installation, equipment, sales, financing, overhead, cancellation, and other project costs. The solar gross margin guide provides the broader margin boundary.

Manual proposal cost calculations fail in predictable ways

The solar margin erosion guide explains other ways project economics can drift. Proposal cost is one controllable component, not a complete explanation of margin.

Missing data deserves its own row. If one role did not record time, report the gap and avoid a final measured cost until the business decides how to handle it. A sensitivity scenario can use a visibly labelled assumption, but it should not overwrite the measured view.

Read the event notes. A high correction cost may reflect weak intake, changing customer evidence, a design defect, a legitimate site discovery, a supplier change, or an external return. Those causes suggest different decisions. One total cannot explain them.

Where can SurgePV affect manual proposal workflow cost?

SurgePV can support connected roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Those capabilities place it inside several measured proposal events. Any cost difference still depends on the company’s inputs, process, project mix, configuration, review requirements, adoption, and observed pilot results.

The National Laboratory of the Rockies (NLR, formerly the National Renewable Energy Laboratory/NREL) describes PVWatts as estimating grid-connected photovoltaic energy production from location and system inputs. The cost point is that model preparation and review depend on identified inputs, regardless of the tool used.

Evaluate SurgePV with the same event ledger used for the manual baseline. Measure intake correction, site and roof work, array design, shading, model preparation, equipment and electrical activity, material output, commercial assembly, review, rework, and release. Retain any tasks that remain outside the product. Include subscription, implementation, training, integration, migration, and exception cost under the approved method.

The verified solar design software workflow provides the product route to inspect alongside the event ledger. Test connected outputs and the remaining manual controls rather than assuming a product feature removes the full event.

The repository verifies SurgePV support for 3D roof work, array layout, shade analysis, yield and financial models, electrical workflow, material output, and proposal creation. That scope identifies workflow events to test; it does not prove that labor disappears. Each output still depends on its sources, assumptions, equipment data, configuration, and review. Engineers, authorities, lenders, insurers, and utilities retain their own approval roles. A written quote must settle pricing, access, implementation, and contract terms.

Software cannot establish the correct payroll allocation, accounting treatment, opportunity value, project requirement, model input, equipment choice, customer statement, or approval. It can change how certain workflow events are performed. The business must measure that change and have qualified owners review the technical and financial conclusions.

Frequently Asked Questions

Should sales time be included in manual solar proposal cost?

Include sales time when the activity exists because the proposal is being prepared, corrected, reviewed, packaged, or explained. Exclude general prospecting or unrelated account work unless the defined cost question includes it. Record event purpose and active minutes so a calendar block does not become an unsupported labor estimate.

How should a solar company calculate a loaded hourly labor rate?

Use a finance-approved method based on the company’s payroll and accounting records. Define which wages, employer costs, benefits, paid time, and allocable overhead are included, the period covered, and the productive-hour denominator. Do not copy an industry salary, divide it casually, and present the result as the company’s labor cost.

Should rejected or abandoned proposals be included?

Include them in the workflow cost pool when the business spent proposal labor or outside money on them. Report completed, released, abandoned, and returned work separately, then choose a denominator that matches the decision. Excluding unsuccessful work can understate the cost of operating the proposal process.

How should rework be counted without double counting labor?

Record each rework event once under the role that performed it, with cause, active time, initiating revision, and affected output. The original work stays in its original event. Rework becomes a separate event. Do not add a generic rework percentage on top of measured correction time unless the methods are reconciled.

Can this calculation prove solar proposal software will save money?

No. The calculation establishes a measured manual baseline. A software decision needs a comparable pilot with the same workflow boundary, proposal mix, quality rules, review requirements, and cost method. Include implementation, training, subscription, integration, exception, and remaining manual work before describing any observed difference as savings.

A useful cost model should survive a skeptical finance review and an operations replay. The reviewer can trace the total to time, rates, invoices, states, and formulas. The operator can see which events created the cost. Once both are true, the business can test another workflow without asking a sales claim to do the work of measurement.