A good demo should follow your real project. It should not follow the vendor’s perfect script.

Most software looks capable when every field is complete and nothing changes.

Solar operations do not work that way.

A design gets revised. The AHJ sends a correction. An inverter is late. The crew finishes only part of the job. PTO holds the final invoice.

Before you say yes to a solar ERP, make the vendor show what happens next.

What is a solar ERP demo checklist?

A solar ERP demo checklist is a structured set of workflows, questions, edge cases, and scoring criteria used to test whether a platform fits the way a solar company actually operates. It should examine the full lifecycle from lead and sold scope through survey, design, permitting, interconnection, materials, field work, finance, PTO, service, and warranty.

The checklist is not a list of module names. It is a proof plan. It tells the vendor which project to use, what events to process, which records should change, what reports must appear, and how the buying team will score the result.

Why do polished ERP demos mislead solar buyers?

A vendor-controlled demo is designed to reduce friction. The sample account is clean. The presenter knows every click. The workflow follows the product’s strongest path. Missing data, conflicting statuses, failed integrations, and awkward permissions are kept outside the frame.

Solar work is full of cross-team dependencies. DOE identifies permitting, interconnection, customer acquisition, suppliers, portfolio management, and workforce activity among the non-hardware processes that influence solar soft costs. A demo that isolates those areas into separate screens can hide the handoffs where cost and delay accumulate.

The latest SolarAPP+ performance review provides a useful illustration of why structure matters. In 2024, 861 installers submitted 37,393 permits through the platform. The report found a typical SolarAPP+ project was permitted and inspected 12 business days sooner than traditional projects and estimated about 18,400 hours of AHJ staff time saved.

Those figures are not an ERP claim. They show the value of complete specifications, automated review, inspection checklists, and consistent records. Your demo should test whether the ERP creates that kind of operating discipline across the rest of the business.

What should you prepare before the demo?

Do not begin with the vendor’s feature list. Begin with the decision your company needs to make. Write three measurable outcomes the platform must improve, such as reducing permit follow-up misses, proving installation readiness, triggering invoices from field evidence, or showing current job cost before closeout.

Then choose two projects. One should be ordinary enough to represent most of your work. The other should contain the conditions that consume management time: incomplete survey data, design revisions, AHJ comments, equipment substitutions, a schedule change, partial completion, and a financial dependency.

Bring these inputs

• A sample customer, property, contract, sold scope, equipment list, payment schedule, and project stage history.
• One survey form, design revision, permit packet, AHJ correction, utility requirement, purchase order, field checklist, and invoice trigger.
• The reports each role currently rebuilds, including active-project aging, material readiness, crew schedule, receivables, cash forecast, and margin.
• A list of critical integrations, data exports, user roles, approval limits, branches, warehouses, and regional controls.

Remove sensitive information and use a controlled copy. The data does not need to be perfect. In fact, realistic imperfections help expose how the platform detects duplicates, handles missing fields, assigns ownership, and records corrections.

Who should attend a solar ERP demo?

Bring the people who own the workflow, not a crowd of passive observers. Oracle’s implementation guidance recommends a cross-functional team with business, operations, finance, data, integration, and change-management knowledge. That principle should begin during evaluation, not after the contract.

• The executive sponsor should define the business outcome, budget, and decision boundary.
• Operations should test stages, ownership, blockers, forecasts, and cross-team handoffs.
• Permitting and interconnection should test requirements, corrections, aging, submissions, inspections, and PTO.
• Procurement, warehouse, and field leaders should test material readiness, dispatch, mobile use, evidence, and exceptions.
• Finance should test invoice triggers, receivables, commitments, labor, job cost, cash, and margin.
• The implementation or IT owner should test migration, permissions, integrations, security, support, and data exit.

Not everyone needs to attend every minute. Keep the core buying team present for the full workflow, then bring specialists into the sections they own. A process owner who asks one difficult question is more valuable than five senior attendees who only watch.

How should you structure the demo agenda?

A serious proof session needs enough time to complete the workflow and discuss gaps. The following 90-minute agenda is illustrative. A broad or complex evaluation may require separate sessions for operations, finance, security, and implementation.

Send the script several days in advance. A vendor may need time to configure fields or load sample data. That is acceptable when the work is disclosed. What matters is whether the final demonstration shows standard configuration, an integration, paid customization, or a temporary presentation setup.

Set three rules before the vendor shares the screen

