Service 04
Registers and trackers on SharePoint, instead of the spreadsheet
TechRam builds registers and trackers on SharePoint to replace the compliance spreadsheets your operation runs on — expiry and renewal trackers, incident and hazard registers, OKR trackers. Every row has an owner, a state and a date, reminders fire before anything lapses, and the register itself is the audit file. Built on the Microsoft 365 licences you already hold.
- Weeks, not months
Who it's for
Organisations where the compliance register, the expiry tracker or the objectives list is a spreadsheet one person understands, and somebody outside the organisation asks for evidence from it.
What we do
- Expiry and renewal trackers — screening checks, insurances, certifications — that watch their own dates
- Registers for incidents, hazards, assets and contracts, with an owner and a state on every row
- Objectives and key results tracked where the executive looks, not in a workbook
- Reminders before a date lapses, and a report off the register for whoever is accountable for it
How it works
Step 1
Bring the spreadsheet. We work through who touches it, what it captures and what it feeds
Step 2
Fixed scope and fixed price, agreed in writing
Step 3
Build it as a SharePoint register, test it with the people who keep it, document it
Step 4
Hand over, then improve on a cycle if you want us to
The problem it answers
The worker screening expiries are a spreadsheet. The insurance renewals are a tab in it. The hazard register is a different spreadsheet, and the objectives the board asked about live in a workbook one person updates the night before the meeting.
None of these were bad decisions. Each one was the fastest thing available at the time. The cost arrives later — when a check lapses before anyone notices, when an auditor asks who changed a row and nobody can say, or when the person who understands the workbook is on leave.
What changes
The same lists become real systems: one register per obligation, each row with an owner, a state and a date, and a reminder that fires before the date does. The record is written as the work happens, so the register is the audit file rather than the thing you assemble for one.
That’s what the OKR tracker at Local Government Procurement replaced: a spreadsheet one person owned and a weekly executive pack assembled by hand. It’s the same shape as the hazard register in the catalogue, and the same shape as an expiry tracker for screening checks. What changes between them is the obligation, not the build.
If you’d rather start small, the Policy Acknowledgement Centre is a register of who has read which policy, deployed into your own tenant. It’s the light version of this.
Proof: LGP
Local Government Procurement tracked objectives in a spreadsheet one person owned, and assembled the weekly executive pack by hand. TechRam built an OKR tracker on SharePoint lists where owners update their own progress, and the executive report now builds itself from live data every week.
Weekly
report writes itself
Built under this service
Hazard Management
Report, triage, close and report on hazards without a spreadsheet.
Read the entry → — Hazard ManagementOKR & Objectives Tracker
Objectives, owners and progress in one place the executive actually opens.
Read the entry → — OKR & Objectives Tracker
Related reading
How do you prove your staff have read a policy?
Read it → — Proving staff have read a policy
Start here for free
Policy Acknowledgement Centre
Deploys in about an hour
Deploy it in your own tenant → — Policy Acknowledgement Centre
What this does for your AI
A register with owners, dates and states is something an assistant can answer from. A spreadsheet is something it can only guess at.
Common questions
01. Why build a register on SharePoint rather than keep the spreadsheet?
The spreadsheet works until the one person who understands it is on leave. It has no owner on each row, no history of who changed what, and nothing that warns you before a date lapses. A register on SharePoint has all three, and the audit trail is written as the work happens rather than reconstructed when someone asks for it.
02. Can a register be kept up to date from the field, on a phone?
Yes. The person closest to the work enters it once, and the record carries through to the audit file without anyone retyping it. That is the whole point: the people doing the work stop being the ones keying data twice.
03. Would an auditor accept a SharePoint register as evidence?
If it's built as one. An audit asks who did what, when, against which version, and whether a check was current at the time. A register with owners, dates, versions and retention holds that; a shared spreadsheet doesn't. Which obligations yours has to satisfy is a discovery question, not something we assume.
04. What does a register or tracker cost?
Fixed scope, quoted in writing before work starts, and the number doesn't move because the work turned out harder than we expected. We don't publish a range, because the scope is what sets it and a range without a scope is a guess you would have to unlearn.
05. Do we need new software to run a register?
Almost never. A register is a SharePoint list, Power Automate for the reminders and routing, and a Power BI view where it helps — all inside the Microsoft 365 licensing you already have. We don't resell licences and we don't earn a margin on them.
06. When is it a register, and when is it a custom operational app?
A register is the simplest system we build: one list, with owners, dates, reminders and a view over the top. When the process has intake, routing, approvals and handoffs between teams, that's a custom operational app. Plenty of organisations start with a register and grow it into one.