Operations Insight
Find the Bottleneck Before Buying Another Tool
Many organizations do not need another tool first. They need to understand where work is getting stuck, what it is costing them, and which systems should be improved first.
3 min read
When intake slows down or reporting takes too long, buying another tool can feel like the obvious next step. Start by finding the specific task that is holding up the work.
A bottleneck might be a manual data transfer, an approval that depends on one person, or a handoff with no clear owner. Each calls for a different fix.
Follow one workflow
Choose a recent request and trace it from arrival to completion. Record where it waited, where information was copied, and where someone had to chase an answer.
Talk to the people doing the work. A process diagram may show a clean sequence while the team relies on informal messages to keep it moving.
Estimate the cost
Measure how often the task happens and how much time it takes. Include the time spent correcting mistakes or checking whether work was completed.
For example, a task that takes 15 minutes and happens 20 times a week consumes five hours. That gives you a concrete baseline for deciding whether a change is worthwhile.
Also consider what the delay blocks. A slow intake review may hold up service delivery, while a slow monthly report may affect a different set of decisions.
Choose the smallest useful fix
The answer could be a clearer responsibility, a simpler form, an integration, or custom software. Choose it based on the cause of the delay.
After the change, check the same workflow again. Did waiting time decrease? Are there fewer corrections? Can the team see who needs to act next?
Those observations are a better measure of progress than the number of tools you have added.
Separate waiting from time spent working
Consider a referral that arrives on Monday but is not reviewed until Thursday. The form might take only a few minutes to read. Adding a faster form will not address the main delay if nobody knows who should review it or if the designated reviewer is available only once a week.
Track both the time spent doing the task and the time the work waits between steps. Also record what the team is waiting for: missing information, approval, a response, or access to another system. Each points toward a different intervention.
Use several recent examples, including one that did not follow the usual path. A single smooth case can hide the exception that consumes most of the team's attention. Treat estimates as estimates until the people doing the work can check them.
Match the fix to the cause
If work waits because responsibility is unclear, first agree on an owner and a backup. If staff repeatedly chase the same missing information, review the intake questions and the way incomplete requests are handled. If people retype an agreed set of fields between two systems, an integration may be worth evaluating.
Write a small before-and-after comparison before committing to implementation. Describe the current step, what will change, who will maintain it, and how the team will tell whether it helped. Include the time required to check errors and keep the new process running, not just the time saved when everything goes well.
Then try the change on a bounded workflow and revisit the same observations. If the delay moved to another step, follow it there. The purpose of the review is to improve how work moves, not to justify a tool that has already been chosen.
For the decisions that need to be settled before implementation, see understanding the workflow before building software.