Decision Framework For A First-Version Internal Tool

The question that exposes a shaky process is simple: what would stop working tomorrow if one specific person stopped doing one manual thing. The answer is usually uncomfortable.

This piece is about decision framework for a first-version internal tool, and specifically about a handoff that no one has formally agreed to own. The point here is not to add tooling. It is to find the one place the workflow quietly depends on a person and decide whether that is safe.

01The part nobody puts on a slide

The pattern repeats across very different companies. The tool is not the bottleneck. The bottleneck is a handoff that never got an owner, and an exception that quietly relies on one person being available.

02Where this shows up

An approval sits in an inbox. The person who can sign off is travelling, so the request waits. Nobody is doing anything wrong. The process simply never decided what happens to that request when its owner is unavailable, so the work stalls and a client wonders why.

This is not a tooling problem and not a people problem. It is a design problem, and it is the kind of thing HATT builds for: map the handoffs around the workflow, replace the highest-friction step first, then connect reporting to a real decision. Related reading: how to scope an mvp internal tool without overbuilding.

03The five questions that surface the problem

A short diagnostic that tends to expose the real gap:

1. What is the real cost when a handoff stalls for a day
2. Which step relies on knowledge that lives in one person's head
3. Which exception keeps returning to the same inbox
4. Which meeting exists only to find out what the process should already show
5. Where does work wait between two roles with no one clearly holding it

If the answers are fuzzy, map the workflow before spending on anything new.

04What a practical first build replaces

Do not try to boil the workflow down to one perfect build. Find the step that hurts most when it slips, own that, and let the rest wait until it has earned its own version.

Good first targets tend to look like this:

• The sales to delivery handoff that runs on a forwarded email
• The exception that keeps landing in the same inbox and waiting
• The step that only moves while one specific person is at their desk
• The approval that stalls whenever the one person who signs off is away

Buying a tool buys you speed today and a dependency tomorrow. Building buys you control and a bill up front. The deciding factor is how weird the workflow really is, and how much the odd case costs when it slips through.

05FAQ

How do we know a workflow is ready to automate?

Readiness is about the cost of the exception, not the number of repetitions. If the same messy case keeps landing on one person and it hurts when they are out, that is the part worth building around first.

What is the most common automation mistake?

Automating the happy path and leaving the exception on a human. The rare case is exactly where the process breaks, so a build that ignores it just moves the fragility somewhere quieter. See also integration fatigue when too many tools create manual work.

06The bottom line

Name the handoff in the workflow that has no owner and the exception that waits for one person. That is usually the whole diagnosis, and it points directly at what to build first.

If you want a second set of eyes on where the workflow actually breaks, HATT maps the workflow first and scopes a first version that removes the worst step. You can book a scoping call to talk it through.