Before you commission sustainability software: write a one-workflow build brief

A sustainability software build brief is a working agreement about one workflow: who needs to do what, which records they use and what a first release must make possible. Before commissioning a build, write that agreement in plain language. Bring the unresolved questions to the scoping call rather than filling the gaps with a feature list.

The brief below is an editorial worksheet, not a standard Council Fire Labs package, a technical specification or a contract. Use it to prepare a conversation with the people who will build, approve and operate the system.

If you have not decided whether custom software is appropriate, start with how to choose sustainability software: buy, configure or build. This article takes the next step: defining a first release without turning one reporting problem into an enterprise replacement.

What belongs in a sustainability software build brief?

Start with a sentence the program owner and the person doing the work can both recognize:

When [trigger occurs], [user] needs to [make a decision or complete a task], using [source records], so that [program outcome becomes possible].

For a hypothetical resilience program, that might mean a planner preparing a reviewed project shortlist for a funding meeting. The first release could cover project intake, review and the approved shortlist. It need not include a public portal, grant submissions or every department's planning process.

Keep that example hypothetical. Your brief should describe your actual work, including the awkward handoff that a tidy process diagram might leave out. Ask someone to walk through the last completed cycle. Record where they waited, what they reconciled and whose answer allowed them to move forward.

This follows the GOV.UK Service Manual's user-research guidance: understand who users are, what they are trying to do and how they do it now. The guidance treats suggestions that do not come from users as assumptions to investigate. That is a useful discipline for a sustainability sponsor who already has a dashboard in mind.

Council Fire Labs describes its Scope phase as finding the bottleneck and defining the smallest system that removes it. A useful brief gives that conversation a starting point. It should leave room for the builder to challenge the proposed solution.

Who uses it, who decides and who keeps it running?

Name the people involved in the workflow before naming screens. The person entering a record, the reviewer resolving a discrepancy and the sponsor approving an output may need different permissions. A contributor should not acquire approval rights merely because they can upload a file.

For each role, write down its task and the information it must see. Include people outside the sponsoring team: a project partner submitting an update, a grantee correcting a response or a community representative challenging a description. Ask about accessibility, language, device and connectivity needs before choosing an interface.

Council Fire Labs frames responsible design around who can use a tool, whose needs shape its recommendations and who benefits. For this brief, put those questions into the role list. If a proposed feature saves internal effort by requiring more work from partners, record that trade-off and ask those partners about it.

Assign two different responsibilities explicitly:

• A business decision owner accepts the workflow and resolves disputes about what its outputs mean.
• A technical counterpart confirms access, integrations and operating constraints with the relevant system owners.

Then name the person or team expected to administer the release after launch. Do not write only "IT" if no one has accepted the responsibility. An unresolved owner is a scoping question, not a blank the developer should fill by assumption.

Which source records and integrations are actually needed?

List the records required for the selected decision. For each, specify its source, owner, update cadence and the version or reporting period that matters. Distinguish an approved record from a draft submission. Record how someone corrects an error and who decides whether the corrected version replaces the earlier one.

Bring a small, non-sensitive example of the record structure. Column names and dummy values may be enough for an initial discussion. Do not send confidential project records, personal information or credentials through an ordinary inquiry form. Agree a permitted sharing method and access scope first.

For each proposed integration, write the direction of travel. Does the new system read an export, retrieve records through an application programming interface (API), or write changes back? Identify who owns the other system and who can authorize that connection. Mark access as confirmed, requested or unknown.

Avoid "connect to our existing systems" as a requirement. A first-release question is more specific: can the team use an approved periodic export while it investigates direct access? That is a choice to evaluate with the technical owner, not a promise that a file import will meet your needs.

CF Labs' dashboards and data infrastructure offering describes a shared view supported by data pipelines. Make the pipeline's boundary visible in the brief: which inputs it receives, who resolves failures and whether it can change the source. A dashboard does not settle a disagreement about the underlying metric. Keep unresolved definitions on the decision list.

What should the first release leave out?

Write an explicit exclusion list beside the inclusion list. The GOV.UK discovery guidance recommends defining the problem and agreeing what is not part of it before committing to a solution. Its government-service process is not a contractual requirement for your project; the distinction is useful here.

Possible exclusions to discuss include historical backfilling, replacing the system of record, public access, automatic regulatory submissions, payment processing or an organization-wide rollout. Select the exclusions that fit your workflow. Do not paste a standard list into a scope without checking its consequences.

For every exclusion, identify how the remaining work will happen. If historical data stays outside the release, say how users will consult it. If the release prepares a report but does not submit it, name the person who submits it. A narrow release still needs a complete path to the selected decision.

Separate exclusions from prerequisites. "No direct connection in release one" is an exclusion. "The data owner has not approved any export" may prevent the workflow from operating at all. Put prerequisites on an open-question list with an owner and a resolution date, and ask the builder which ones must be settled before a commitment.

Also record constraints: procurement approvals, required hosting arrangements, access rules, retention requirements, review availability and the date the workflow is needed. Mark each as confirmed or still to be checked. Ask which deadlines are external obligations and which are preferences. This brief does not replace legal, security or procurement review.