1. Follow the buyer’s project. The vendor may explain the platform, but the agreed workflow controls the session.
2. Do not reset after an exception. A correction, shortage, or failed integration must remain in the project while the next steps are demonstrated.
3. Label every answer. Mark it as shown live, configurable, documented integration, custom work, roadmap, or unavailable.

The solar ERP demo checklist

The questions below are designed to expose workflow depth. Ask the vendor to show the answer whenever possible. A spoken explanation is useful for context, but it should not replace evidence for a critical requirement.

1. Can the system preserve the sold scope from CRM to project delivery?

Start before the project exists. If the ERP cannot preserve what sales sold, every later screen may be built on a manual handoff.

• Show how a lead becomes a customer, site, opportunity, proposal, contract, and project without duplicate entry.
• Change the system size, equipment, payment terms, or customer commitment before signature. Show the version history and approval.
• Close the deal and show exactly which sold fields, documents, exclusions, adders, and responsibilities reach operations.
• Block project creation when a required contract, deposit, survey input, or approval is missing.

2. What happens when survey, design, or engineering information changes?

A solar design revision is a useful stress test because it should affect several teams. Make the change while the project is already moving.

• Submit an incomplete survey and show whether completeness rules stop design work or merely display a warning.
• Create two design versions, reject one, approve the other, and show which equipment and documents are current.
• Change a module, inverter, battery, or electrical scope. Show the effect on the proposal, permit packet, bill of materials, cost, and crew instructions.
• If a specialist design or engineering tool is used, show what leaves the ERP, what returns, and which system owns the approved result.

3. Can permitting handle requirements, corrections, and inspections as a real workflow?

Permitting is where a generic project board often runs out of depth. Ask the vendor to use a specific AHJ and a correction that changes more than one project record.

• Show AHJ contacts, forms, fees, submission rules, required documents, inspection requirements, and local notes.
• Build a permit packet and remove one required item. Show whether the system catches the omission before submission.
• Enter an AHJ correction, assign an owner and due date, revise the affected documents, and preserve the first submission.
• Schedule an inspection, record a failure, create rework, arrange the reinspection, and update the customer and forecast date.

4. Does interconnection remain visible through PTO?

Permit approval and utility approval are related, but they are not the same workflow. The demo should keep them distinct while showing how both affect schedule, billing, customer communication, and project closeout.

• Show utility-specific requirements, contacts, forms, fees, portal references, and document ownership.
• Track application, review, agreement, utility inspection, meter activity, energization, and PTO where relevant.
• Delay PTO and show what happens to the forecast, final invoice, cash view, customer update, and management dashboard.
• Approve PTO and show the resulting billing, closeout, asset, service, and warranty actions.

5. Can procurement and inventory prove that a project is ready?

A warehouse count is not the same as installation readiness. The demo should connect the approved design to project demand, buying, allocation, delivery, and the schedule.

• Generate material demand from the approved design or bill of materials without entering it again.
• Compare suppliers, lead times, quotations, terms, substitutions, and landed cost before approval.
• Receive only part of a purchase order and show committed cost, available stock, project allocation, and expected delivery.
• Replace an unavailable inverter and show the technical approval, price effect, permit impact, serial tracking, and new readiness status.

6. What does the field team receive, and what comes back?

Field software is valuable when it changes the project, inventory, inspection, billing, and cost records. A mobile checklist that creates another isolated stream of photos is not enough.

• Open the mobile view as a crew member and show the current drawings, scope, materials, customer notes, safety requirements, and checklist.
• Demonstrate low-connectivity or offline behavior, including what users can capture and how conflicts are handled when the device reconnects.
• Record a shortage, damaged item, safety issue, scope change, punch-list item, and required follow-up from the site.
• Complete only part of the installation. Show how progress, labor, material usage, photos, inspection readiness, and invoice eligibility change.

The field leader should ask how many taps, screens, and required fields are involved. Adoption problems often appear in small daily tasks, not in the main dashboard.

7. Can finance trace every number back to project events?

Finance should not wait until month-end to discover what operations already knew. Ask the vendor to create a financial consequence from the project workflow and trace it both ways.

• Trigger a deposit, milestone invoice, or final invoice only after the required operational evidence exists.
• Show purchase commitments, actual material cost, labor, expenses, subcontractors, rework, invoiced revenue, collected cash, and forecast margin.
• Delay a permit, installation, inspection, or PTO milestone and show the effect on billing forecast and cash timing.
• Open a margin variance and drill into the exact purchase, time entry, material issue, change, or repeat visit that caused it.

