Who Can See What: Permissions in a Nine-Person Shop

A nine-person shop usually has no permission model at all. One shared drive, one shared inbox, one shared login, and everybody sees everything, because nobody ever had a reason to stop them. It holds up until the day a staff member leaves on bad terms, or a customer disputes a payment and three people give three different answers, or the owner works out that the coordinator booking appointments can also read exactly what every job billed. Nobody did anything wrong here. The business grew past the point where everyone sees everything was harmless.

Below is the three-role model we build for shops around this size, why it usually lands at three roles rather than nine fine-grained ones, and how to work out what your own shop needs before you buy or build.

The three roles a shop this size usually needs

For a nine or ten person field business, three roles cover almost everything, each one drawn from how the business already splits its work:

• Admin. Sees the whole thing, money included: invoices, payments, outstanding balances, the full client history. That’s the owner, plus anyone else who runs the business end to end.
• Coordinator (office role). Takes intake, schedules, and quotes. Blocked from invoices and payments at the permission layer, so the block holds even for someone who knows the web address of the page. A coordinator books a job, quotes a job and puts a technician on it, and cannot see what the job billed or whether the customer paid.
• Technician (mobile-only). Sees their own assigned jobs. Once a job is invoiced, that technician loses access to its data. The person who did the work gets no running view of what the office charged for it.

We built exactly this for a fire-safety inspection contractor, and stopped at three roles, with no per-field “can view but not edit” checkboxes anywhere in it. Trust a small staff and carry the boundaries in the role structure, rather than a checkbox for every action.

The boundary has to live on the server

Plenty of software “restricts” access by leaving a button off the screen. The data behind it stays reachable for anyone who knows, or guesses, the right web address, because nothing on the server ever checked who was asking. Off-the-shelf tools get this wrong by default.

We test boundaries like this by denial, straight at the API. A coordinator’s login asks for invoice data through the same channel the software itself uses, with the interface out of the picture. What should come back is a flat rejection, an HTTP 403 “forbidden” response, carrying no data at all in the body. Compare that with a blank screen that has the numbers sitting underneath it. If your system only hides a menu item, a curious or motivated person sees through it in an afternoon.

Put the question to any vendor you’re weighing up. Log in as the restricted role, request the restricted data by its direct web address, and what comes back? You want to hear “nothing.” Treat “I’m not sure” as a failed answer.

Why a coordinator role usually exists at all

Two roles would be easier to build, admin and technician. The coordinator earns its place because answering the phone in a small trades shop is a different job from running the shop. Someone books the work and sends the quote all day, without ever needing to know what an old job billed or which customer is 60 days behind.

Distrust has nothing to do with that split. Customers ask the front desk things they’d never put to the owner, and a coordinator who can see every client’s outstanding balance sits one awkward phone call away from a customer relationship problem. With no money on their screen, the answer is easy and true: “I don’t have that, let me get the owner.” With money on the screen, the same person has to improvise on the spot or claim not to know something sitting in front of them.

The dull reason matters as much. A coordinator who can’t touch invoices also can’t wipe one out while rescheduling a job on a busy morning. Narrow roles cut down the ways an honest mistake turns into a real problem.

Why a technician typically loses access at invoicing

Scoping the technician role to a phone and to that technician’s own assigned jobs takes about five seconds to justify. Nobody in a van needs to browse another crew’s job history. The harder call sits at the other end of the work.

The pattern we build toward: access ends the moment the job is invoiced. Up to then the technician can see and update their own job, arrival and departure, checklist, materials, work performed, photo, signature. After the invoice goes out, the job belongs to the office and accounting side of the process, and the technician’s login stops opening it.

That’s a statement about scope. A technician does the work and records that it was done. Pricing, invoicing and collections all happen afterwards, in a different chair, and there’s no operational reason for a technician’s login to reach forward into any of it once their part is finished.

Working out what your own shop needs

Write down who sees what today, and mark each line as a decision somebody made or an accident nobody stopped. Then run this, which takes about an hour at this size:

• List your roles by job, with the names left off. The question is what the person who answers the phone needs to see, whoever is holding that seat next year.
• Split “does the work” from “bills the work.” One person may do both today. The split still holds when they leave, and a role model built on it survives turnover better than one built around how much you trust a specific person right now.
• Ask what happens the week after someone leaves. If your coordinator quit tomorrow, does their access die cleanly? Or is company data scattered across logins, shared drives and personal phones that nobody can fully claw back?
• Push back on anything that only hides a button. A vendor who answers “well, they wouldn’t know where to look” has sold you a hope.

None of this needs a complicated build. Three roles, cleanly enforced, cover a real multi-person business end to end with no per-field permission checkbox anywhere in the system. Aim for the fewest roles that match how the work splits in your shop, each one backed by a real boundary the software holds whether or not anyone remembers to check.