The week after a peak sales period is the most informative week of your operational year, and it has a short shelf life. Whatever your staff did by hand during those ten days is your automation backlog, written by the people who had to do it. Whatever broke under load will keep breaking in smaller, quieter ways for the rest of the year. Both are obvious in early December and forgotten by February.
This guide is for an owner or operations lead running the review, particularly one who suspects the supplier's version of events will be that everything went fine.
Key takeaways
- Run the review within two weeks, while the people who were there still remember the detail.
- Manual work during peak is a specification, not a sign that people worked hard.
- Ask what nearly went wrong, not only what went wrong; near misses are the cheapest lessons available.
- Separate what the load caused from what the load revealed: the second category is the one that matters all year.
Ask the people, not the systems, first
Start with the staff who processed orders, answered the phone and handled the exceptions. Four questions, in a room, not by email.
- What did you do by hand that week that you do not normally do?
- What did you do more than ten times that should have been one action?
- What did you find out from a customer rather than from a system?
- What did you stop doing because there was no time, and has it been picked up since?
The last one is important and easy to miss. Work that quietly stopped during the peak and was never resumed is a category of failure nobody reports.
Then ask the technical questions
Ask your development team or supplier for specifics rather than reassurance.
- What was the peak load, and how close was that to where things started to degrade?
- What errors increased, and at what point?
- What was changed during the week itself, and why?
- What was nearly a problem, and what stopped it becoming one?
- Which parts would need work before the same volume again?
A team that can answer these has been paying attention. A team that reports only that it went well may be right and is not telling you anything you can act on.
Separate caused from revealed
Two different lists come out of this, and they have different urgency.
Caused by the load. Things that only break at volume: timeouts, queues backing up, provider limits. These matter once or twice a year and can be planned for.
Revealed by the load. Things that are wrong all the time and only become visible when volume makes them expensive: a manual reconciliation step, a report that takes an hour, an integration that fails silently and is corrected by hand. These cost you every month, quietly.
The second list is where the money is. It is also the list that gets dropped, because the first one feels more urgent.
Turn it into a short, ordered list
The output of the review should be one page: five to eight items, each with what it costs, roughly how often it happens, and who owns it. Ordered by cost, not by how annoying it was.
Anything without a named owner will not happen, and anything expressed as a general complaint about a system will not either.
Do it before the January reset
By the middle of January the peak feels like last year's problem and the roadmap conversation has moved on. Running the review in the first week of December, while the invoices are still being reconciled, is what makes it land in the budget and the plan rather than in a document.
Related guides
- If the budget conversation comes first, start with preparing systems for peak sales week.
- If the review is full of manual steps, the hidden cost of spreadsheet workflows puts a number on them.
- There is a longer treatment of the same subject in the automation discovery phase.
If the review produces a list you want scoped and costed before next year's budget closes, Discuss Your Plan.
Ali Boran Gazel