Build a system your team can run

A delivery team can have a website, a scheduling app and a beautifully organized spreadsheet and still have no reliable answer to “Has this address change reached the driver?” Each tool works; the agreement between them does not.

A business system makes the condition of the work understandable across people and tools. Its most important feature may be a dependable shared answer about what has happened, what can happen next and who is responsible. That is what turns a collection of applications into an operation.

Make the status mean something

A label such as “complete” hides a surprising amount of policy. Does it mean the worker finished, a supervisor checked it, the customer accepted it or the invoice was sent? If teams use different meanings, a shared dashboard can make them confidently disagree.

Useful states correspond to observable events. “Ready for dispatch” should mean the necessary details have been checked and someone may act on them. The system also needs a response when reality changes: an address correction after dispatch is a new event with consequences, rather than just a different value in a cell.

This is why a small system with clear transitions can outperform a larger feature collection. It reduces the amount of history people must reconstruct before making the next decision. Follow an ordinary job and a corrected one; the corrected job will often tell you more about the design.

The pattern is a dependable shared record

Many operational systems revolve around a record that changes state: received, checked, assigned, completed. The exact states should come from the work. Each transition needs a responsible person or rule, and enough history to explain what happened.

The screens can stay modest. A public form, a staff view and a notification may be sufficient. Other tools can remain in place if their roles are clear. The architecture becomes easier to reason about when each kind of information has an agreed home and each handoff has a defined destination.

This does not require one enormous database or application. A useful boundary might separate customer information from delivery scheduling while allowing the two to exchange the fields they need. Integrations explains that boundary in more detail.

Fit the tools to the team

The Community Thanksgiving Dinner Foundation needed a public website connected to its operational work, including delivery management. We built those pieces together, using Cloudflare Pages and Workers alongside custom Google applications built on Sheets. Familiar tools stayed central to the team’s process.

The important decision was the scope. The build supplied the needed features without adding Wix, Airtable and a stack of per-seat subscriptions. Features that would complicate the work were left out. That is the reasoning behind the CTDF project; it is not a rule that custom software is always cheaper.

For another organization, a well-supported existing product may be the better answer. We compare configuration, integration and custom development before choosing the implementation.

Things to consider before commissioning it

• Who can change a record, and who can correct a mistake? Access should reflect actual responsibility.

• What needs to work when a person, vendor or connection is unavailable? Write down the fallback.

• Can a second team member run the process using the instructions provided? A developer’s memory is not a handover.

• What recurring work and bills will the system create? Include review, support and updates in the decision.

• Which parts are likely to change? Keep those rules understandable and separate from unrelated functions.

Start with one complete operation

An initial release should carry one meaningful piece of work all the way through. Define the expected result, test ordinary and awkward cases, and let the people doing the work try it. A smaller complete operation is easier to evaluate than a large collection of disconnected screens.

Before commissioning a build, prepare a simple map, a few representative records and a list of the decisions that currently need clarification. Those materials are useful whether you buy a product, build a system or ask for an independent review.

For a broader service-design perspective, the GOV.UK Service Standard is a useful reference. Its attention to users, the complete service and ongoing operation translates well beyond government. Our practical ownership guide turns the post-launch questions into a working checklist.