Beyond the Minutes: A Decision Register for UK Client Work
Meeting minutes have a comforting weight. They are circulated, filed and rarely read again. The decision that shaped the work — a change of scope, a revised acceptance date, a concession on access — can sit inside them like a stone in a loaf. When the next query arrives, the team must reconstruct what was agreed, by whom and from when.
A decision register does a narrower job. It does not summarise conversation. It records the commitments that alter the work, in a form that can be read in under a minute. For UK service teams, the discipline is less about software than about agreeing what counts, who maintains the record and how it is used when memory is contested.
The gap between discussion and commitment
Most client meetings produce opinions, options and a measure of polite ambiguity. A decision is different. It changes what someone will do, pay, accept or stop doing. A useful test is simple: if nothing downstream changes, it is probably not a decision. If the team would act differently because of it, it belongs in the register.
This distinction matters because minutes are written for completeness. A register is written for use. It should answer four questions without recourse to the original meeting: what was agreed, who approved it, when it takes effect and where the evidence sits.
A six-field register
A workable register needs few columns. The exact labels matter less than consistency.
Decision reference. A short sequential identifier, such as CL-2026-014. It gives the team something to cite in emails, change requests and handover notes.
Decision statement. One sentence, active voice, with the object and its limit. Not discussed access arrangements, but client approved Saturday access for the first two weeks of the mobilisation period, excluding bank holidays. If the sentence needs a second paragraph, the decision is not yet clear.
Client approver. The named individual who had authority to agree it. A job title alone is weak evidence. Where approval came through a group email, record the person who confirmed it and the date.
Internal owner. The person accountable for carrying the decision through. This is not always the person who attended the meeting. It is the person who will notice if the decision is not applied.
Effective date. The date from which the decision changes the work. A decision taken on 3 November may take effect on 1 December. Recording only the meeting date invites confusion later.
Evidence. A link or reference to the email, signed note, change request or minute where approval is visible. The register should point to evidence, not duplicate it. A second column for status — proposed, approved, superseded or withdrawn — prevents a draft idea being mistaken for a commitment.
A ten-minute weekly discipline
The register fails if it becomes a second set of minutes. Keep it to decisions only. At the close of the weekly client meeting, the service lead reviews new entries, confirms the decision statement is unambiguous and checks that the approver had authority. Anything unresolved is marked proposed, not approved.
One person should own the register. Others may add candidates, but the owner is accountable for quality. In smaller teams, that is often the client manager. In larger teams, it may sit with a service delivery lead who already controls the action log. The register should live where the team works — a shared spreadsheet is sufficient — not in a folder that requires three clicks and a password reset.
When a decision changes
Decisions are rarely final in the sense of being untouched. They are superseded. Never overwrite an entry. Add a new row, mark the earlier decision superseded and cross-reference the replacement. The register then becomes a history rather than a list.
This matters in service work where small concessions accumulate. A relaxed reporting deadline in month one can become an expectation by month six. A superseded entry shows when the change happened and who agreed it, which is more useful than a tidy record that conceals the sequence.
Handover and disputes
At handover, the register is a transfer instrument. A new account manager can read the recent approved decisions, the pending approvals and any future effective dates. The question is not what did we discuss, but what remains binding and what still needs a client signature.
During a dispute, read the register chronologically. Separate approved entries from proposed ones. Follow the evidence links rather than relying on recollection. The register will not replace a contract, but it can show the pattern of operational agreement that sits alongside it. That pattern is often what a client remembers differently.
Quarterly review
A quarterly review turns the register into a management tool. Count decisions by type. Identify approvals that have sat pending for more than 30 days. Look for decisions with no effective date or no named approver. Check whether superseded entries have been closed out in the delivery plan.
The review also exposes behaviour. A client who repeatedly agrees in conversation but not in writing is a risk. A team that records decisions only after a problem arises is reacting, not managing. The register makes both patterns visible without requiring a confrontation.
Common failure modes
Most registers fail for predictable reasons. They become meeting notes in disguise. They name a client organisation rather than a person. They omit the effective date. They store evidence in a personal inbox. They are updated monthly and trusted daily.
Avoid these by keeping the register short, naming an owner and reviewing it weekly. A spreadsheet with six columns and twenty live rows is more useful than a sophisticated system that nobody maintains.
Start small, keep it current
The aim is not a perfect archive. It is a reliable answer to a simple question: what has actually been agreed? For UK service teams, that answer protects delivery, supports handover and reduces the scope for disagreement. The decision is the deliverable. The register is how the team proves it.
