Software

ServiceTitan management for roofing contractors

This one arrives with an opinion about how a day should run. Working in it means working to that opinion, not around it.

The daily work on this system

The board first, and continuously. Calls booked into the job types the system recognises. Work assigned to somebody who can actually do it, at a time that survives the drive. Jobs closed out properly rather than left open because the crew moved on and nobody went back.

Around that, the record-keeping the board depends on: customer and location details that are right the first time, technician records that match who is actually working, and the paperwork attached to the job rather than sitting in somebody’s messages. On this platform those are not administrative afterthoughts — the board will not behave without them.

The system sets the tempo, not the desk

Most job-management software waits for you. This one moves. It is designed around operations where the volume of calls and the number of people in vehicles make a shared, current board the only workable way to run a day, and the design assumes that board is being maintained continuously rather than caught up on.

That assumption reaches further than it first appears. Structure that feels like overhead — typing a job properly, choosing a real pricebook entry, assigning rather than noting — exists because the system needs it to schedule, route and report. Skip it and nothing complains immediately; the board simply becomes less able to help, and the company starts working around software it is still paying attention to.

For an outside desk the practical consequence is that pace is not a matter of preference. There is no version of this where the queue is worked twice a week and the board stays useful, because the board is a live artifact and its value decays on the timescale of hours. Either somebody is holding it or the company has an expensive list.

Which is why the honest first question is not what the desk will do here. It is whether the company wants to run at the tempo the system assumes — because if it does not, the answer is a different arrangement rather than a more diligent one.

What working inside ServiceTitan looks like, and where its edges are A diagram of one bounded region representing your servicetitan instance. Above it, a capsule states the single thing that crosses inward — a user record you create at the role you choose — and an arrow carries it through one opening in the boundary. Within the region, three horizontal bands name routines that run there concurrently: a dispatch board that holds through the day, calls booked into the shape the system expects, and technician records kept straight at volume. A darker sealed band, drawn inside the same boundary rather than beneath it, names what never crosses back out: your customer and call history, and the pricebook and every rule around it. Nothing in the diagram leaves the enclosure. It shows structure only and contains no figures. WHAT YOU GRANT A user record you create at the role youchoose Your ServiceTitan instance A dispatch board that holds through the day Calls booked into the shape the system expects Technician records kept straight at volume NEVER LEAVES THIS INSTANCE Your customer and call historyThe pricebook and every rule around it
One way in, nothing out. The work happens inside a boundary you own, under a permission you granted and can withdraw, so that the day keeps its rhythm while somebody is watching the board. The sealed band is drawn inside the boundary on purpose — it is not a limit on what we do, it is a statement about what does not move.

Built for volume, and it shows in both directions

What it does extremely well is stop things falling off. Everything that exists is on the board, everything on the board has a state, and the reporting behind it is genuinely good at answering questions about where capacity went. A company that has outgrown a whiteboard feels the difference in the first fortnight.

What it asks in return is completeness. Half-entered work is worse than no entry, because the board schedules against it. A job with no type cannot be routed sensibly; a technician record that is out of date sends somebody to the wrong address with the right paperwork.

The part that stays with a person is proportion. Not every roofing job needs the full apparatus, and a desk that applies maximum structure to a gutter clean has spent an hour producing nothing. Knowing which jobs earn the ceremony is judgement, it comes from doing the work, and no configuration screen contains it.

Your account, your permissions, your data

A user record you create, at the role you pick. Not a shared login. On a system where the board is edited constantly by several people, being able to see who changed what is not bureaucracy — it is how a disputed morning gets reconstructed.

Nothing leaves. No export, no second copy, no reporting file that lives with us and goes stale.

The pricebook and the rules stay yours. We will show you what is causing friction and implement your decision. What your company charges for is not a back office’s call.

Roofing Back Office is not affiliated with, endorsed by, or certified by any software vendor named on this site. All product names and trademarks are the property of their respective owners.

Learning the cadence before touching it

The first week is spent working the board as it is, at the hours it is actually worked. Cadence is not visible in a configuration export — it shows up as when calls arrive, when crews go quiet, which hour the day stops being changeable.

What comes out of that is a written daily routine: the order the board is worked, what gets escalated and to whom, what is checked before close. Most companies have never had one, and it is the artifact that makes the arrangement survivable if the desk changes hands.

Structural changes wait until the routine is stable. On a system this interconnected, altering a job type or a pricebook category while nobody yet understands the daily flow is how a company discovers what was depending on it — during a busy week, from a customer.

What owners ask about a dispatch-heavy system

We are smaller than the companies this was built for. Does that matter?

It changes what the work is rather than whether it can be done. The system expects a certain amount of structure before it will do anything for you — jobs typed, pricebook entries chosen, technicians assigned properly. A large operation absorbs that as routine. A smaller roofer feels it as ceremony, and the useful question becomes which parts of the ceremony are actually earning something.

Can you run the dispatch board day to day?

Yes, and it is the part that benefits most from somebody watching it continuously. A board decays in minutes rather than days: an unassigned call, a technician who finished early, a job that slipped without anybody moving it. None of those is difficult, and all of them are invisible by the afternoon if nobody is looking.

Do you take the calls as well?

Booking into the system is this desk’s work — taking the conversation is a different function with its own arrangements, and the two are frequently confused. What matters here is that a call arriving by any route ends up in the shape the system expects, because a booking that skips the structure creates a job the board cannot schedule.

Our pricebook is a mess. Where does that leave us?

It is the commonest condition and it is genuinely yours to decide, because a pricebook encodes what you sell and for how much. We can tell you where it is producing friction — entries nobody selects, duplicates chosen at random, categories that stopped matching the work — and implement what you settle on. What we will not do is quietly rewrite what your company charges for.

Will this system work for storm surges?

It handles the volume better than most, which is precisely why the rhythm question matters. A surge does not break the board; it exposes whichever habits were being carried by somebody remembering. Practically, that means the weeks before a busy season are when the structure is worth tightening, not the week it arrives.

What happens to the daily routine if we stop working together?

It transfers, because it lives in the system and in a written account of how the day is run rather than in a person. That account is the part most companies do not have: the order the board is worked, what gets escalated, what is checked before close of day. Nothing has to be migrated, because nothing left your account.

Every platform we work in.

Look at the board at four in the afternoon

If it no longer describes the day that actually happened, it stopped being a board some hours ago and nobody noticed.