Overview of offer characteristics

The offer is the central sales artefact in Reonic. It connects you (the installer) to your end customer with a planned, priced, branded document the customer can sign. An offer carries the planning (solar, battery, wallbox, heat pump), the bill of materials, the pricing, the PDF, and the signature, all on one project record. This page maps the whole surface: what an offer is, what states it passes through, what metadata it carries, and how to navigate it in the Portal.

Before you start

• You need the residential Offers module enabled on your workspace, plus an editor-or-higher role. Viewers see the create buttons disabled.
• Most offers grow out of a request, but you can also create one directly (referrals, tradeshow leads, phone enquiries). See Create an offer directly below.
• The split between residential and commercial is by project nature, not by a system-size threshold. The biggest practical difference is that commercial offers are signed off-system rather than through Reonic's digital signature. See Residential vs commercial.
• Every offer carries a project address (the installation site) that is held separately from the customer's contact address. It defaults to the contact address, and you can override it without touching the contact record. This is useful when the install site differs from the homeowner's billing address (a second property, or a contact managing the project for someone else). See Contact vs project address.

What an offer is

An offer is a phase of the same project that started as a request and ends as an installation. The project progresses through three phases (Request → Offer → Installation), and the Offer phase is when planning, pricing, and signature happen.

• Lead — a raw inbound interest signal that has not been qualified yet (typically from the Energyhouse funnel or a connected CRM). Becomes a request once you act on it.
• Request — a qualified project before planning. Lives in the Requests kanban; carries the customer contact, the address, and a rough scope.
• Offer — the planned, priced, customer-ready version of that project. This is what you send for signature. Lives in the Offers kanban.
• Project / Installation — what an offer becomes once it is signed and ready to build. Lives in the Installations kanban.

Pro tip: You can skip the request stage entirely by creating an offer directly, which is useful for referrals, tradeshow leads, or anything that did not come through a structured intake.

Contact vs project address

An offer holds two addresses, and they are independent:

• Contact address — the homeowner's billing or correspondence address, on the contact record.
• Project address — the installation site, where the system actually goes. The map pin and (on directly created offers) the roof lookup all run off the project address.

The project address defaults to the contact address. You can change it on the create-offer window without editing the contact record, so a customer at one address can have a project installed somewhere else (a second property, or a contact managing the project for someone else). The two addresses are kept independent.

The 9-step offer lifecycle

Every offer in Reonic passes through the same 9-step lifecycle, end to end:

1. Create the offer, either by converting an existing request, or by creating it directly from the Offers list. Reonic assigns an offer number, sets the project's address, and lands you on the offer's Basics tab.
2. Plan the technical scope: solar layout (2D / 3D / Quick), battery, wallbox, heat pump. Planning mode is configurable per variant.
3. Simulate the yield and the economics. Reonic produces a 20-year projection of energy production, self-consumption, feed-in revenue, and break-even.
4. Price the offer: line items per component, discounts (global or component-level), optional custom deal value, financing if applicable.
5. Customise the PDF: cover, testimonial, company introduction, per-component detail pages, bill of materials, economics, terms.
6. Finalise and send for signature. Reonic captures a snapshot of the priced offer, emails the customer a signing link, and renders the PDF.
7. Customer signs, digitally on a signing link you send them or on paper (you upload the paper-signed PDF on their behalf).
8. Post-signature. The offer flips to Won and the signed variant locks. On the Finalise tab you can then hand the signed offer off to your back-office and accounting systems using the Send-to buttons for each connected system. (Your connected CRM syncs earlier, at request creation.)
9. Transition to installation. Pick which signed variant the install team will build. The project moves to the Installations kanban.

Note: Steps 4 and 5 (price and customise the PDF) happen iteratively as you build the offer, with no enforced order. Steps 6 onwards are sequential.

Offer states (the deal-outcome axis)

Every offer carries an outcome that tracks how the deal is progressing, independent of which kanban column it sits in:

• Open — default. The offer is in flight; no signature yet, no loss yet.
• Sent for signature — a pending signature request exists. The customer has a live link. This is a sub-state of Open, surfaced clearly in the Finalise tab.
• Signed / Won — the customer signed. The signed variant locks and the offer moves to the Installations kanban.
• Lost — the deal is closed unsuccessfully. Mark lost from the offer card and pick a structured closed-lost reason from a predefined list. The offer leaves the active kanban view, and the record stays.

