Operations
How to Run a 30-Day Operations Review
By MegaPhoenix Editorial Team · · 7 min read
You do not need a consultant to find your biggest operational problems — you need four structured weeks and the discipline to write things down. This is the review structure we use as the backbone of an Operations Assessment, adapted so you can run it yourself.
Week 1: List what actually happens
Write down every recurring process in the business: quoting, onboarding, fulfilment, invoicing, support, purchasing, reporting. For each, note the owner — a name, not a department — and how often it runs.
Two rules. List what really happens, not what should happen. And include the invisible work: the checking, chasing and re-entering that nobody was ever assigned but everybody does.
Week 2: Put numbers on three of them
Pick the three processes that touch the most money or the most customers. For each, measure for one week: how long does one case take from start to finish, and how much of that is the work sitting and waiting?
Pull whatever numbers already exist — invoice dates versus delivery dates, response times in your inbox, error or refund counts. Precision matters less than honesty. “About nine days” measured beats “about two days” assumed.
Week 3: Ask the people who do the work
Hold three or four short conversations, one per process. Three questions are enough: What slows you down? What do you fix that should never have broken? If you could change one step, which would it be?
Listen without defending the current process. The answers will cluster — the same bottleneck mentioned by three different people is real, whatever the org chart says.
Week 4: Decide what to fix first
You now have a process list, real durations and first-hand complaints. Combine them into one ranked list using two questions per problem: what does it cost per month, roughly, and how hard is it to fix?
Cheap-to-fix and expensive-to-ignore go first — they fund the rest. Then write a one-page plan: the fix, the owner, the date, and the number that will prove it worked. Put the review on the calendar to repeat in six months.
When to bring in help
Run the review yourself when the problems look local and the team has the hours. Bring in outside help when the numbers are scattered across systems, when the problem crosses several teams, or when you want an honest picture — people tell an outsider things they will not tell their boss. Either way, the structure above is the one to follow.