Before you build an internal tool, map the handoffs

An internal tool is often requested as a list of screens: a dashboard, a form, a report. That list can be useful later. It is not the best place to begin.

Start with one piece of work moving through the business. Who receives it? What information do they need? What happens next? Where does it wait?

Find where the work gets stuck

A workflow might cross a spreadsheet, an email thread, an accounting package, and a shared drive. None of those tools is necessarily wrong. The trouble often sits between them.

Look for information entered twice, decisions made without the right context, and work that stops when one person is unavailable. Ask the people doing the work to walk through a recent, ordinary example—not just the ideal process.

Write down the exception paths as well. A system that handles the usual case but forces every exception back into email may not remove much work.

Decide what success would mean

Before choosing technology, agree on a baseline. Useful measures might include:

• Time from a request arriving to the first useful response.
• Manual steps required to complete one ordinary transaction.
• Number of corrections caused by copied or incomplete data.
• Time spent locating the information needed for a decision.

Choose a measure that reflects the problem you want to solve. A small sample of real work is more useful than a confident estimate.

Build one complete path

The first release should complete a useful workflow from start to finish. It does not need to serve every department or automate every exception.

Keep existing systems where they work. Define which system owns each record. Make failures visible so someone can recover without guessing whether an action already happened.

A reliable integration may be enough. A new application makes sense when the workflow needs its own interface, permissions, or decision process.

Plan for looking after it

Someone will need to change this system after the first release. Agree on who can deploy it, where its source lives, how data is backed up, and how an issue gets diagnosed.

Those are not finishing touches. They determine whether the tool remains useful after the people who built it leave.

Talk to DRU about a workflow worth improving.