Skip to main content
All articles

Best Practices

What Should a Stakeholder Commitments Register Include?

A commitment is anything a stakeholder can reasonably rely on. The register is how a project remembers them all, whoever made them and however long ago.
  • November 2026
  • 8 min read

Short answer

At minimum: what was promised (in the original words), who made it and in what capacity, to whom, when and through which channel, a link to the source record, a single named owner, a due date or trigger, a status from a fixed list, and the evidence that it was delivered and that the stakeholder was told. Around those fields you need rules: one register for the client and every contractor, a defined authority to make commitments, a check for contradictions when new ones are added, and a regular review that chases anything overdue.

What counts as a commitment?

Anything your side has said it will do, or will not do, that a stakeholder could reasonably rely on. On a major project they come from three places:

  • Statutory: obligations that flow from approval conditions or approved management plans, such as notifying residents before out-of-hours work.
  • Documented: promises made in an environmental impact statement, a submissions or response report, a landholder agreement, or a benefit-sharing arrangement.
  • Voluntary: things said in the field. "We'll keep your driveway open." "We'll send you the dust results every month." "The crew won't start before seven."

The third category is where most trouble starts. It is rarely written down, it is often made by contractor staff, and it is the one the stakeholder remembers most clearly. If your register only holds statutory and documented commitments, it is a compliance list, not a commitments register.

Keep commitments distinct from issues and complaints. An issue is what a stakeholder raised; a commitment is what you promised. Link them, because a closed complaint with an open commitment behind it is not resolved.

What fields should the register have?

Enough to answer, years later and without the original staff, the questions a stakeholder, a lawyer or an auditor will ask: who said what, to whom, when, on what basis, and what happened next.

Recommended fields for a stakeholder commitments register
FieldWhat to record
IDA unique, permanent reference. Never reuse a number.
WordingWhat was said or written, as close to verbatim as possible, plus a one-line plain summary.
Made byThe person, their organisation (client, contractor, subcontractor) and the capacity they spoke in.
Made toThe stakeholder, group or property the commitment was made to or is about.
When and howDate, and the channel: meeting, call, letter, email, doorknock, submissions report, approval document.
Source recordA link to the note, letter, recording or document it came from. No source, no commitment.
OriginStatutory (from a condition), documented (from an EIS, submissions report or agreement) or voluntary (made in the field).
OwnerOne named person accountable for delivery or closure, not a team or a company.
Delivered byWho will physically do it, if different from the owner, such as a contractor package.
DueA date, or a trigger such as "before works on Lot 12 start".
StatusFrom a fixed list: open, in progress, delivered, varied, withdrawn, superseded.
Evidence of closureThe record that proves it was done, and the record that the stakeholder was told.
LinksRelated commitments, the approval condition or plan it supports, and any conflict flagged against it.
SensitivityWhether it contains personal, commercial or culturally sensitive information, and who may see it.

Two fields do most of the work. The source record turns a line in a spreadsheet into something defensible, because anyone can open the note or letter and check it. The original wording matters because summaries drift: "we'll look at screening" becomes "screening promised" after two handovers, and the stakeholder now expects a fence.

How should status and closure work?

Use a short, fixed list of statuses, and make closure depend on evidence rather than on someone ticking a box.

  • Delivered needs two records: proof the thing was done (a photo, a works record, a sent report) and proof the stakeholder was told.
  • Varied means the commitment changed. Keep the original wording, record the new one, the reason and the date, and record how the stakeholder was told.
  • Withdrawn should be rare and should always carry a reason and a record of the conversation with the stakeholder.
  • Superseded links to the commitment that replaced it, so the history reads as a chain rather than a contradiction.

Never delete a commitment or overwrite its history. An edit log showing who changed what and when is part of the record. For public bodies it may also be a legal requirement: in NSW, for example, the State Records Act 1998 requires public offices to make and keep full and accurate records of their activities. Check the recordkeeping rules that apply to your organisation and your contract.

How do contradictions arise across contractors?

Mostly through ordinary delivery. Several organisations talk to the same residents, each with its own records, and nobody checks a new promise against what the others have already said. Common causes:

  • The client team, a principal contractor and its subcontractors keep separate logs.
  • A design or staging change makes an earlier commitment undeliverable, and nobody tells the people who made it.
  • Field staff aren't clear on what they may promise, so they promise what seems reasonable on the day.
  • A package finishes, the contractor demobilises, and its open commitments leave with it.
  • Two people paraphrase the same conversation differently.