Note: Lost and Won keep the offer record. Reopening a Lost offer flips it back to Open, and the structured loss reason is cleared when you reopen. If you may need that reason for win/loss analysis later, capture it elsewhere before reopening.

How states change

• Open → Sent for signature — when you click Send for signature on the Finalise tab.
• Sent → Open — when you withdraw a pending signature, or when the link expires.
• Sent → Won — when the customer signs (digital or paper).
• Open → Lost — from the offer card, pick Mark as lost, pick the closed-lost reason, and save.
• Lost → Open — reopen the offer; the loss reason is cleared.
• Won — a signed offer stays signed. To unwind a deal after signature, document the cancellation off-system; you can move the project to Lost, and the signed PDF and signed variant stay locked as contract artefacts.

Note: A signed offer is edited by forking: add a new variant and sign again. The original signed variant is a contract artefact and stays locked.

Variants — multiple options in one offer

A Reonic offer can carry multiple variants (sometimes called "options") that the customer picks between. For example, one offer with:

• Variant 1 — Solar only
• Variant 2 — Solar + battery
• Variant 3 — Solar + battery + heat pump

The customer receives one signature link, sees all variants in the PDF, and signs the one they choose.

Create variants

1. Open the offer.
2. Open the Variants overlay on the offer detail page.
3. Pick Create new variant for a blank slate, or Duplicate on an existing variant to copy it.
4. Name the variant (e.g. "Solar + Battery") and save.

What a duplicate carries

When you duplicate a variant, the new one inherits:

• The full bill of materials (components, line items, payment mode per component).
• The solar layout (modules, strings, parallel groups), copied cleanly so edits do not bleed back to the source.
• Pricing inputs (feed-in tariff, electricity price, post-EEG tariff).
• Financing details and subsidies. Duplicating a financing variant keeps it a financing variant: the duplicate keeps the source's financing provider and mode rather than coming back as a plain cash copy. For a plain cash duplicate, remove the financing on the copy afterward.
• Optional component bundles, re-created on the duplicate but un-ticked (the customer re-selects them).

What resets on a duplicate:

• The customer's optional-bundle selections. The bundles themselves copy, but their ticked state resets to un-selected.
• The signature lock. The duplicate is unlocked even if the source was signed, ready for you to edit.

Pro tip: For a fast "copy with tweaks" variant of a 3D-planned solar layout, duplicate-and-tweak is the right approach. To start fresh on the canvas, use Create new variant instead.

How variant numbering works

• Variants are numbered per-offer (1, 2, 3), and the number appears on the signed PDF as the offer number followed by the variant number (for example 1024-2).
• Every offer keeps at least one variant, so the last variant stays in place.
• Delete a variant once its signature is withdrawn, expired, or signed. While a variant is attached to a live (non-withdrawn) signature, withdraw the signature first.
• You can add variants even after another variant has been signed. Only the signed variant is locked.

Offer metadata

Every offer carries metadata on its Basics tab, distinct from the PDF body. This metadata drives the kanban view, the activities feed, the integrations sync, and your sales reporting.

• **Offer name* — Title shown in the kanban and lists. Defaults to the customer's name (e.g. "Jane Doe"*) if left blank.
• **Offer number** — Assigned on creation or on kanban-drag promotion. The number format is configurable for your workspace.
• **Creation date** — When the offer was first created. Read-only.
• **Modification date** — Bumps on every metadata or content edit. Useful for sorting "most recently touched."
• **Valid until / Validity period — When the offer text says the prices stop being valid. Customer-facing, and appears on the cover via the Show valid-until date** toggle.
• **Deal value (Deal-Wert)** — Expected deal value used for kanban totals, CRM sync, and pipeline forecasting. Independent of the offer's customer-facing pricing math.
• **Background / Hintergrund** — Free-text internal notes. Never appears on the customer-facing PDF.
• **Laufzeit / Next touch** — Customer-relationship cadence date. Not the same as the signature-link expiry.
• **Lead source** — How the customer found you. Set manually; not inherited from the request.
• **Key Account Manager (KAM)** — The user the customer's signature email goes out as. Drives sender identity and CRM ownership.
• **Status / kanban column — Which board column the offer sits in. Drag-drop on the kanban or pick from the Status** dropdown.
• **Outcome* — Open / Won / Lost. See Offer states* above.

Note: "Deal value" (Deal-Wert) on the offer card is not the same as "custom deal value" in pricing. The card field drives the kanban total and CRM sync; the custom deal value overrides what the customer sees as the total price on the PDF. Keep them separate.

Rename, duplicate, delete

