Software
JobNimbus management for roofing contractors
The boards and the automations are not settings. They are the company’s process, written down by somebody who has usually moved on.
What the desk picks up here
Contacts and jobs entered as they arrive, on the board they belong to, with the fields the office actually uses filled rather than the ones the form happens to show. Items moved between stages when something has genuinely happened, which is a smaller set of moments than most boards imply.
Alongside that, the follow-up that a busy week eats first: the estimate nobody chased, the customer who was promised a call, the job sitting in a stage that stopped describing it a fortnight ago. And an eye on what the automations are doing while all of this happens, because they are also moving things.
We inherit the process you already encoded
This system is unusually willing to be shaped. Stages, fields, board layouts and automated sequences are all yours to define, and companies define them — over years, in response to particular problems, usually without writing any of it down.
The consequence for an outside desk is that the software teaches you almost nothing. Two roofing companies of similar size can run instances that share a vendor and nothing else: a stage called the same word means a signed contract in one and a scheduled inspection in the other. There is no default arrangement to fall back on, because the arrangement is the product of decisions rather than of design.
So the work begins as archaeology. What does this stage mean to the people using it. Which automation sends that message. Why does one field get filled reliably and the neighbouring one never. Each answer is a decision somebody made, and a surprising number of them are still right — the ones that are not tend to be the ones nobody can explain.
None of that argues for rebuilding it. A desk that arrives and imposes a tidy structure has thrown away the encoded knowledge along with the mess, and the company then discovers which parts were load-bearing one failure at a time.
Flexible enough to encode anything, including a mistake
The flexibility is genuinely useful. A roofing company that works in an unusual way can have a system that matches it, rather than bending the business around software written for somebody else. Boards make the state of the pipeline visible at a glance, which is the thing most owners actually want and rarely get.
What that same flexibility does not do is object. It will accept a stage that two departments read differently and keep both of them happy for years. It will run an automation whose original purpose has expired. It will hold a required field that everybody fills with a placeholder, and it will never mention that the placeholder is now the most common value in the system.
The judgement left to a person is which of those is worth touching. Inconsistency that nobody trips over is not a problem worth a change window; inconsistency that produces a wrong answer to a question the owner asks monthly is. Telling those apart takes a while and cannot be done from a settings screen.
What you grant, and what never moves
An invitation you issue, at a level you set. Not a shared password. A shared credential cannot be attributed to anybody afterwards, and on a system where automations and people both change records, being able to tell which did what is the whole audit trail.
Nothing is exported. No parallel database, no shadow spreadsheet. If we stop working together there is nothing at our end to return or delete.
The configuration stays your decision. We will document what it does, say where it is costing you, and implement what you choose. We will not quietly reshape the process to suit the desk.
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.
Reading before changing
The first pass is an inventory rather than a cleanup: which boards are in use, which stages have a shared meaning, which automations fire and on what trigger. Most companies have never seen that written down, and a fair number of the surprises turn up here rather than later.
Live work runs throughout. Holding the queue while the inventory is built stops the backlog growing and is also how the conventions reveal themselves — a week of doing the work teaches more about how a board is used than any amount of being shown.
Changes come afterwards, singly, with the reason recorded and the automation checked. On a system where an edit can trigger something else, a batch of well-meant tidying is how a company finds out what was connected to what.
What owners ask about handing over their boards
Will you rebuild our boards?
Not without you asking, and not early. A board layout encodes decisions somebody made about how work moves — what counts as a stage, who owns an item once it lands there — and most of those decisions are load-bearing even when nobody remembers making them. We work the boards as they are, tell you where they are costing time, and change what you decide to change.
Nobody here knows why the automations were set up that way. Is that a problem?
It is the usual situation and it is the first thing worth fixing. An automation nobody owns still runs: it moves items, sends messages and changes states on a schedule that made sense to somebody once. The early work is an inventory of what actually fires, so the company knows what it is running before anyone edits it.
Can you work in our instance rather than exporting?
Yes, and that is the only way we do it. The record your company runs on stays the one being maintained, which matters here because the configuration is part of the record — an export captures the contacts and loses the arrangement that gives them meaning.
What happens to automations that turn out to be wrong?
They get listed, not silently switched off. An automation that fires at the wrong moment is visible and annoying; one that was quietly disabled is invisible and will be discovered by a customer who stopped receiving something. Anything we propose turning off comes with what it currently does and what stops happening if it goes.
Do you handle the data entry as well as the process?
Both, and they are less separable here than owners expect. Keying a contact into a board that routes it wrongly produces a tidy record in the wrong place, so the entry work and the arrangement it lands in have to be understood together. In practice that means the first weeks are slower and the months after are not.
If we bring this back in-house, what does the next person inherit?
A live instance and a written account of how it is configured — which stages mean what, which automations run, which conventions the office actually follows. That second thing is what a company almost never has, and it is the difference between handing over a system and handing over a puzzle.
Open your automation list and read it aloud
If nobody in the room can say what one of them is for, it is still running and still changing records every week.