8. Does the customer and service record continue after PTO?

Many demos end at installation or commissioning. That leaves out the years in which warranty, service, replacement parts, customer communication, and O&M depend on the original project record.

• Show what the customer can see, approve, upload, pay, and ask without exposing internal notes or unrelated records.
• Open the installed asset and find the approved design, equipment, serial numbers, warranties, inspections, documents, and prior communication.
• Create a warranty ticket 18 months later, assign a technician, reserve a part, record the visit, and update the asset history and cost.
• Show service profitability, repeat visits, unresolved issues, preventive maintenance, or O&M obligations where relevant.

9. Can reporting answer the next operating question?

Do not judge reporting by the number of charts. Give the presenter a question your team asks every week and make the platform answer it from the workflow you just completed.

• Which projects are blocked, why, for how long, and who owns the next action?
• Which jobs appear scheduled but are missing permit, material, customer, crew, or vehicle readiness?
• Which completed milestones can be invoiced today, and which expected collections have moved?
• Which active jobs are below forecast margin, and what transaction or event caused the variance?

Then change one filter, save a role-specific view, schedule an export, and drill back to the project. Ask whether business users can maintain the report or whether every change requires vendor services.

10. What happens when an integration or automated action fails?

Integration slides usually show logos and arrows. A useful demo shows field mappings, ownership, failure handling, and recovery. Microsoft’s go-live guidance recommends testing external systems when they are unavailable and validating how that affects the user experience.

• Send a record to a connected system, change it on one side, and show which system owns each field.
• Simulate an authentication failure, unavailable service, duplicate record, or rejected payload.
• Show the alert, error detail, retry process, audit history, responsible owner, and effect on the project.
• Explain who supports the connection when either vendor changes its API, authentication, fields, or pricing.

11. Can the vendor prove permissions, security, and data exit?

Solar ERP may hold customer addresses, contracts, employee information, system designs, financial records, and long-term asset history. CISA’s software-acquisition guidance encourages structured supplier risk questions during procurement. Do not postpone them until implementation.

• Log in as sales, crew, project manager, finance, administrator, customer, and subcontractor roles where relevant. Show what each can view, change, approve, and export.
• Remove a user and show how access, ownership, pending approvals, sessions, and audit history are handled.
• Export customers, projects, documents, tasks, inventory, employee records, transactions, and audit history in usable formats.
• Ask about MFA, SSO, encryption, backups, recovery, data locations, subprocessors, incident notice, retention, and deletion.

12. What will implementation, adoption, and support actually require?

The demo shows a configured environment. Your team still has to reach that state. Ask the vendor to connect every impressive workflow to the work, data, people, and cost required to make it real.

• Which parts are standard, configurable, integrated, custom, or planned, and who completes each part?
• Who cleans, maps, migrates, validates, and signs off active customer, project, material, employee, and financial data?
• What testing, training, adoption, cutover, hypercare, support, and update activities are included?
• What are the acceptance criteria, exclusions, renewal terms, usage charges, custom-work rates, and data-exit obligations?

Microsoft’s testing guidance connects test cases to business processes and recommends clear scope, ownership, entry and exit criteria, issue tracking, and user acceptance. Ask how the vendor will turn the demo script into implementation test cases. That answer is often more useful than another product tour.

Use one messy project to connect the entire demo

The strongest evaluation device is a single project that becomes more difficult as the meeting continues. It prevents the vendor from proving each module with a different perfect record and forces the platform to preserve one version of the truth.

1. Sell a project with a battery, an electrical upgrade, milestone payments, and a customer deadline.
2. Submit an incomplete survey and show the completeness gate and owner.
3. Approve a design, then revise the equipment after the permit packet is prepared.
4. Enter an AHJ correction that changes drawings, materials, schedule, and customer expectations.
5. Delay the preferred inverter and propose a substitute with a different cost and lead time.
6. Schedule the crew, then reveal that one material, one certification, or customer access condition is missing.
7. Complete only part of the installation, record rework, and fail the first inspection.
8. Delay PTO and show the effect on the final invoice, cash forecast, closeout, customer updates, and management reporting.
9. Open a warranty request later and export the complete project and asset history.