• Rename an offer — open the Basics tab, edit the Offer name field, and save. The new name shows in the kanban and lists; the offer number stays the same.
• Duplicate an offer — duplicate variants within the offer (see Variants above). To produce a fresh offer for a similar customer, create a new offer for the new customer and re-pick the same packages.
• Delete an offer — the hygiene path is Mark lost with the appropriate reason. The record stays in your reporting, and the offer leaves the active kanban.

Pro tip: If an offer was created in error (wrong customer, accidental double entry), mark it lost with the reason "Created in error" or your equivalent. That keeps your funnel analytics clean while keeping the record.

Tag offers

Reonic supports project tags on offers: coloured labels you create per workspace, split between Residential and Commercial tabs.

1. Open the offer.
2. On the offer card, find the Tags picker.
3. Click to add an existing tag, or type to create a new one (1 to 25 characters).
4. Save. The picker auto-saves after a short pause.

The tag stays on the project across the request → offer → installation lifecycle. It is not per-phase.

Note: Tags are per-workspace and per-business-domain. A residential tag is invisible in commercial and vice versa. Tags are for your internal organisation only: they stay out of the customer portal and do not sync to your external CRM.

Where offers live in the Portal navigation

Offers have their own home in the Portal:

• Offers list — left nav → Offers (with separate residential and commercial lists). Two views: the kanban (cards in columns) and the table view (rows with sortable columns).
• Inside a single offer — clicking an offer routes you to the offer's tabs: Basics, Components (planning), Simulation, and Finalise (plus a Subsidy tab and France-specific tabs where applicable).
• Multiple kanban boards per offer phase. Your workspace can run parallel kanban boards, each with its own column setup. Switch between boards from the dropdown at the top of the Offers list.
• Quick-planning offers have a streamlined exit. If you built the offer through the Quick planning flow, the Finish planning step carries the same key signature actions as the full Finalise view (withdraw a pending signature, open the signed-offer link, and see the per-variant lock state), so you can send or check a Quick-planning offer without jumping to Finalise.

Filter and search the offers list

The offers kanban and table view supports:

• Search by customer name, address, offer number, or keyword.
• Filter by status column, by tag (include / exclude / off, a tri-state chip), by KAM, by deal value range, by creation date range.
• "Without tags" as a pseudo-filter, which surfaces offers that have not been tagged yet.
• Sort the table view by creation date, modification date, deal value, offer number, or customer name.

Pro tip: Tag-based filtering is the cheapest way to slice your pipeline. Create tags for things you care about ("financing requested", "large project", "follow up after holiday"), then filter on them.

Residential vs commercial

Reonic has two parallel flows for offers:

• Residential — the homeowner flow. Full feature set: digital signature, e-mail signature link, financing partners, country-specific subsidies, multi-language PDF.
• Commercial — the commercial flow, used for light commercial projects (e.g. an installer adding commercial customers to their residential business). Offer and variant logic exists. Commercial offers are signed on paper or via your own contract process rather than through Reonic's e-signature.

Both flows use the same kanban, status, tag, and variant model. The split shows up only in the signature step and in which kanban board you are working on.

Note: If you sell to a commercial customer through your residential flow, the digital signature still works: residential customers all sign the same digital link. Use the commercial flow when the project's nature (multi-building, multi-unit, complex commercial scope) calls for it. A commercial project is signed off-system; the digital signature flow described here is the residential flow.

Offer types — PV, heat pump, wallbox, combined

A Reonic offer can include any combination of:

• Solar (PV) — modules, inverters, strings, parallel groups, full 2D / 3D planning.
• Battery storage — a discrete battery component with its own payment mode. Whether the system is AC- or DC-coupled follows from the inverter and battery you select (a hardware property), set by the components rather than a separate coupling toggle on the variant.
• Wallbox — EV-charging hardware. You can add multiple wallbox units as hardware (by quantity), and one electric vehicle can be modelled for consumption per offer. Fleet / multi-vehicle consumption modelling is a commercial capability.
• Heat pump — heat-pump planning, heat-load, gas/oil baseline comparison. Available on heat-pump-enabled accounts (DE / AT / FR / BE).
• Additional components — non-PV trades work (electrical, scaffolding, civil works) that count in the price but not in the simulation.
• Optional components — add-ons the customer picks at signature time (e.g. "extra battery module if you want it").

The offer's pricing sums across all categories. The simulation covers PV yield math and leaves out additional and optional components.

Currency and VAT

