Scope of Work: Desired Scope and Solution Scope
Your company sells a given set of services to its customers. Each service you sell has a type, and the scope is a list of all the types included. Types of services include, for example:
- Grid-tie PV
- Energy Storage System
- Main Panel Upgrades
- Heat Pump Water Heater
- Array Remove and Replace
- Defective Equipment Replacement
The scope of work for any given job is defined by the types of services included AND the specifics of each service. The specifics of a service include the makes and models of equipment and the other details. But regardless of the equipment you install, it's the type of service that defines the job processes you need to undertake. For example, sale and install of a new PV system requires my company to do A, B, and C while a main panel upgrade (MPU) requires X, Y, and Z. I may install entirely different equipment in one PV system vs another, but its the fact that its a Grid-tie PV System that drives my workflow.
Note that besides PV systems, SolarNexus supports the sale, installation, and support of any other type of systems and services. SolarNexus provides multiple default values (e.g. Grid-Tie PV, Energy Storage, etc), but you may have additional custom values defined in your account reflecting the types of services your company sells. (See here for how to define custom service type values.)
Selecting the Desired Scope for a New Lead
On a new project lead, a customer will very likely communicate to you the services that they desire from you. On the Job Screen, SolarNexus provides a default field called "Desired Scope" where you can multi-select from a list of service types that your company provides. For example, for a customer interested in only PV, you would select Grid-Tie PV, while for a customer potentially interested in both PV and energy efficiency, you would select both Grid-Tie PV and EE (two separate service type values). Note that this desired scope is merely preliminary. The actual scope of work on any eventual job is defined by the services on the sold solution.
Solution Scope
While the Desired Scope field is intended to capture the prospective scope of a potential project, you might wind up proposing multiple solutions to the customer with different scopes. For example, if a customer is interested in PV with battery backup, you might propose one solution with PV-only and one solution with both PV and a battery backup.
The set of services you add to a solution defines the solution's scope. The solution scope values can be output to your proposal
Note: Legacy Solution Scope
Prior to SolarNexus' introduction of service offerings in 2017, SolarNexus used a "Solution Scope" field on each solution that allowed users to add a series of text values that helped define the scope of work, primarily as a way to define work included other than PV. That field was deprecated, but older projects still have this data which is still important and relevant.
Using Scope for Management
Specifying the customer's desired scope helps you to more effectively track and manage your leads:
- On the Sales screen, you can filter by Desired Scope to see only the leads/opportunities with the selected service type. For solutions that have been proposed to customers, you can use the Proposed Scope filter.
- You can define project milestones that only apply to leads/projects with a certain scope. For example, you might have a step in your sales process that applies only to leads interested in energy efficiency, so you could define a milestone relevant to leads with the EE scope. That milestone would not be included in the process for leads without EE.
Scope values are also helpful in managing projects post-sale:
- On the Installs screen, you can use the Scope filter a selected service type to see only the sold projects that includes that service type.
- You can define post-sale project milestones that only apply to projects where the sold solution has a certain scope. (see the Project Inclusion section of the article on Administration - Project Milestones)
- Secondary milestone predecessors can be enforced based on scope values, providing additional control over the workflow in your projects.
Scope in Reporting
- Scope is a key attribute on which you can When defining custom reports, you can add Project Scope as a filter, and can also display the Project Scope in a report column.
- When defining custom reports, you can add Sold Solution Scope as a filter, and can also display the Sold Solution Scope in a report column.
Transition notes from Project Scope behavior prior to Nov 8, 2017:
- Previously, SolarNexus only allowed you to select a single scope for a project. Thus, to indicate that a lead was interested in both PV and EE, you would need a combo scope, like "Grid-Tie PV + EE". This made filtering projects on the Sales/Installs screen difficult -- if you had both "Grid-Tie PV + EE" and "EE only" as possible scopes, there would be no way to see all "EE"-related projects in one shot. With support for multiple scopes per project, you no longer need combo project scopes. Instead, you should define each possible project element as a separate project scope value in your account, and simply select all relevant scopes when entering a new lead. Combo scopes in most accounts have been automatically converted to multiple individual scopes where possible.
- The scope filter on the Installs screen now filters on the scope of the sold solution, not the project scope. For example, if the initial scope for a project included both "Grid-Tie PV" and "Battery Backup", but the final sold solution only included "Grid-Tie PV", then filtering the Installs screen by "Battery Backup" will not return the project.
- The scope for all existing solutions as of Nov 8, 2017, was automatically set to be the same as the project scope. You can update the scope values for existing solutions by clicking the Edit icon at the top of the solution header.
- If you use different solution templates for different types of projects, you can edit the solution template to specify the default scope. Any new solutions created from each template going forward will use the respective template's scope by default.