Guide

Staff roles that match how your store actually runs

The mistake is designing roles from fear. Design from the workflow: what does this person do all day, what do they do sometimes with supervision, and what is simply not their job.

1. Start from a template

SeroBooks ships starter roles — Sales Clerk, Bookkeeper, AR Clerk, AP Clerk, Accountant, Auditor. Apply the nearest one, then adjust.

2. Use the middle state deliberately

Visible-but-locked (View without Allow) is for legitimate-but-supervised work: refunds, price overrides, reopening invoices. Staff see the button, a permitted colleague approves on the spot — no admin hunts, no workaround culture.

3. Hide what is not their world

A sales clerk does not need to know the Chart of Accounts exists. View off removes the tab entirely — less noise, less temptation, faster staff.

4. Protect the money boundaries

Cost and margin visibility, supplier payments, reconciliation, period locks: each is its own permission. Grant them by job, not by seniority.

5. Trust the trail

Approvals and changes are audited with names attached. Roles are not about suspicion — they are about every override having an author.

serobooks / setting up staff rolesLive

Design roles around jobs, not people

Permissions granted person by person become unmaintainable within a year — nobody remembers why someone has an exception, and leavers keep access nobody notices. Roles named for jobs (Counter, Supervisor, Bookkeeper) survive staff turnover and can be reasoned about.

Start restrictive and widen on request. Widening is a two-minute conversation; discovering that a clerk could edit closed periods is not.

Separate seeing from doing

The useful distinction is between what a role can view and what it can act on. A supervisor may need to see margin without being able to change prices; a bookkeeper may need to see every sale without being able to void one. Collapsing those into a single permission forces you to over-grant.

Sensitive actions — refunds, discounts, price overrides, edits to posted documents — are the ones worth requiring an approver for.

What SeroBooks does with this

Access is a View/Allow tree over every screen and action, enforced server-side rather than politely in the interface — a revoked permission reaches the device and stops the action even if the screen was already open. Approvals let a permitted user authorize on the spot, recorded with who asked and who approved.

The audit trail keeps what the books used to say when someone corrects a document, so permissions decide and the trail remembers.

See it in your own numbers.

Free to start, on Windows, Mac, iPad and Android. No credit card.

Start freeBook a demo