A case study: launching a custom product for solar roof innovator SunRoof

A case study: launching a custom product for solar roof innovator SunRoof

BY Katarzyna Malecka ON AUGUST 18, 2022

Swedish company SunRoof makes solar roofs, combining solar power solutions with a unique roof design. In 2020, SunRoof started to expand into other EU countries – Poland, and Germany – and then to the USA. Its timing was good: the demand for clean energy was already surging, and consumers were increasingly aware of the advantages of energy self-sufficiency.

However, growth wasn’t as smooth as expected. It became clear that roofs, regulations, and customers differ around the world. The sales teams also struggled to prepare offers for customers using Excel and software available separately in every market. SunRoof decided that its immediate need was for a global custom system that would help sales representatives correctly estimate the parameters and costs of solar roofs. It also needed a system flexible enough to embrace cultural differences among customers in different countries.

Because solar roofs are not yet widespread (these are not solar panels installed on a roof, but a solar roof) the software platforms available could only be applied to PV panels installed on existing roofs. It meant that SunRoof needed to build its own software.

Why a custom system?

Firstly, SunRoof needed to be able to optimise the work of sales representatives in different countries. The challenge here was: how to create a piece of software that would both:

• allow sales reps to make an offer to customers quickly;
• allow sales reps to create an accurate calculation, optimal for the customer and the company.

Secondly, SunRoof needed flexibility and the ability to create a system open that could be customised for each market without affecting the global approach. In other words, it needed a system with a global core, but with enabled variations of sales tools in different countries, so the offers could fit particular customers’ needs.

How did we approach the task?

We looked at the sales CRM and then talked with the operations teams (who build the roofs). As there was no need to change or write our own CRM software, we wanted to map problems that arose on the line between the two departments.

We decided to create a platform that could be easily integrated with the CRM and automatically transfer data about sales leads, so that sales representatives enter data specific to solar roof construction. We also decided to add our own PV Designer (description below), so the sales reps could sketch the roof, estimate the number of panels and energy production, and create a reasonable offer based on those and other inbuilt parameters.

We also needed a specific, custom-per-country design of the offer (the cultural differences are described below). It might seem easy, but the software available on the market was not flexible here, especially on the legal documentation, and it was a blocker for our sales teams.

Last but not least: our sales teams needed an error-proof tool that would be fast to operate. Before we launched our platform, offer creation could take anything from six hours to two days if the roof was complicated. Training sales reps also was not easy, as it also involved people from other departments.

What did we build?

The system we built is called SunRoof Business Panel. Creative, right?

Below are some of the significant innovations the system delivers for SunRoof.
1. Localisation data vs accuracy and optimisation
We use Google Maps to check if the address data provided by the customer (or inserted by the sales reps or partners’ sales reps) is valid. This must be accurate for various reasons:
a. we have regional sales teams, so the data should be assigned to the correct regional sales team in our CRM;
b. we also have regional roofing teams, so we also need to have leads that convert into projects assigned to the correct teams also;
c. last but not least: we need to optimise our routes. By knowing the correct construction address from the beginning of the project, we can organise our logistics by assigning a warehouse and planning the transport of materials to the construction site in the most efficient way.

Business Panel screen – example

Address data is crucial here not only to be sure we are preparing an offer for the correct house, but also for future planning (e.g. delivery of materials from warehouse to the construction site. We optimise routes thanks to the correct and detailed location – usage of Google Maps).

2. PV Designer vs complicated CAD software
An additional challenge was a need for a piece of software called PV Designer.
PV Designer software enables a roof outline to be drawn with accurate measurements and angles, specifying setbacks and keep-out regions, incorporating additional parameters, and using heuristic calculations to position solar panels and calculate energy production.
We incorporated much simplified and automated versions of this CAD software. We took the crucial elements and removed other complicating factors so that sales reps could use the tool without many training days. As an underlying mechanism, we used Google Maps, but with a custom (grey) background, as it is easier to focus on the drawing. Options are limited to only basic ones; and we built in parameters so sales reps can’t go wrong.

Here are examples:

PV Designer screen – example

3. Translations vs localisation
The system is available in English, Swedish, Polish and German – thank you, Google Translate! Yes, that’s correct. We used Google Translate to get four language versions of our system that helped us to prepare language files (.json), and corrections needed by native users of all languages were minor.

4. Custom offer designs vs customers’ needs
Our first approach was to have unified templates for the offers and all communication with customers. It was the wrong approach, at least for pricing. Customers differ (not a surprising discovery), so their expectations regarding sales process, communications, and even design – vary (and that was a surprise). So the need here was for better localisation – which we did in the tool we built.