• Currency is set per workspace based on the workspace's country (EUR for DE / AT / FR / BE / IT / ES / PT / NL; GBP for UK; and so on). One workspace runs one currency; to work in multiple currencies, set up separate workspaces.
• VAT handling is country-aware. German offers ship with the German VAT structure (0% on residential PV under the Nullsteuer regime; standard rate on commercial); French offers carry French VAT; Italian offers carry Italian VAT.
• VAT is shown as a per-line and total on the offer PDF, so the customer sees the breakdown.

Multi-language offers (DE / EN / FR / IT / ES / PT / NL …)

Reonic renders the offer PDF in 15+ languages, picked per offer based on the customer-facing language setting on the workspace.

• Customer language is tied to the workspace's customer-facing locale. The offer PDF, the customer portal, and the digital signature page all render in that language.
• The PDF's built-in boilerplate follows the workspace locale, not your personal UI language. All the standard template text on a shared offer or commercial PDF (cover title and subtitle, datasheets, the cancellation form and policy, Terms & Conditions, the signature-with-contacts page, the contact banner, the heat-pump legal condition) is generated from your workspace's locale, the same one your customers see. So if your Portal is in English but your workspace serves German customers, the boilerplate prints in German. If a PDF prints in a different language than expected, check the workspace locale, not your personal account language. Free text you type yourself (cover title, testimonial, customer comment) prints exactly as you wrote it.
• Switching language per offer is typically a workspace-level setting. Talk to your Reonic account manager if you need per-offer language for a specific customer.
• Internal language (the Portal UI you use as an installer) is independent of the customer-facing PDF language.

Reporting and KPIs

Column summaries (number of deals, sum, average, weighted sum, average weighted sum) and conversion-ratio configuration are set up under Configure Kanban boards. The same configuration drives the Offers kanban, the Dashboard's cross-funnel KPIs, and the per-offer activities feed.

Things to know

• A live signature request locks the variant it was sent on. While a request is pending you can review it, withdraw it, or add and edit other variants, but to change the variant that's out for signature you must withdraw the pending request first (that also cancels the customer's link). The customer keeps seeing the send-time snapshot until you withdraw and re-send.
• Re-sending after an edit is communicated off-system. The offer record keeps the latest content, and Reonic emails the customer on signature send, re-notify, and sign-completed. You drive communication for creation, edits, and withdrawals.
• Communicate edits to the customer directly. If you re-send after editing, tell the customer what changed off-system.
• Bookmark a complex filter. If you set up a complex filter on the offers list, screenshot the kanban or bookmark the URL so you can get back to it.
• Lead source starts empty on a converted offer. Set it manually after converting a request.
• Direct-created offers skip the request stage and land in the offer kanban as an offer from day one, with no request history.
• Conversion ratios are per-column and per-workspace, and they keep your custom values. Once you customise them, they stay customised, so tune them carefully.
• Reporting on the closed-lost reason is the load-bearing win/loss input. Mark lost reasons honestly: the aggregate is what tells you why you are losing deals.
• Why prices may be hidden in the component selection or bill of materials. This usually means your price-display mode is set to Grouped by target on the customer-facing view, or your user role does not include pricing visibility. The installer-only local-with-customer mode blanks prices on the rep's own screen only and does not change what the customer sees. Check the offer's PDF settings on the Finalise tab or your role permissions.
• When the simulation runs. The simulation runs once the offer has a complete solar planning (modules placed, electrical scope set) and updates from there, with no "press simulate" button. If the simulation panel is empty, check the Planning tab for missing inputs.
• Custom images are scoped to a variant's planning state. If you re-run planning or duplicate the variant, re-attach the image after major planning changes.
• The Reonic planning service is an optional add-on. Reonic planners do the 3D solar planning work (panel layout, variants, simulation) inside your offer and hand it back to you. It is residential-only and Portal-only, billed per planning. Your Reonic account manager can walk you through the pricing. To commission it, open any offer and use the Solar planning card's request banner and modal. The first request from your workspace requires an admin role; later requests work for any user with the Planning Service right enabled in Settings > Company settings > Users & Teams.
• The order confirmation (Auftragsbestätigung) is created in the Invoicing area after the customer signs, not from a tab on the offer itself. Subsidies attach to the offer, and the order confirmation inherits the subsidy line items from the signed variant.

Need help?

• Step-by-step questions about this flow → contact Reonic support.
• Feature requests / something missing → send your account manager a note with what you would like to see.
• Bug reports → include a screenshot and the URL where it happened in your support email.

Last updated on August 4, 2026