Dashboards, approval queues and internal tools

Internal tools development is the work of designing and building software for a team’s operational tasks. That can be an approval queue, a dashboard, a client portal or a focused screen that brings together records from several systems. It is not necessarily a replacement for the systems you already use. Often it is the missing layer between them.

Approval workflow software should make a decision clear: what is proposed, why it needs review, what evidence supports it and what happens after approval. A button labelled approve is not enough. The reviewer needs the authority to act, an option to reject or edit, and a record of the outcome. The system also needs a way to handle unresolved work.

An AI dashboard should distinguish completed actions from recommendations and failures. Confidence indicators, where used, need a defined meaning and should not be presented as certainty. We design around the team’s job, not around impressive-looking charts. The useful measure is whether someone can find the item, understand the issue and act appropriately.

An invoice exception queue can show the extracted details beside the purchase order, highlight a mismatch and let an authorised person approve, edit or reject the proposed action. The decision is recorded before the workflow resumes. This is an example of human supervision, not a claim that every invoice should be approved by an AI system.

An operations dashboard can bring together pending tasks, failed runs and items waiting for a person. A client portal can collect structured information instead of a long email chain. A sales review screen can present a drafted reply with relevant account context, leaving the person responsible for the communication in control.

Website and migration work can also involve interfaces: preserving enquiry journeys, rebuilding resource download pages or connecting forms to the right operational workflow. Existing URLs, accessibility, permissions and consent handling matter. A new page that loses the original contact route or exposes private files is not a successful migration, however tidy it looks.

The Role Replication Sprint gives us a five-day starting point around one role’s workflow. We map who uses the screen, what they need to see and which decisions they make. We can build and test a bounded interface alongside the workflow so the person doing the job can assess it. Suitable examples and an available reviewer are essential.

Full Deployment is scoped separately. We agree the data sources, permissions, states, validation and integration behaviour. Loading, empty, failure and access-denied states need deliberate design. A portal for external users has different requirements from an internal review queue. Authentication and authorisation belong in the design rather than being added after the screens are finished.

Run means keeping both the interface and the underlying workflow observable and maintainable. Your team needs to know what happens when a connected system is unavailable and whether an action succeeded. Ongoing Support can cover monitoring and optimisation. Changes to permissions, fields or workflow rules should be tested before they affect live work.

A custom interface is not always necessary. If your existing CRM, accounting platform or Microsoft tools already provide the required screen, configuration may be enough. If the team cannot agree the process or ownership, a dashboard can make the confusion more visible without resolving it. Start with the job and the decision, not a request for more charts.

We also avoid treating an interface as a shortcut around another system’s access rules. Data should only be shown to people permitted to see it. High-stakes decisions need accountable reviewers, and a portal handling sensitive information needs appropriate controls. A smaller approval screen or a better form may be the right first step instead of a large bespoke application.