How will you know the first release is done?

Describe a demonstration the named users can perform with representative, permitted records. Specify the starting state, the actions they take and the output they should be able to inspect. The GOV.UK guidance on user stories describes acceptance criteria as outcomes used to check that a service has met a user need. Use that idea to turn "a working dashboard" into something your team can evaluate.

A recommended demonstration for a reviewed shortlist might show that a contributor can enter an eligible record, a reviewer can return an incomplete one, and the decision owner can approve the resulting shortlist. Ask to see the relevant source records and the approval record, not only the final screen. Include an incorrect or missing input so the team can inspect what happens when the workflow cannot proceed.

These are proposed checks, not claims about a shipped CF Labs feature. Agree the actual tests and acceptance authority during scoping. If the workflow includes artificial intelligence (AI)-generated material, use the separate AI sustainability reporting pilot acceptance checklist to develop the additional controls rather than treating this brief as an AI evaluation plan.

Define operational readiness too. Who has access? Who corrects a failed import? Where are the instructions? What does the team do if the system is unavailable? CF Labs describes its Run phase as hosting or handing over the system with documentation and training. Ask which arrangement, responsibilities and handover materials belong in your engagement; do not infer specific support terms from that description.

Copy this one-workflow commissioning brief

Copy the fields below into a shared document. Keep the answers short enough that the program owner, user representative and technical counterpart can read them together. Leave an honest "unknown" where a decision is still open.

Purpose and people

• Workflow name and brief version/date: ___
• Program outcome this workflow supports: ___
• Trigger and recurring decision or task: ___
• Primary user and current steps: ___
• Bottleneck observed in the current process: ___
• Other contributors, reviewers and affected people: ___
• Business decision owner and release approver: ___
• Technical counterpart and post-launch operator: ___
• Accessibility, language, device or connectivity needs to check: ___

Records and connections

• Required source records, reporting period and source owners: ___
• Definitions or calculations already agreed: ___
• Draft, reviewed and approved states needed: ___
• Correction route and approval record to retain: ___
• Permitted sample format and agreed sharing method: ___
• Required connection, read/write direction and access status: ___
• Update cadence and response to missing or stale input: ___

First release and boundaries

• Included start-to-finish workflow: ___
• Output and decision it enables: ___
• Explicit exclusions and who handles that work instead: ___
• Preconditions that must be resolved before committing: ___
• Security, privacy, hosting, procurement and retention constraints: ___
• Needed-by date, reason and reviewer availability: ___

Demonstration and open decisions

• Starting records and expected result for the demonstration: ___
• Missing or incorrect input to test, and expected response: ___
• Permission and approval checks: ___
• Training, documentation, support and fallback responsibilities: ___
• Evidence the approver will use to accept the release: ___
• Open question / decision owner / resolution date: ___
• Brief approved for scoping by / date: ___

Approval of this brief means it is ready to discuss. It does not authorize data sharing, spending, development or production access.

What should you bring to the scoping call?

Bring the completed brief, a safe sample structure and the people who can explain the current workflow. Highlight the unanswered questions first. Ask the builder to identify assumptions, dependencies and exclusions that would prevent the proposed release from reaching its intended decision.

Council Fire Labs builds software, dashboards and AI systems to make sustainability strategy operational. Its delivery approach starts with scope and continues through Build, Run and Evolve. Use the brief to discuss that first scope, then agree the delivery and operating terms for your situation.

Scope your build through Council Fire's contact page. Choose Software & AI (CF Labs) and describe the workflow. Arrange how to share supporting material before sending sensitive records.

Related Resources

• How to choose sustainability software: buy, configure or build? helps resolve the purchase decision before you specify a custom workflow.
• AI sustainability reporting: a pilot acceptance checklist develops the additional review and acceptance work for an AI-assisted reporting task.
• Grant reporting: which questions can you stop asking? helps funders examine the information request before commissioning software to collect it.
• Why ESG Reporting Needs Live Data Dashboards provides adjacent reading on dashboard inputs, review and reporting views once you have defined the decision they support.

Additional Resources

• Learning about users and their needs, GOV.UK Service Manual: foundational guidance on researching current tasks and separating user evidence from assumptions.
• How the discovery phase works, GOV.UK Service Manual: a government-service guide to problem boundaries, constraints and the decision to proceed.
• Writing user stories, GOV.UK Service Manual: a practical explanation of users, goals and acceptance criteria.

About the Author

Zach Chmael is Council Fire's Marketing Manager. Explore Council Fire Labs for the firm's software and AI work supporting sustainability strategy.

Cover photograph: Pexels — Terraced fields viewed from above. Illustrative stock photograph, not a Council Fire project.

Written by

Zach Chmael

Marketing Manager

Filmmaker, photographer and storyteller for purpose-driven organizations.

Full bio →All 4 articles by Zach →

From the library

• Topic hubSustainability Strategy→
• Topic hubStakeholder Engagement→
• GuideDouble Materiality Assessment Guide→

Around The Fire, in your inbox.

New articles on climate resilience, sustainable business and the end of extraction, sent when they publish.

Email addressSubscribe