Controls that work:

  1. One register. Require every contractor, by contract, to record commitments in the client's register against the same stakeholders and properties, not in a separate system that is reconciled later.
  2. Authority to commit. Write down who may commit to what. For example, field staff may commit to information and minor works within a set scope; anything involving access, design, money or timing goes to a named role.
  3. Check before contact. Before a meeting or doorknock, read the stakeholder's or property's open commitments.
  4. Check on entry. When a new commitment is added, compare it with open commitments for the same stakeholder or property and flag conflicts to the owner.
  5. Handover gates. No package closes out until its open commitments are delivered, varied with the stakeholder's knowledge, or transferred to a named owner.

Handover is the riskiest moment, and it gets its own article: engagement handover between contractors.

A worked example (hypothetical)

On a road upgrade, a civil subcontractor's supervisor tells the owner of a rural property that their driveway will stay open throughout. Three months later, the principal contractor's traffic team writes to the same owner advising a three-day closure. Neither knew about the other. With one register, the supervisor's promise would have been on the property's record with its source, and the closure letter would have been flagged as a conflict before it was sent. The fix might have been the same closure, but explained in person, with an alternative access arrangement offered and recorded as a varied commitment, rather than discovered by the owner from a letter.

What governance keeps the register alive?

A register stays useful only if someone owns it and it is reviewed on a rhythm. A workable pattern:

  • Capture standard. Set an internal time limit for entering a new commitment after it is made, short enough that the detail is still fresh.
  • Weekly: owners update status; overdue and due-soon items are chased.
  • Monthly: a report to the project leadership on open, overdue, varied and conflicting commitments, by package and by owner.
  • Read-back: for significant stakeholders, periodically confirm in writing what you understand you have promised. It surfaces misunderstandings early.
  • Privacy: the register holds personal information. Where the Privacy Act 1988 applies, the Australian Privacy Principles require reasonable steps to protect it, so limit access by role and keep sensitive material visible only to those who need it.

Transport and government projects add their own pressures, including information access requests and ministerial briefings; see transport consultation and the government engagement playbook.

Finally, link the register to what you report publicly. NSW guidance for State significant projects, for example, expects proponents to report back on how engagement has shaped the project. A register that ties each commitment to its source and its delivery makes that report straightforward, and makes it true.

Where VivoAI fits

VivoAI keeps one stakeholder view across portfolio, program and project, so the client team, principal contractors and subcontractors record engagement in the same place, against the same stakeholders and properties. Commitments are picked up from meeting notes, calls and correspondence and linked to the property and the person who made them. When a new statement conflicts with an earlier commitment, it is flagged to the owner to resolve.

Teams start on one or two packages alongside the system they already use. See how it works for infrastructure delivery.

Frequently asked questions

What is the difference between a commitments register and an issues register?

An issues register tracks concerns stakeholders raise. A commitments register tracks what your side has promised to do in response, or otherwise. One issue can lead to several commitments, and a commitment can exist with no issue behind it, such as a promise made in an environmental impact statement. Keep them linked, but separate.

Should informal promises made by field staff go in the register?

Yes. If a stakeholder could reasonably rely on it, record it, even if it was said at the fence or on the phone. Informal promises are the ones most likely to be forgotten internally and remembered externally. Record them with the exact words as best they can be recalled, then confirm or correct them with the stakeholder in writing.

Who should own the commitments register?

The organisation that holds the approval or the relationship, usually the proponent or client, should own the register and its rules, even when contractors make and deliver most of the commitments. Each individual commitment then has its own named owner responsible for delivery or closure.

Can a commitment be closed if it was never delivered?

Only with a record of why. A commitment can be varied or withdrawn, but the stakeholder should be told, and ideally agree, and the register should keep the original wording, the change, the reason and the date. Deleting or silently overwriting it is how contradictions and disputes start.

Sources

This article is general information, not legal advice. Check your own approval conditions, contracts and recordkeeping obligations, and obtain advice for your circumstances.

Next step

See every commitment, whoever made it

One register for the client and every contractor, with each commitment linked to its source and contradictions flagged before the stakeholder finds them.