Multiple Estimates.

RoofLink is a roofing CRM. A rep can go from knocking a door to inspecting a roof, building an estimate, sending a contract, collecting payment, ordering materials, and scheduling the crew, all in one system.

Leadership asked our product pod to build proposals. We found the real problem sat one step earlier: reps couldn’t create a good, better, best set of estimates in the system at all.

The business problem

RoofLink was losing customers to competitors. Estimates drove 8.6% of churned revenue, and the top reason for lost sales was “Proposals.”

Why now

The roofing industry was shifting from insurance work to retail, and peak season was weeks away. RoofLink was about to enter its highest volume months.

The user problem

A rep couldn’t show a homeowner more than one price without deleting the estimate he’d just built and starting over. That was 126 actions deep and 12 minutes of sitting in a truck while a sale was being reconsidered, all to present three options on an unprofessional PDF.

This was the first project our team picked up after the acquisition, so we started with very little product or industry context. My PM and I split the stakeholder conversations around what proposals meant to each part of the business. We learned the terminology, workflows, priorities, and constraints, and that’s where we first heard about the estimate problem.

Back together as a product trio, we formed a hypothesis: before building a proposal experience, we needed to understand why customers couldn’t build a good, better, best set of estimates today. That gave us three things to investigate: engineering constraints, a self-serve success metric from Support and CX, and a complicated existing flow.

“We need to be able to sell with options. This is the majority of our customer base. We can’t win this market without GBB.”

Stakeholder

“I need a way to write good, better, best estimates without having to completely delete, rework, and resave the estimate.”

RoofLink customer

I designed a three-column layout with the estimates side by side. It felt right because everything was boxed up cleanly. In validation, users couldn’t find key actions, and the sentiment was “this doesn’t feel right, but I don’t know why, because I like this idea.”

Going over the findings with my product partners, I realized why. The rest of RoofLink is built on tables, and I was asking users to learn a pattern they’d never seen in the product. So I stopped introducing a new visual paradigm and adapted the solution to what users already understood: a table, with each estimate as a row. I tested it with more users, including the original one, and it landed. It translated to mobile too.

The hardest design problem was deciding where and how a user picks their primary estimate. The primary estimate drives the invoice, the work order, the material order, and QuickBooks, so getting it wrong would create errors and send customers back to Support, which directly threatened our self-serve goal.

Four stakeholders pushed for four different lock points in testing. I moved the lock to job approval instead of the material order. It was flexibility against data integrity, and I chose integrity.

I was the first designer to ever work on RoofLink. There was no design system and no patterns, and I was designing over screenshots with seasonal deadlines approaching. I was building the product’s visual language while building the feature.

• 47% less friction in the workflow, from 126 actions down to 50
• 12 to 5 minutes to build a set of estimates
• 373 hours a year saved across 1,600 daily users, about $2.9M in contractor labor
• 3 support tickets in the six months after release

Time saved isn’t only a design metric. Labor cost is one of the top pain points for roofing business owners, so this is the number that turns RoofLink from a cost into an investment for them.

The business numbers followed. Four months after release, 87% of the 800+ accounts we measured had adopted the multiple estimate workflow. Estimate-related churn fell 29%, from 8.6% to 6.1% of total churn. I wouldn’t claim the feature alone kept those customers. What I can say is that four customers named this problem as a reason they were considering leaving, we solved it, and three of them are still customers today.