Solar1 buyer FAQ
Answers before you scope a solar operations rollout.
Understand what Solar1 is designed to address, how implementation is scoped, and which product or data questions should be settled before a rollout begins.
Product scope
Understand the operating problems Solar1 is designed to address and where evaluation begins.
What is Solar1 designed to help a solar installer manage?
Solar1 is being shaped around the operating record that connects lead intake, project delivery, finance, inventory, and service. During early access, the relevant workflows and boundaries are reviewed with each installer before configuration begins.
Does Solar1 replace every tool our team uses today?
That is not assumed. The assessment identifies which records should live in Solar1, which familiar tools should remain, and where a controlled handoff is needed. The initial rollout is limited to workflows the team can map and validate with confidence.
Can Solar1 support residential and commercial solar work?
Solar1 is primarily evaluated with growing residential installers, while shared commercial workflows can also be assessed. Project types, approval paths, records, and reporting needs are documented before anyone treats a workflow as part of the rollout scope.
Implementation
Learn how workflow discovery, configuration, validation, and rollout planning fit together.
How does a Solar1 implementation begin?
It begins with a workflow assessment covering current records, owners, handoffs, exceptions, and control requirements. That discovery informs a proposed scope, and configuration work starts only after both sides understand what will be reviewed and validated.
How long does implementation take?
There is no fixed schedule before discovery. Timing depends on workflow scope, data quality, integration boundaries, decision availability, and the number of roles involved. The assessment is used to define practical phases and acceptance checks for the specific team.
How are training and team adoption handled?
Training needs are scoped by role and rollout phase rather than treated as a generic handoff. Teams review their configured records and decisions, validate representative scenarios, and identify internal owners before a workflow is considered ready for wider use.
Integrations and data
Set realistic expectations for existing systems, migration scope, ownership, and validation.
Can Solar1 connect with software we already use?
Potential connections are evaluated individually. The assessment documents the systems, supported records, direction of exchange, ownership, failure handling, and reconciliation needs before an integration is included in scope or described as available.
Can our spreadsheet and system data be migrated?
Migration can be scoped after the source data is reviewed. The team decides which active records and history are useful, maps required fields, plans cleanup, and agrees on validation checks. Some older material may be better retained as an archive.
Who is responsible for data quality during rollout?
Data quality is a shared implementation responsibility. Solar1 can help define mappings and review checks, while the installer provides source context, resolves ambiguous records, and names people who can approve results before migrated data is accepted.
Access and commercial evaluation
Understand early-access qualification, pricing inputs, security review, and next steps.
How can our company request early access?
Start with a workflow assessment request. Solar1 will review your company profile, operational priorities, current systems, and decision timeline to determine whether there is a suitable implementation scope for the present early-access stage.
How is Solar1 pricing determined?
Commercial terms are prepared after scope discovery. The quote can reflect workflow breadth, data migration, integration work, rollout phases, training, access requirements, and support expectations. Published evaluation material is not a binding project quote.
Can our team review security and access requirements?
Yes. Relevant access roles, data handling expectations, review needs, and operational controls should be raised during evaluation. Any requirement that affects configuration, hosting, support, or approval must be confirmed in the proposed scope.
Your workflow, not a generic checklist