Written for the people who use it every day. Nothing here is a rule you have to memorise — the point of the board is that it works out what is late so nobody has to remember. Back to the board
A run is one payroll schedule for one pay period — Harbour Kitchen's September, or Copperworks' week 36. Every run has thirteen steps and a handful of deadlines worked back from its pay date. You tick steps off as you do them; the board works out from those ticks and those dates whether a run is fine, at risk or late. You never set a status by hand, which is the whole point: a status somebody has to remember to update is wrong by Wednesday.
The board is one row per run, soonest pay date first. The thirteen dots are the steps, in order:
Click any row to open it. Tick a step and the time is stamped by the server, with your name against it, and it appears in that run's history and on What has moved at the foot of the board.
Pay dates in the filter rail decides which runs are on the board. It reaches both ways: the Ahead windows run from the start of this month out to 14, 30, 60 or 90 days or 12 months, the Back ones cover the last 30 days, 3, 6 or 12 months, and Everything is the whole board. Custom range… opens a From and a To box for any two dates. The line under the rail always says which dates are in.
Two things hold whatever the window says. Anything still unpaid is shown, however far back its pay date is — an unpaid run from two months ago is exactly what the board must not hide. And the strip at the top counts what is on the board, so if you look back a year the counts are about that year; click one and you get the rows behind it, always.
The Pay diary and the HMRC tab each have the same control over their own dates.
Inputs chased and Amends required are flags, not progress — chasing a client is not a step forward and amends coming back is a step back. Both are recorded so "who have we chased" has an answer.
The stage shown is the last step finished in sequence. If you tick RTI submitted without Approval received — which happens when a client approves by phone — the stage stays where it was. That is deliberate: it stops the board claiming more progress than there is. A run can therefore read Done while its stage says something earlier, if a step in the middle was never ticked. That is how you notice you forgot one.
| Status | Means |
|---|---|
| Done | Signed off. Not "paid" — signed off. |
| Overdue | A deadline has gone by with the step not done. |
| At risk | One of those deadlines is today. |
| On hold | Parked by hand, with a reason. Stops the chasing. |
| On track | Everything still ahead of it. |
The red text beside a status says why — "no inputs (due 24 Sep 26)", "funds not requested (cut-off 29 Sep 26)" — so you rarely need to open the run to know what to do.
You can pin On hold, At risk or On track on a run if you need to say something the dates cannot. You cannot pin Done or Overdue: those are facts about dates and ticks, and being able to set them would only let the board lie.
| On the client | Means |
|---|---|
LWD | the last working day of the month |
LWF | the last Friday of the month |
LWW | the last Wednesday of the month |
28th, 7th | that day of the month |
Friday | the weekday a weekly or fortnightly schedule pays on |
Weekly, fortnightly and four-weekly schedules also need a seed pay date — one real pay date. Nothing can work out which Friday a fortnightly client is paid on, so without a seed the board generates nothing for them and tells you so.
A client's processing days is their SLA in working days, counted back from pay day and skipping weekends and bank holidays. Four working days before a Monday pay date is the Tuesday before, not the Thursday. The other two are the same: the approval lead, and the funding cut-off (before pay day, because BACS takes days). Sign-off is three working days after pay day.
Generate periods puts every period that pays inside a window onto the board. It is safe to run twice and safe to run for a month somebody else has already done — anything already there is left exactly as it is.
A weekly Monday means the same step across a lot of clients. Rather than opening thirty runs:
Every run gets its own history entry, so the audit trail is exactly as if you had done them one at a time. The selection stays afterwards, because the next thing you usually want is the next step across the same thirty. Use the Tick / Un-tick toggle to reverse one, and Also change… to set the payroll lead, pin a status or set the chased and amends flags across the selection.
The chips under the filters show what is currently filtering the board, so a short board is never a mystery.
The Imports tab takes the files a client sends — rota export, timesheet, tronc sheet, bonuses, new starters — and writes the two CSVs BrightPay imports.
A works number is believed first. Then the client's own mapping file — their spelling of a name against a payroll number — if they send one. Then the pairing the other files imply: if the rota carries both a name and a number, a tronc sheet with nothing but names lands on the right people by itself. Only then a name on its own.
If a file arrives with headers the board cannot work out — Ttl Hrs Wkd, Bsc Rate, Trnc — press Suggest the columns. It reads the headers and comes back with what each column probably is, how confident it is, and why.
Nothing changes until you say so. You get a list of what it wants to change, with a tick box each. Anything it is less than 60% sure about arrives unticked. Read it before you press apply — the whole point of a mapping screen is that a person looked at it.
It never sees anybody's details. What gets sent is the column headers and the shape of the values, not the values: an NI number goes as AA999999A, a name as Aaaaa Aaaa, a postcode as AA9A 9AA. Numbers go as a range, because 22 to 44 is what says "hours" and 12 to 14 is what says "hourly rate". No name, no number, no address and no figure attached to a person leaves the building. There is an Exactly what was sent link on the screen — open it, it is the truth.
Underneath the files, the board compares what you have dropped in against the last lot from the same client. This is not the AI — it is arithmetic, done here, and nothing is sent anywhere for it.
PAYE is paid per tax month, not per run: tax months run the 6th to the 5th, and several weekly runs roll into one payment. So the HMRC tab is one row per client per tax month, due on the 22nd of the month that tax month ends in — a pay date of 3 September is in the tax month that began 6 August, and is paid by 22 September.
The amount owed is added up from the runs inside the period every time you open the screen, so filling in a run's HMRC figure updates it here with nothing to regenerate. Record what was actually paid and a reference; if the two differ, the row says so rather than quietly reconciling it.
Every complexity input on a client exists to produce one number:
WI = (employees ÷ 25) × frequency score × adjusted complexity
Frequency scores 4 weekly, 3 fortnightly, 2 four-weekly, 1 monthly. Adjusted complexity is the base rating of 1–3 plus a loading for each thing that makes the work harder: tronc, client-led funding, hypercare, a tight SLA, a complex or multi-level approval, high comms, a salary-sacrifice pension, and no rota system or hours by spreadsheet.
Open any client and the index is shown with every loading that went into it, so it can always be explained. Tiers are High from 20, Med-High from 10, Med-Low from 5, Low below.
The Workload tab is what it is for: what the book weighs, how it splits by tier and by payroll lead, the heaviest schedules, and fee per WI against the book average — which is where a pricing conversation starts.
The unit of work is a schedule, not a company: a client running a weekly and a monthly payroll is two rows, which is why the same name can appear twice.
Click any client for their note feed — "they send the tronc separately, always late". A pinned note appears on every one of their runs and on the import screen. That is the point: whoever does September should not have to rediscover what August learned.
Split the tronc, check the director's manual pay — set them on the client and they are copied onto each of their runs, shown as a separate checklist and as a count on the board. Adding one now also puts it on the runs already open. They never change a run's colour; the thirteen built-in steps do that.
| Role | Can |
|---|---|
| Administrator | Everything, plus managing people, import layouts and housekeeping. |
| Editor | The board, the clients, imports and HMRC. Everything except managing people and deleting. |
| Viewer | Reads everything, including the exports. Changes nothing. |
There is no automatic password reset. Forgotten your password? tells the administrators, and one of them hands you a one-time password which you replace when you sign in. Those expire after a fortnight if unused.
Five wrong passwords for one address inside fifteen minutes locks that address out for a while. A correct password clears the count, so one fumbled attempt never counts against you later.
Open the board. The strip along the top is seven counts and every one is a filter — click Overdue to see only those. Then Pay diary for what lands this week, and pick off anything unfiled on a day that pays.
Filter to yourself, select what you have done, tick the step. Chase what needs chasing and set the chased flag so nobody chases twice.
Pension, journal, sign-off. A run is not finished until it is signed off, and it goes red three working days after pay day if it is not — which is the only thing stopping close-out work from quietly never happening.
HMRC by the 22nd. Then the Workload tab: fill in anything on the gap list, and look at the underpriced clients before the next fee conversation.
Something has not been ticked, or a date on the client is wrong. Open the run: the reason text names the step. If the client's deadline itself is wrong, fix it on the client and every future run is right too.
Check their pay day rule and, for weekly and fortnightly, their seed pay date. One wrong seed moves every pay date for that schedule.
Signed-off runs whose pay date is before the start of the current month drop out of the default window. Change Pay dates — the Back windows and Everything reach as far as the board goes — or use the CSV export.
Look at the Workload tab's gap list. A missing complexity rating or headcount scores as low, not as unknown.
Tell Tom. The run history and the access log record what happened and when, so nothing has to be reconstructed from memory.
Every run and every client has a Comments box, and the Team tab has a General channel for anything that is not about one client.
Notes are how a client is run — the standing instructions, pinned, and they follow the client onto every run. Comments are a conversation: "did their hours ever come in?" Ask in comments; write down what you learned in notes. If a year of chat ends up in the notes, nobody will find the instructions.
Type @ and pick a name. They get it on their Team tab and a chip appears in their header until they have read it.
If you name somebody on a client that is not theirs, it will refuse and tell you — they cannot see that schedule, so they would never get the message. Reassign the run, or tell them directly. Same if you misspell a name: it will post, and then say nobody answers to what you typed, so you know they have not been told.
Anyone in a thread can mark a comment sorted, not just whoever asked — that is usually the wrong person to have to chase. Sorted comments stay there, greyed, and drop out of the "still open" list. Nothing is deleted, so why something was done is still readable next month.
Danielle and Tammy see every comment on the board. Everybody else sees comments on their own schedules, plus General, plus anything naming them — the same rule as the runs.
Put somebody's personal details in a comment. It is the wrong place for a National Insurance number or a pay dispute, and the import review screen or a phone call is the right one.
Nora sits in the bottom-right corner of the board. She is the same Nora our clients meet on team-pay.co.uk, doing an internal job here: answering questions about this board.
Things you would otherwise go and look up across three tabs. What is overdue. Why a particular run is red. What the COM says about a client's approval route. What is owed to HMRC on the 22nd. Which schedules look underpriced against their workload index. She reads the same figures the screen shows, so she cannot tell you something different from the tab next to her.
She sees exactly what you see. Every lookup she does runs as you. If a client is not one of your schedules, it is invisible to her too — she will say it may not exist or may not be yours, and suggest asking Danielle or Tammy. She is not being coy: she genuinely cannot see it.
She cannot change anything. She has no way to tick a step, edit a client, reassign a run or file a submission. Ask her to and she will tell you where to do it yourself. That is deliberate — a step ticked because a question was misread is worse than a question unanswered.
Nothing is kept. There is no transcript: the only thing recorded is a count of how many questions each account has asked today, which is there to stop a stuck browser tab running up a bill. Don't type an employee's personal details into her — she is told not to repeat them back, and the chat is not the place for them either way.
The Nora on team-pay.co.uk answers the public about the product. She has no way to see this board — different system, different database, no access to a single client of ours, and she is told plainly not to discuss how we run the bureau even if somebody insists they already know. The one in here has both: the board, and the same product answers the website gives, so if a client asks you what we charge or whether we do tronc, she can hand you the exact wording they would have got from the website.
She keeps the two apart and will tell you which is which. Ask her what to say to a client and she gives you the public line; if the answer needs something off the board in it, she will flag that part rather than hand you a sentence with another client's name in it. That last bit is worth remembering when you paste her answers into an email.
Her API key is not set on the deployment. That is an administrator job, not something a reload will fix.
Anything that turns on a specific set of circumstances — a leaver's final pay, a tax code somebody is disputing, whether an odd NI category applies. She will point you at Danielle or Tammy for those, and she is right to. She explains how this board works out a deadline; she does not rule on your obligation.