Reading the Business, Not the Queue: A Board-Ready IT Ledger for UK SMEs
Photo: UgandaWiki, CC BY-SA 4.0, via Wikimedia Commons
Ask a finance director what the IT provider delivered last month and the answer is usually a number: tickets closed, first-response attainment, an uptime figure to two decimal places. Ask what the business got for the money and the conversation tends to stall. That gap — between supplier activity and business effect — is where accountability in managed IT quietly disappears.
Why the monthly ticket pack fails the board test
Service reports are written by the people delivering the service, for an audience that already understands them. A fourteen-page pack of queue volumes, engineer utilisation and SLA attainment tells a director almost nothing about whether the warehouse picked orders on Monday morning, whether the finance team closed the month on time, or whether a new starter waited two days for an account.
The format also invites a defensive reading. Attainment sits at 97 per cent, the page is green, and the meeting moves on — even if users spent the same month working around a failing line-of-business application.
Directors are not being difficult when they disengage from these packs. They are applying the right filter: if a measure cannot be connected to cost, risk, revenue or staff experience, it does not belong in a board conversation.
Five questions a director is entitled to answer
Every line in a results ledger should trace back to one of the following:
- Did our people have working technology when they needed it, and for how long did they not?
- If we lost a system tomorrow, how quickly and how certainly could we be trading again?
- What did we actually do this quarter to reduce the chance of a serious incident?
- Which improvements did we pay for, and did they land on time?
- What did we spend against plan, and what explains the difference?
None of those questions is answered by a queue report. All of them can be answered on one page.
The ledger itself: five lines, one side of A4
A workable template for a 30–250 seat UK business looks like this.
| Ledger line | What is recorded | Evidence source | Red flag |
|---|---|---|---|
| Productive time lost | Aggregate hours users could not work, split by team | Ticket timestamps plus outage log | More than 40 hours per 100 staff in a month |
| Recovery confidence | Date of last successful end-to-end restore; elapsed time against target | Restore test evidence, not backup job logs | No test this quarter, or restore slower than agreed |
| Security actions | Completed versus planned: patching coverage, MFA, phishing simulation results, Cyber Essentials progress | Remediation tracker | Two consecutive quarters of slippage |
| Change delivery | Percentage of agreed improvement work delivered by the promised date | The list agreed at the start of the quarter | Below 80 per cent, or scope altered without a decision |
| Spend against plan | Actual versus budget, split support, licensing and project | Supplier invoices and the approved budget | Unexplained variance above 10 per cent |
Five lines will not cover everything, and that is the point. The discipline lies in what is excluded. Anything that cannot earn its place beside those five becomes an appendix nobody reads — or is dropped altogether, which is usually the better outcome.
The page should carry three further items beneath the table: the name of the person accountable for each line, the agreed threshold, and the two changes committed for the coming quarter. A ledger without owners and commitments is just a shorter report.
Thresholds turn numbers into decisions
A red flag is not an accusation; it is an agenda item. The useful move is to agree the thresholds with the supplier at the start of the quarter, in writing, so that the review discusses the number rather than the relationship.
A worked example: if productive time lost breaches 40 hours per 100 staff, the supplier brings a short written cause analysis and a proposed corrective action to the next review. No escalation, no blame — simply a defined next step that both parties already accepted.
This is where the ResultIT view is straightforward: a threshold agreed in advance is worth more than a service credit argued after the fact.
A quarterly cadence that borrows time rather than adding it
Boards and senior management teams do not need another meeting. They need a better forty-five minutes inside one they already hold.
The pattern that tends to work:
- A week before the meeting, the supplier and the internal IT owner circulate the single page. No appendix, no slide deck.
- Ten minutes walking the ledger, reading the numbers aloud so nobody has to interpret them privately.
- Fifteen minutes on the red flags and the proposed corrections.
- Fifteen minutes agreeing the two changes for the next quarter, with dates and owners.
- Five minutes recording decisions. The supplier attends the first twenty-five minutes only.
Monthly reporting continues at an operational level, but the board sees the ledger quarterly. A quarterly rhythm is enough to keep accountability visible and slow enough to show genuine movement rather than noise.
Where ledgers go wrong
Three failure modes are common. The first is the ledger that becomes a second report — twelve lines, three sub-tables, and no audience. The second is the measure chosen to flatter: productive time lost calculated only from tickets the user bothered to raise, which quietly understates the problem. The third is the missing owner, which turns a management tool into a spectator sport.
A fourth deserves mention: treating the ledger as a stick. Suppliers respond to public scoring by managing the score. If the conversation is framed as a joint review of evidence, with the thresholds agreed in advance, the incentive to game the numbers falls sharply.
Starting this quarter
Do not launch all five lines at once. Pick two — productive time lost and recovery confidence are the usual starting pair, because both are easy to source and both matter to a board — and run them for one quarter. Add change delivery and spend next, and security actions after that.
The test of a good ledger is simple. Hand it to a director who has never sat through a service review and ask what they learned. If they can answer in two sentences, the page is doing its job.
