What Should Staff Do When Custom Software Is Unavailable?
Start with the short answer ↓
Give staff a defined fallback for essential work and a clear way to report the interruption. Avoid improvising separate spreadsheets that cannot later be reconciled.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Identify essential actions
Decide which work can wait and which must continue during an outage. For the latter, define the minimum information to record and who owns it. Keep the fallback narrow enough to operate reliably; attempting to recreate every software feature manually may create more confusion.
Use a controlled record
Provide an approved temporary form or procedure with stable references. Explain where it is stored, who may access it, and how duplicate entries are avoided. Do not encourage staff to put customer data into personal tools simply because the normal application is unavailable.
Define communication
Name the person who confirms the outage and gives updates. Tell users how to distinguish a local access problem from a wider interruption. Keep customer-facing messages accurate and avoid estimated restoration promises unless the responsible team has a basis for them.
Reconcile before normal operation
When service returns, compare the fallback records with any work that did reach the application. Assign responsibility for entering or linking missing work and checking for duplicates. Do not declare the incident operationally complete while temporary records still contain unprocessed customer requests.