Why did we choose Scrumban over Scrum to organise the development process?

At first, we organised our work using the Scrum approach. But after a few Sprints, we discovered that we needed a little more flexibility – and many fewer meetings.

We decided to introduce Scrumban*, a nice hybrid of Scrum and Kanban. By extracting the best of both Agile methods, our Scrumban team became more flexible in adapting to change. Scrumban also focused us on the continuous improvement aspects of Kanban, encouraging short Kaizen meetings like training sessions, knowledge sharing, and waste elimination as options for learning opportunities and process improvements.

*I strongly recommend looking closely at how the IT team works. Scrum, in our case, was consuming a lot of time for “rituals”. Ditching a lot of obligatory Scrum meetings, we felt freer and happier, and we started to have more time to do the actual work. We have achieved our goals and have good relations – within and outside the team. I know it can be shocking, but I think Scrum is not agile anymore (author’s note).

Below are the steps we took, using the Scrumban approach within the IT team:

• focus on basic requirements from only one market for MVP, no long documents with descriptions of requirements, keeping it simple as possible;
• UX/UI decisions based on straightforward sketches or examples from other systems, no hi-fi wireframes, no interactive prototypes, no detailed designs by graphic designers;
• first functionalities and speedy launch of MVP, connected with extended tests with internal users – here, we didn’t save time. We wanted users to give us honest feedback;
• only after launching MVP – custom requirements per country, extended development, UX improvements.

Thanks to this organisational change, we could develop the needed system pretty fast and without endless meetings.

Results

In summary, our system now provides:

• On average, sales reps can create an offer in under 15 minutes. There are some differences between markets, for example, in Sweden, it can take around 5-10 minutes, while in Poland, you can squeeze and generate a nice looking and accurate offer within 6 minutes, even adding a loan offer;
• Sales reps do not need to learn too many specialised and technical aspects of roof construction to be able to create a correct calculation;
• Sales reps can draw a first drawing of the solar roof in our PV Designer, with critical parameters included, so it is easier to visualise how PV panels will fit and where they could be complementary surfaces;
• Sales reps can estimate energy production based on official EU sources, also considering roof shapes and localisation of the building;
• Created offers have a nice, easy-to-understand design, so customers understand what is included and what process of construction awaits them;
• Sales reps can generate automated contracts based on the data inserted, meaning less manual work;
• Sales reps can handle the process from the beginning (leads) to the end (sales confirmed by e-signed contract).

Our system means a better customer experience, as sales reps can provide a clear offer with no hidden costs or information.

The Business Panel gives us the flexibility we didn’t have before and lets us make the adjustments we need a lot faster – because we own the product. – Toni Lattinger, Head of Sales, Sweden.

Lessons learned – cultural differences

When we decided to develop software for teams across countries, we thought we needed to keep it unified to have control over the product. This approach was mistaken, as we learned pretty fast. One team grasped the software and wanted to improve it with more features, while another team was just observing but not using the system at all. When we saw this, we understood we had a problem.

Says Aleksandra Popek, IT Product Manager at SunRoof: “Every team, every person – reacts to ‘the new’ differently. It applies to everything that is new – so, of course, it also applies to our software. In SunRoof, we have teams in four countries, and not only the barrier was that the system is something new, but also we had to face cultural differences, sometimes language barriers, and even distance between us, compared with challenges that remote teams face. To launch our Business panel was quite a challenge!

“We have learned a lot. In Sweden, for example, we noticed we had to go in person and work with the team to understand their needs better; the team here also wanted to participate in the decision process for requirements. In Germany, face-to-face training, rather than online training, was crucial. In Poland, we needed to find one person responsible for decisions. Only then could we choose which requirements were important and which were just nice-to-haves. Teams also wanted to discuss some details in their native language rather than English, even if it happened during a meeting where not everybody knew the language. I let it be. Team comfort and good communication are always the best choices. In general, I believe the IT team should be close to the teams and business owners. Without it, it is nearly impossible to understand the needs. Knowing the needs is not enough; you also need to understand the background.”

To wrap up

The costs of building our software are comparable with the prices of systems we would have needed to buy for each country’s market, as they all differ. From now on, we will save money when we start to introduce partners to our system. We own the software so there will be no need for additional licences; partners can use our system for free. A win-win situation.

And finally

I believe solar energy is the future. It is green-clean, and makes us less dependent on coal, gas, or oil; It is helping to save the planet and helping to change geopolitics. It’s fantastic to be a part of it!