Roofing CRM Pipeline Explained: How to Organize HubSpot Deal Stages and Ticket Stages

What's up, everyone? Welcome to another episode of Winning Wednesday. Today, Drake Miller from Mountainside Lights brought up one of the most common CRM problems I see. What deal stages and ticket stages should you actually be using? Most roofing companies have way too many stages in HubSpot and it destroys your reporting. So here's the correct pipeline setup that actually works.

So I guess today's question is kind of about deal stages and ticket stages and which ones I should have. So right now for the sales pipeline, I have qualified to buy, which is just when the deal's created, then contract sent, contract opened and closed one and closed loss. I was thinking maybe I should add some stages beyond like closed one, you know, or with closed one is the last stage or something.

So a lot of times when we get into CRMs, people create a whole bunch of extra stages so it'll break those rules. Like it's not required. So like contingency signed will be on every deal pipeline, even though they don't do insurance all the time. Or it'll be like hot, warm and cold as like deal stages. Those aren't deal stages. Those are like sub statuses of a deal. When you're looking at what deal stages should you have? Well, it should be what does the buyer have to experience in your proven pathway to success? How do you make that inspectable and only put them there if it's a required step? So if it sometimes happens that's a sub status or a variable on a deal. It's not a deal stage itself. It has to be all the required steps, steps that allow the buyer to get their deal done and then they should be factual.

So basically contract sent in my stage doesn't actually mean it's been sent yet, but not when it's actually sent with the loom video yet. Should I add a second stage for that or just have it so it only goes to contract sent.

There's a part of your process where before the contract is sent, there's almost like the contract is prepared. Yeah, you would have like appointments set and then inspection complete and then estimating assets collected sometimes. And then it'll be like quote ready and then contract sent. So that's how like I've seen it sometimes, but that's only if you always have to get estimating assets collected. So this is more like a commercial pipeline. Right. Where you basically have a site walk and then you do the inspection or the site walk and then you have to get a whole bunch of different assets and then you have quote ready and then you have contract sent. So you might just have the need for like a quote ready and then a contract sent. You have to get it ready to.

Send the estimating assets ready or whatever thing. Like. Yeah, I do sometimes have that because most of my quotes I can do with near map, but sometimes it's a new house, it's not on there yet. Would I in that case be best to you know, say have that as a sub property of some sort?

Yeah, because it's basically you received everything from the customer, like from the buyer centric. Remember it's buyer centric, inspectable, required and factual. So from the buyer centric perspective, does the buyer have to do anything between these two stages that you're thinking about? No. Yeah. So then it's not a stage because it's not really buyer centric. It's not the buyer is anything doing. It's a variable on the deal that triggers something for your team member to do or an agent to do or a workflow to do or a date to pass or something like that.

And when you guys talk about like job sold and contract signed, what's the difference between those stages?

Yeah, good question. So, so I'll kind of like get that drawing that I was going to put together earlier. So essentially you have a deal pipeline and then a ticket pipeline. Your deal pipeline is going to move like this and naming aside, it's basically going to go like marketing qualified lead to sales qualified lead to opportunity to customer. You're going to have different stages on there. Now the ticket would only exist in this length of time. So it's like there's two stages here that encompass the ticket which has multiple stages because you have to load the material, you can install the roof. They're going to have a quality control, that trade is complete and punch list complete. And then it's, it's closed as a job. And then that's what triggers the deal to move on to like invoicing. Because the invoicing is more of a deal related activity. Ticket is a work related activity. So the completion of this ticket creates the work. So that's kind of the preface behind what you just asked. Which is the reason that we have contract signed. Right. Which is buyer centric. Right. The customer signed the contract. Then we have a task for the inside sales to do the job file playbook. So the contract is signed. So in the customer's eyes this has been done. Like the customer feels like they've signed the contract, but then we have to make sure this is an approved deal. So then there's going to be a stage where they do the job file playbook and it goes to another stage which are usually called job sold. And then after that it goes to approved. Because then what happens is, okay, when it goes to contract signed, the salesperson has to do something. Then when it's moved to here, the manager has to do something because then they move it to approved because they approved the job file playbooks being completed. Once it's approved, then we create this ticket pipeline, right, where work's going to happen on the ticket and eventually come back to the deal for the invoicing. The reason that you want to do it this way is because a deal could have one or many tickets, right? You could have roof install and then a gutter install and then a siding install, all fitting within the approved stage where like the job file playbook was completed. And in the job file we said, hey, we're doing a roofing job, we're doing a gutter job and we're doing a window job. Those are three approved tickets that exist. But then we have to complete 1, 2, 3 tickets before we say all trades complete and then we go to invoicing.

You said with the deals it should always go through that whatever stage it is. But it's okay to have like an extra stage on a ticket. For example, like my main one is I have like with the hail storms and such, we have people who have signed on but they're waiting on getting their soffits replaced or something. So it's like waiting on other trades or something. Is that an okay state to have?

You can do that. Especially like where you're at right now, you can absolutely do that. It's like it only becomes an issue if you're like worried about service level agreements. Like that's really the only time you really start to like care about that is like, oh well, not sitting in that stage. And we have to have something that tells us that the clock stops when it's in that stage. If you were worried about a certain service time frame, that's the only time. Like having unnecessary stages for tickets as opposed to closing them and reopening them. But you're not going to worry about that. But just I'm just trying to be intellectually honest for the rest of the room that might then want to go and create a bunch of tickets in their systems when they have 100 tickets.

Okay, that makes sense.

Think it would. Like if a client sends us a ticket at rbp, so they send us a ticket saying hey, we want to Make a certain dashboard. Well, if we put it into a certain stage and it just sits there and rots, it drags down the average ticket closing time for the whole company while it sits there. And maybe that ticket should just be closed. But some people, like, some companies will go and leave things there. And I've seen that kind of stuff in, like, job nimbuses where I'll go in some job nimbuses where they've got files that have been sitting there for like 600 hundred days in some stage. Fair enough.

One more quick question. Sometimes I'll get people to say, like, follow up with me in September. We'll be ready. Then should I just close lost that and put a event, or should I keep that open?

Well, you could keep it open, but you would set the close date for September. You'd set a task, because if you end up getting a bunch of those, you don't want to create some waiting until spring bucket. That's what a lot of people do. And then if it gets in the way, like when you start getting lots of deals, you would usually say, hey, I only want to see deals that have a close date of like, the next three weeks. And then that's how you can kind of get focused. Because you don't necessarily want all your deals in front of you all the time. You're just like, what? Yesterday me, when it was trying to take care of tomorrow me, which is now today me, yesterday me, did it set a close date? And if it did, is that close date in the near future? Okay, well, that's where I want to focus my attention is on the people that yesterday me told me to say, hey, call this person tomorrow or call this person in a week or call this person in September. So the close date is in a way, allowing you to forecast your revenue.

So you basically just can clean it up by changing the view based on close date.

Yeah, so you say, hey, I only want to see, like, let's say you get 50 of those and they feel like they're clogging up your view. Well, then you don't mark them lost and create a task to reopen a deal. Like, that's going to create three times as much work later on. You just say, hey, we've got a lot of people who are hit by that hailstorm who are in this, like, waiting on other trades thing. Let's just change the close date. And that's just like, set our default view to, like, only show the close date for the next 30 days or something.

Awesome. Thanks, Adam.

Hey, man. No problem. Glad to be here. Hope it helps.