Adam Sand explains a scalable organizational framework for roofing companies centered on an insurance-claims-aware CRM. He defines a buyer-journey pipeline (BIRF naming rules) and clarifies three distinct objects to model — the customer-facing deal, the carrier-facing claim, and money-adjusting supplement/change orders — then argues for a specialized claims department (claims manager and claims pod) to improve efficiency and scalability.
Chapters
We have this really good organizational framework that's the general structure that we're trying to pass into the roofing company. Because this is something that's scalable. And the whole reason that you buy a system and get consultant. We had this one buyer's journey for insurance. This is the insurance pipeline. And you would have these multiple steps and this was the deal object. And this deal object would move linear across this pipeline and then eventually you would end up with money at the end. The stage of on that thing should follow this abbreviation called birf, which is they should be buyer centric. So it should be like what is the buyer experiencing along the way? It should be inspectable and that you should be able to look at a deal and see some kind of property or data that shows you why it's in that stage. This should be required, right? So this should be a required step. If there's a step on the pipeline that is not required and you frequently skip it, then it's not a required step. It shouldn't be a buyer's journey stage. It should be a sub stage or a sub status or property or some kind of variable to the deal. But it can't be a buyer's journey stage because it's going to throw off reporting. And it should be factual, not anecdotal. The name of that buyer's journey stage and its existence is based on facts, not anecdotes. And as. Yes, and past tense. Because you don't want something that is current tense. So like this is what's happening and this is what needs to happen. So it shouldn't be like appointment to be scheduled and then inspection complete and then adjusting. You know, those are three names that one was past tense, one was future tense and one was current tense. We don't want that. They should all follow a past tense naming convention. And so when we do that, this kind of best practice rule of system design contrasted or came up against how insurance goes, which is that there's kind of a cyclical or other kind of journey where there's some back and forth. So inside of a particular step of the deal journey pipeline, there's another kind of journey where the customer is not the homeowner, the customer is the insurance company. This is why we frequently use the term I got the roof bought by the insurance company. So then this is what necessitated creating a claim. And a claim goes along a linear journey from start to finish that also has multiple steps. Eventually we get to the end and we get money from the insurance company, which contributes to the money that the homeowner has has to buy it. But the homeowner not only has this money, but they also have to pay their deductible. Now, even inside of the claim itself, there was another thing that happened, which is that what was frequently referred to as change orders, and we've met a lot of customers, I would say roofing companies, where there's a change order in that the homeowner says, you know What? I'm getting $20,000 for my roof, but I also want to get these upgrades. They want to do something better with the money. So there was this change order where the homeowner would go over above what was paid for by the insurance. There was this other type of change order that they were doing, which is they would have this change order that was created by the supplementing activities and where the claim would go up because of something to do with code. Like our clients would experience the fact that, well, it's like, okay, well, this money has to come from the homeowner, and then this money had to come from the insurance company. So we needed a way to keep those two things separate. So in the claims management process, there was another journey that we had that was the supplement order. So we created this new thing called a supplement order that impacted the claim. And so it would go across its linear pipeline and eventually add money to the claim. Because a claim would kind of go from red light to a yellow light to a green light of profitability. And the thing that would impact that was not the claim itself, but the supplement order process that kind of happens. So in this, you could have multiple supplement orders that impact the claim. So you would have multiple times that there would be an addition of money that would travel up to the claim, which would then impact the deal. When we kind of really got clear on the fact that there was actually three objects that existed in the insurance management process, which is that you have the deal with the customer, the claim with the carrier, change orders from the customer, supplement orders for the carrier. All of a sudden, now we have this really good organizational frame. Then what happens is you would have, okay, well, who does what? Because the problem that existed is that salespeople are hard enough to train to do the sales journey, right? To do the buyer's journey and manage this process of the deal was hard enough. Then handling claims was kind of this other difficult to train skill. And there was an order of efficiency that was created for companies when we could say, okay, we have inside sales, outside sales, and then we have pods of those people. And then we had that leading up to sales manager. But this person in outside is not always the most detail oriented, which is why we need an inside sales. Now there's leadership needed because above this of course is a CEO and there needed to be some leadership infrastructure in place. Usually a person who knows this job and understands this job, who becomes the person who did this job. But along the way, they don't necessarily learn how to be a great supplementor. Like, they didn't go to xactimate mastery, they didn't learn supplementing, they don't know xactimate, they can't even read an xactimate. Doesn't mean that they can't be extraordinarily good at managing these outside salespeople and extraordinarily good at managing these salespeople. But when it comes to claims, they just don't have that experience. And we don't want to lose a potentially great sales manager to be just because they don't know this. So then it was like what you need is a claims department and that's where we'd have a claims manager. And that claims manager is very specific in their ability. And what they're doing is they're serving the sales department in managing just the claims pipeline. And this is where you get the ability to handle claims efficiently. There's not enough work to necessitate any one of these people being really good at it because everybody has a particular skill set that makes them good. This claims management role was super powerful in that they had enough work to keep them very busy and they lived inside of claims and they could learn all the subtle nuances of how I submit this to this carrier, how I submit that to that carrier, how I get something like this approved, knowing the building code that's needed to get that approved, the different types of contracts that needed to be signed, all of that was something that could be learned and specialized and therefore provide value to the company. So that's a big part of kind of the why behind this design. So when we build RBP with a CRM with a insurance claims management process, that's the general structure that we're trying to pass into the roofing company. Because this is something that's scalable. And the whole reason that you buy a system and get consulting is to take your business this from organized chaos to something that's efficient and scalable and predictable in your growth.
