Roofing CRM Setup Guide: How to Organize Jobnimbus, Proline & HubSpot for Success

Foreign. Flow through a well built CRM. If you guys aren't on our CRM, again, this isn't a attempt to sell you. This is just like, I can't teach this stuff without teaching this stuff. Picture this like a timeline. Okay? So we go to timeline and on this timeline we want to think of every stage of it. There's kind of a rule set for how we name deal stages and this all makes sense in a second, but it's birth with a C on it. So this should be buyer centric. So it should be about what the customer is doing, not what the salesperson, production manager is necessarily doing. Then it should be. Or what the buyer has experienced. Right. It should be inspectable. So based. Whatever deal stages we name, they should be, we should be able to inspect it and see why it's in that stage. Like if we're going to create a stage, we should be able to see in the CRM exactly why it's there. Usually based on properties and data, not notes and emails and calls. Then it should be required. Every deal stage in your CRM should be required as part of the buyer's journey or, and that includes like your ticket stages or your claims stages. Because the common culprit of this, the bad one, is this deal stage waiting until spring. Right? A lot of people create a bucket like this in a job nimbus when we migrate data. The problem is that's not required. It's buyer centric. It's what the customer is experiencing. If we have a close date of April 24th and it's August 26th, yeah, they're waiting until spring. The close date is inspectable, but it's not, it's not a required stage of our buyer's journey. Every customer does not go into a waiting until spring stage. So we use other properties or data to filter. We don't use buyer's journey stages to do that because it screws up reporting. And that's something a lot like just you don't know how to set up a CRM. You know, the people who work at CRM places that are getting paid $17 an hour to do customer support, they're just going to pick their battles and so they're not going to do it. Like they're not going to tell you that stuff. But I'm responsible for building pretty complex stuff. So the other one is factual. So hot leads, that's not our hot deals. Right. That's not a buyer's journey stage. It's not customer centric. It's. And it's not really factual, it's anecdotal. It's based on the opinion of a sales guy. Whenever we name stages in a CRM, we want to make sure it matches those kinds of things. And so then you end up having these stages. And now let's say this is all the way from when we create a deal. So create all the way to close one and we've been paid. So now this is our deal. So this is an object in your CRM, right? So in like job Nimbus, you have contacts and jobs. Now the problem is that's not everything that happens in a business. Now if you're running a three million dollar company, that's fine. But you know, when you're building a, a more complex CRM that you want to have to scale and collect good data and get like the best business intelligence, well then you really realize that you have contacts, you have deals, you have tickets, which is kind of like jobs, but then you also have say, buildings, right? Because a building could have one or many contacts and a contact could own one or many buildings. A deal could be related to one building or it could be related to multiple buildings and a building could eventually have multiple deals on it. But a lot of times people make the mistake of creating a company cam for a contact or they make a company cam for a deal. But that's wrong because a company cam is not a contact, it is not a deal, it is a building. And so that's where your company cam goes. So that's just a quick, kind of quick and dirty explanation as to why there has to be multiple objects. Because another thing that could exist is a claim which is another object that has its own continuum, right? It has its own timeline of events that is separate from a deal. And same thing, a building could have one claim on it or it could have multiple claims on it. And then once you sell a deal, so once a deal passes a certain line, it becomes a ticket. And a deal could have multiple tickets because you could be doing roofing and gutters and siding, right? So you would essentially have multiple tickets. So in a deal, right, you're going to have several stages. You're going to have the inspection complete and then you're going to have the contract sent and then you're going to have the contract signed and then you're going to have job files. You got to complete your job files and then you're going to have an approved deal. Then once you get an approved deal, well then there's a separate timeline that exists and so we have to kind of encompass for that. And so I'm going to create another timeline and this is going to be your ticket of which there could be one or there could be many, many. And that ticket is going to go through more stage, have its own set of stages, right, because you're going to have the production intake and then you're going to have to schedule it. You have a scheduled job and then you're going to have your whip, right, so work in progress and then you're going to have the install complete. And so it's going to have its own journey that exists. This kind of exists within this. But we have a stage called all trades complete. Because what it's basically saying is if we have multiple tickets that have the same stages, but this one is for the roof and this one is for the gutters in the context of the deal, we really don't have to do anything or shouldn't do anything until all trades are complete. That's the next buyer centric were inspectable required in factual deal stage. A required stage is that all trades have to be complete. But if you had some like silly stages in here, like a roof's complete, gutters complete. Well, not every time are you going to have a gutters complete stage. That's the issue that a lot of people have with job progress, is that you only have one timeline and you have to kind of fit your insurance claim time stuff in here. And so sometimes you have to move it through these stages and it'll say completed on 8 26, but you never actually did that. So then you get bad data because it moved through a stage that never should have even existed on this deal pipeline. Not talking smack on the product, I'm just saying that there's limitations to certain things because the other thing that happens is on say an insurance pipeline, you have another timeline that's going to exist, right, which is your claim because you're going to have to file a claim, then you're going to have to get your scope determination, then you're going to get your paperwork and then you're going to have to get do front end supplementing. Then once you pass this line, the job is allowed to go into work in progress, right, which is a middle stage wip. So once you pass this line, they say basically the deal pipeline will not allow this deal to move from here to here unless this is moved from here to here. So when this claim moves from here to here, this unblocks this block from going that way. This is how you can kind of keep things organized because one person is working on your claims, right? Another person is working in production, but you want kind of a total record of truth that happened with the deal. And so certain things unblock. For example, you can't go to all trades complete until all of these associated tickets have moved to this stage. The reason that we have say a claim object, right, just for example, is that a deal will exist on this continuum somewhere, right? From when it's new to when it's one. Because someone else is usually running the claim. There's a small order of work that needs to be organized and managed. And so this is our deal and this is our claim. And so as we have our claims manager doing the things to get the claim to move to key milestones. So you have a claim and that claim is going to move through these stages, right? So it's going to bounce, bounce, bounce through those stages. There are certain points where the deal cannot go past this line until the person running the claims gets it to here. And so we don't want to have our deal be allowed to go past and continue going through this because there's reasons that could be bad. So a good example is there is separate pipelines for different trades. So you're going to have the service hub. We have contacts, we have buildings, we have deals, we have tickets, we have claims. So there's different objects that are different things, right? So another easy way to kind of explain this we all kind of understand is maybe say a car dealership. If a car dealership had a CRM, well, they would have contacts. And then from there they have an inventory of cars and then they have parts and then they have deals. So for example, a deal, you could have inventory of cars, you could have a 20, 24 Jeep in blue. And you only have one of these things. So there's only one of those objects, right? If you have three deals on the Jeep. So three people came in, three people want the Jeep, everybody wants to be a negotiator. And so this guy has an appointment scheduled to come view the Jeep. This guy has test drove the Jeep and been offered something, he's still negotiating on the price, right? He's going to go drive other Jeeps and think about it. And then a new guy comes in, he goes through, he books an appointment, comes in, same day, does a test drive, gets a contract, goes into finance, right? Gets approved. And so now this is a green kind of green for go because he's approved on financing. And so then all he has to do is come in and sign and then he drives away. Well, now this jeep is no longer in existence. So this deal, because this inventory piece no longer exists anymore, these deals cannot proceed any further. So that's where we're trying to say based on what's happening with one object inventory, we could have things that happen with deals. If you have multiple tickets, well, your roof has to go first because you don't want to bang up your brand new gutters. So you cannot go forward with. You can have this one be in scheduled stage, that's allowed. But it cannot go into work in progress until this one is install complete. But until just because this one is install complete and is considered to be green, we cannot move from work in progress to close one and start invoicing until such time as this one is also green. So the idea is that the production manager playing this Tetris game has to try and keep all this organized. He also doesn't want to say maybe put a deal through until front end supplementing is complete. Because some companies, not all some companies, so this is not like a major indicator of success. But some companies will not allow a deal to go into scheduling until they hit a 40% gross profit or a 35 or whatever it used. Actually this company was 45 and then wouldn't let it go until it was. Now they, they basically had three lives. They had a green light on it if it got to if it was a 45, the yellow light if it was 40% and they had a red light if it was under 40%. So they would not allow if the claim object. So the claim timeline, claim pipeline does not get past this point of getting to 40 the deals, the work in progress, not allowed to proceed. Now we have other clients who do all their supplementing on the back end. So they don't have this line right here. So the deal is able to continue proceeding regardless of all this. So this is all to just kind of say that this is a large place where the production manager lives.