An email saying “we’re looking into it” is welcome when your business software stops working. It tells you somebody has received the report. It does not tell you whether orders can move, staff can finish payroll or customers can complete a purchase.

For an SME, the useful question is what happens between that first reply and normal work resuming. You do not need to manage the supplier’s engineers. You do need a shared understanding of the problem, the next action and who will keep you informed.

Describe the business impact

Start with the task that has failed. “The system is down” can mean anything from one person being unable to sign in to every order being blocked. Explain who is affected, when the fault began, what still works and whether there is a deadline.

For example: “Three warehouse staff cannot print dispatch labels. We can enter orders, but nothing has left since 9am.” That gives a support team something concrete to investigate and prioritise. Include an error message or reference number where available, using the agreed secure channel for sensitive information.

Separate acknowledgement from progress

Ask what your support arrangement means by a response. Is it confirmation that a report has arrived, an initial assessment or the start of technical investigation? When does the clock run, and what happens outside normal support hours?

Also distinguish getting the business working again from identifying and fixing the underlying cause. A temporary measure might restore a task while investigation continues. Agree what each stage means so that a closed ticket does not come as a surprise when staff are still struggling.

Give the incident a clear owner

A business application may depend on a hosting company, an application developer and another service, such as a payment provider. When something fails between them, the customer can become the messenger.

Ask who will coordinate the investigation, collect evidence and communicate the combined position. That person need not fix every component personally. Their role is to make sure the next action has an owner and does not disappear between separate support queues.

On your side, nominate someone who can explain business priorities and arrange testing. Keep their deputy informed too.

Set the next update

An uncertain restoration time is frustrating, but a confident guess can be worse. Ask what is known, what remains uncertain, what is being checked next and when you will hear again.

The next update should happen even if the investigation has not yet found the cause. That lets you decide whether to change staffing, warn customers or use another process. Agree how an issue is escalated if its impact grows, progress stalls or an important deadline approaches.

Keep a brief incident log of decisions and updates, so a change of shift does not mean starting the same conversation again.

Check the workaround

A suggested workaround needs a business check as well as a technical one. Re-entering an order, for example, may appear to solve a problem while creating a duplicate elsewhere. Exporting information to a spreadsheet may introduce access or reconciliation problems.

Ask what the workaround changes, who may use it and what needs checking afterwards. Record any manual transactions so they can be reconciled when normal service returns. Do not bypass access controls or make unapproved changes simply to get past an error.

Where practical, try the workaround on a small, controlled example before asking everyone to use it. Agree what would make you stop and call support again.

Define what recovery looks like

“The server is running” is useful technical information. The business still needs to know whether the interrupted task works from beginning to end.

Agree a short acceptance check with the supplier. For a dispatch problem, that might mean creating the label, confirming the correct order status and checking that the customer notification was sent once. Choose checks relevant to the actual fault.

Before closing the incident, confirm whether any orders, payments or records need reconciliation. Identify who owns that work, what remains outstanding and whether extra monitoring is needed. A named person in the business should confirm that the affected process is usable again.

Learn from a repeat

Once the immediate pressure has passed, ask for a short explanation of what happened, what restored service and what will reduce the chance of a repeat. Separate confirmed causes from assumptions.

Any follow-up action needs an owner and a review date. If a permanent fix requires a separate change, ask how it will be assessed and scheduled.

Good support becomes easier to judge when these expectations are explicit. Before the next fault, ask your supplier to walk through a realistic incident with you: report, assessment, ownership, updates, workaround, recovery and follow-up. The answers should help you plan what your business will do while the technical work is under way.

Author bio
Graham Church, founder and managing director of CodeFirst, has 30 years’ professional software development experience. Founded in 2012, CodeFirst takes over, supports and modernises business software built by others. The UK company also builds new systems and improves the performance and reliability of applications that organisations depend on every day.