Table of Contents
A request for proposals for a business solar plant gives several contractors the same task. Describe the objective, site, available data, expected result and response format. This helps reveal the proposed solutions, what each contractor includes and which questions still need inspection.
The request does not replace design, legal review or technical verification. The following structure and fictional example are working aids. Actual specifications, procurement procedure and acceptance must be defined for the facility with the responsible specialists.
Start with the task, not a brand list
Describe the problem the plant should solve, such as partly displacing daytime electricity purchases. State operating hours, seasonal shutdowns and expansion plans if known. If backup is needed, identify the loads, desired duration and operating mode separately. Solar panels alone do not establish backup capability.
State whether export is being considered; if undecided, ask for options and necessary checks separately. Do not call a desired capacity final without demand, site and network data. The load-profile sizing guide helps frame the initial task.
Specify what result is expected at this stage: a preliminary estimate, site assessment, design or a defined-scope offer. Different outputs require different inputs and should not be compared as if they were identical. Make the decision stage clear to each participant.
A cover sheet to adapt for your request
Start with a short fill-in block. The brackets identify fields for your team, rather than fixed conditions for every procurement:
- Identifier and revision: [site name], [date], [version].
- Stage deliverable: [estimate, assessment or defined offer].
- Base scenario: [self-consumption], [export], [backup], [phases].
- Appendices: [file], [revision], [confirmed facts or unknowns].
- Response arrangements: [contact], [channel], [response date].
Where a field is undecided, state the clarification needed. Do not convert a preferred configuration into a confirmed site parameter merely to complete the form.
Describe the site and missing data
Provide the address, available roof or land plans, photos, electrical room location and possible access routes. Mark rooftop equipment, planned repair and areas needed for operations or logistics. Distinguish confirmed facts from preliminary plans: photos do not replace an assessment of structural condition.
Identify the building or site owner, known use arrangement and a contact who can arrange an inspection. Do not share confidential material without an agreed channel and access rules. If a drawing is unavailable, list it as open and ask how the contractor proposes to obtain the necessary information.
The business solar documents guide explains the initial package and document route. The request uses that information to give all participants the same task; it does not establish that the documents are sufficient.
Prepare demand and network data
Where available, provide an agreed period of interval data, units, time zone and explanations of gaps. Monthly bills help explain costs but do not show when solar generation coincides with demand. Ask participants to identify data sources and boundaries and label estimated periods.
Share the current single-line diagram and connection documents within the agreed access arrangements. Identify existing power sources, restrictions on production shutdowns and known network changes. If a parameter is unconfirmed, do not fill it with a guess or ask contractors to treat it as final.
Ask them to identify work needing further inspection or coordination. A request can state a desired operating mode, but the final scheme, protection and settings are determined through design for the actual conditions. A generic template cannot establish them for every facility.
Request supply and work boundaries
Separate design, equipment, delivery, unloading, site preparation, installation, electrical work, configuration, testing and document handover. For each group ask participants to mark included, customer responsibility, preliminary estimate or clarification required. A missing row does not mean work is free or unnecessary.
Ask for proposed exact models and quantities and an explanation of substitutions. If a model is not yet selected, the participant should show assumptions and effects on price and timing. A designer assesses critical technical issues; a buyer should not independently confirm electrical compatibility from device names.
For each exclusion, record who is responsible and when it is needed. Roof reinforcement, for example, may sit outside the initial offer while affecting the entire schedule. Ask for the evidence needed to refine the scope rather than inserting an arbitrary contingency for a known task.
Give everyone the same response format
Ask participants to answer the same questions while allowing a separate alternative. The base option should address the shared task and deviations should be explained. Each figure needs a unit, boundary, date and assumption. Allow clarifying questions that may reveal a mistake in the initial request.
| Code | Common question | Response fields |
|---|---|---|
| A. Solution | What configuration is proposed? | DC and AC capacity, exact models, quantities, boundary and assumptions. |
| B. Work | What does each stage include? | Included, provisional, customer responsibility or clarification required; responsible party. |
| C. Generation | How was production estimated? | Data revision, period, time profile, losses and calculation boundary. |
| D. Price | What scope does the amount cover? | Priced items, currency, tax basis, validity and clarification conditions. |
| E. Schedule | What controls the timing? | Stages, prerequisites, access, shutdowns and proposed payment events. |
| F. Handover | What will the customer receive? | Documents, checks, instructions and access; warranties and service separately. |
| G. Deviations | What differs from the base request? | Request row, reason, effects on scope, price, timing and checks. |
Matching codes let the team place responses side by side. Ask whether a blank means not applicable, missing information or excluded work; these are different states. Present an alternative in a separate table referring to the base revision.
After responses arrive, first check whether outputs and scope are defined consistently. The budget comparison example can then help align prices to the same scope. The request itself does not select a winner or guarantee identical technical solutions.
For a combined project with storage, the guide to comparing storage projects provides a separate technical and economic comparison basis.
Describe the result to be handed over
State the expected result of each stage as well as an equipment list. For design this may be an agreed set of deliverables in a defined format; for installation and start-up it may include contractually specified checks, drawings and instructions. Set the actual list and criteria for the system rather than copying a generic template.
Ask participants to describe test conditions, measurement boundaries, inputs and who takes part in acceptance. If a measure depends on weather or plant operations, ask how the proposed method accounts for that. Do not prescribe a universal numerical threshold without technical support.
Agree how observations are notified, who approves corrections and which records are updated after a configuration change. Request a handover list but check it against actual scope. Receiving a folder does not prove every drawing is complete or every test performed.
Agree how responses will be reviewed
Before receiving offers, identify minimum conditions needed to proceed, such as a defined scope, access arrangements or evidence of required competence. Criteria should fit the task and be understandable to participants. Review supporting documents rather than relying solely on promotional claims.
Separately record what will be compared after minimum conditions are met: schedule, work scope, service arrangements and other site-specific factors. If scores or weights are used, agree them in advance and explain the levels. A high total score does not resolve an unanswered critical question.
Do not automatically transfer rules from one public procurement to another procedure. Engage legal or procurement specialists to determine applicable process, criteria and documents. This working structure does not establish a legal tender procedure.
A fictional short brief
Imagine a business operating in daytime on weekdays that wants to assess rooftop solar for direct consumption. It supplies available interval data for a year, a roof plan, existing diagram and shutdown periods. Backup is not requested; export requires separate review. This situation is fictional and describes no actual facility.
Participants are asked for a base configuration, generation estimate with assumptions, scope of work, unpriced items, schedule, price breakdown and handover package. They separately identify conclusions requiring a roof assessment or network clarification. The output is a set of responses in a shared format, not confirmation of technical feasibility.
Suppose participant A offers only a preliminary layout in row B, while participant B includes an assessment followed by a defined offer. Their totals describe different outputs. Ask both to price and describe the same initial stage, showing later work conditionally. The form exposes the mismatch before contractor selection.
If one participant proposes another operating mode, show it as an alternative with changes to price, scope and necessary checks. The business can then avoid comparing two different tasks as if they were one system. Technical, legal and financial questions need site-specific assessment before a decision.
Organize questions and versions
If another supplier is invited later, check that they receive all current clarifications and appendices for the same version. Record the date and channel of delivery and list any documents with restricted access. This helps the team compare responses on a consistent basis.
Identify an owner, question channel, response date and way to send updates. If an answer changes the inputs, provide the same clarification to every participant and retain the version number. Mark which data require protected exchange and who may receive them.
Before comparing offers, check price validity, matching currency and tax basis, timelines and whether the schedule is feasible. Record the reason for each open question and its next action. If inspection is needed, agree its scope, access and the result the business will receive.
A useful request contains the task, list of files provided, response form and open-items register. Have specialists review it, then retain the final version with the proposals. It supports a substantive discussion but does not replace a design or signed contract.
Discuss site assessment and design scope through solar services.