Do not ask only whether the system can complete these events. Ask what changed automatically, what required a person, what remained blocked, which user was notified, what reached finance, and what the customer could see.

How do you separate proof from a promise?

Use a proof ladder during the meeting. The exact points below are illustrative, but the categories should remain consistent across vendors.

Screenshots, slides, and verbal assurances may explain direction, but they should not receive the same score as current workflow proof. If a critical requirement is roadmap, the buying committee should decide whether to delay, change scope, accept a workaround, or reject the option.

Use a post-demo scorecard before discussing impressions

A confident presenter can influence the room. Reduce that effect by having each attendee score the demo independently for ten minutes before the group discusses it. Record both the number and the evidence behind it.

Weights should reflect your business. A company losing margin through material mistakes may assign more weight to procurement and inventory. A multi-state installer may prioritize workflow variation, permissions, and reporting. Set the weights before the vendor demo so they are not adjusted to favor the most polished presentation.

Do not average away a failed critical requirement. If the system cannot export your data, support active job cost, control a required approval, or handle a necessary regional process, record that as a decision issue even when the overall score is high.

What are the biggest red flags during a solar ERP demo?

A gap is not automatically a red flag. Every platform has limits. The concern is how the vendor handles the gap and whether the buying team can see its operational and commercial effect.

• The presenter refuses to use your project, changes the agreed script, or replaces live workflow with slides.
• The environment is reset after an exception, so the team never sees the downstream consequences.
• A roadmap feature, partner service, manual process, and current product capability are all described as though they are the same thing.
• The vendor shows module names but cannot connect the approved design to materials, field evidence, billing, and margin.
• Mobile access is demonstrated on a fast connection with no discussion of offline work, conflicts, or required field effort.
• Integration claims stop at logos, while field mappings, failure handling, monitoring, support ownership, and added charges remain vague.
• The team cannot export a complete record or test permissions without administrative access.
• Implementation is quoted as one line with no data assumptions, responsibilities, acceptance criteria, or exclusions.

What should happen immediately after the demo?

Do not end with a vague promise to reconnect. Convert the session into a decision record while the evidence is fresh.

1. Each attendee submits the independent scorecard and names the strongest evidence, largest gap, and one unanswered risk.
2. The buying lead creates a gap log with the requirement, proof level, owner, due date, proposed workaround, cost, and decision impact.
3. The vendor confirms every roadmap, customization, integration, implementation, support, and pricing statement in writing.
4. The team requests references from companies with a similar region, project mix, size, and implementation scope.
5. Critical workflows move into a second proof session, sandbox test, implementation workshop, or contract acceptance test.

A reference call should ask what the buyer had to change, which promised workflow took longer than expected, what survived in spreadsheets, how much internal time implementation required, and whether support resolves operational issues after launch.

How does this checklist help identify the best solar software?

The best solar software is not the platform with the most impressive sample account. It is the platform that supports your critical workflows, handles realistic exceptions, gives each role usable control, preserves the business record, and can be implemented at an acceptable cost and risk.

This demo checklist should be used with the broader Solar ERP requirements checklist, pricing guide, and 30-60-90 day implementation plan. The requirements define what must be proven. The demo provides the evidence. Pricing shows what the evidence will cost. The implementation plan tests whether the company can reach daily use.

How should Solar1 be evaluated in a demo?

Solar1 is being built as a complete solar-specific ERP for installers and EPCs. Its product direction includes CRM, surveys, design workflow, proposals, projects, engineering, permitting, interconnection, procurement, inventory, field operations, HR, payroll, fleet, finance, customer communication, service, warranty, analytics, permissions, and administration.

Solar1 is still under development. Buyers should not treat the mapped direction as proof that every capability is already available. Solar1 should be held to the same standard described in this guide: use a real project, introduce the difficult event, label every answer by proof level, show the affected records, and document the remaining gap.

Make the software follow the job

Take one project your team remembers because it went wrong. Remove sensitive information. Rebuild the timeline from sale through PTO and service. Mark every place where data was retyped, ownership became unclear, a decision waited, or finance discovered the consequence late.

Use that project for every final vendor demonstration. Send the same script. Ask the same questions. Score the same evidence. Do not say yes because the dashboard looks clean. Say yes only when the platform can carry the messy project without forcing your team to rebuild the business around the demo.

Download the Solar ERP Demo Scoring Sheet before the next vendor call, or use this checklist to structure a Solar1 demonstration around one real job.