When sales increase, some costs are easy to predict. More stock needs more space. More parcels need more packing time. Software costs are less obvious, especially when the applications keep running, and nobody reports a failure.
An order might still need to be copied into the accounting system after it arrives in the shop. Someone does that between other jobs, so the task has no separate budget. Later, with more orders coming in, the same employee starts staying late. The business may put this down to being busy without asking how much of the extra work comes from entering information it already holds.
Work That Never Gets Counted
Ask an employee how they confirm stock, and they might name the inventory application. Watching them do it can reveal a longer process. They open the application, compare it with a spreadsheet, then message the warehouse about an item whose quantity looks wrong. Only after that can they answer the customer.
All of this may be covered by one line in the procedure: check availability. A few days of notes can give a rough idea of the time involved. Record which orders needed additional checking, what caused it, and how long the employee spent resolving it. Include the messages sent after the order was processed.
At five minutes per order, a hundred orders require more than eight hours of work. The average will vary, particularly if a few difficult cases take most of the time.
Sometimes, the constraint is one person’s availability. Refunds may need a manager’s approval, for example. Another employee could prepare the request, but it would still sit in the same queue.
Why Is That Spreadsheet Still There?
Businesses often have files that nobody planned to keep using for so long. A spreadsheet created for a temporary promotion becomes the place where special prices are recorded. A customer service export acquires extra columns because the main application has nowhere to store delivery instructions.
Removing these files takes more thought than cancelling an unused subscription. Employees may depend on information that would otherwise disappear from their working day.
It helps to find out what each file contains and who updates it. A sheet used by one person to organise their work is different from a stock record used by the whole sales team. With the latter, an outdated copy can affect orders before anyone notices.
Returns are worth following through the records. The original purchase may pass neatly between applications, while the refund requires a spreadsheet entry and an email to finance.
After the Order Has Been Sent
A warehouse connection can work reliably for new orders and still cause trouble with changes. Packing instructions have already arrived when the customer cancels an item. The cancellation appears in the shop, but the parcel goes out with the item inside.
If cancellations stop reaching the warehouse once packing begins, customer support needs to know that cutoff. Without it, staff may promise a change that the warehouse can no longer make.
Keep the cancellation email and both versions of the order, the one in the shop and the one sent to the warehouse. A business using technology consultation services can hand over these records rather than try to describe the fault from memory. The warehouse copy might still contain the cancelled item. Staff messages can help establish whether anyone noticed before the parcel left.
There is also a practical limit to check with the warehouse: at what point is it too late to change the contents of a parcel? That may depend on its packing process as much as on the software.
What Will Actually Increase?
“More business” is too vague for a software test. Another thousand products could mean days spent entering descriptions and sorting out stock records, with no increase in checkout traffic. An upload using actual product data would show how much work remains afterward. Missing fields and rejected records still need someone to fix them.
For a sale, follow a paid order until it reaches the warehouse. Then repeat with purchases arriving close together. The delay may be small enough on an ordinary day that nobody records it.
The supplier may already have results worth using. Look for the volume tested, the time orders took to arrive, and any failures staff had to resolve. The number of users supported does not answer those questions. If another test is needed, run it separately from the live shop where possible.
The Weekly Report Takes Longer Now
A sales export may have been enough when one person needed the weekly figures. They downloaded it, added costs from another file, and checked a few entries.
Then purchasing wanted a breakdown by product. Finance needed refunds included. A second location meant separating its sales from the original shop’s figures. The same employee now spends much of the morning preparing several versions, even though each report still starts with a quick export.
Before adding a dashboard, establish what the figures mean. “Open orders” might refer to unpaid purchases in finance and unpacked orders in the warehouse. Both totals could be accurate. Presenting them on the same screen will not make them comparable.
The useful questions are fairly narrow:
- Which record supplies each figure;
- How often that record is updated;
- Who corrects errors in the original data;
- How much checking the report needs before it can be used.
For reporting work, the time saved should include preparation and checking, rather than just the time taken to generate the file.
During an Outage
A backup may be available without anyone having recently tested how to restore it. Access may depend on an employee who is away.
Restoring yesterday’s data could leave today’s orders to be reconstructed from payment records and customer emails. That would take longer at a higher sales volume.
If delayed stock updates cause most of the checking, repairing that transfer may be enough for the next increase in orders. The staff doing the checking should remain involved afterward. Their workload will show whether the change helped, including any extra work that the new process introduced.
