At seven on Monday morning, a branch supervisor cannot open the dispatch screen. Two orders were confirmed before the problem appeared. A third may have reached the server even though the clerk saw an error. Drivers are waiting. The support provider replies that the ticket has been received. The business still needs to know whether the two confirmed orders are safe, what to do about the uncertain third one and who can authorise a temporary process.
When buying software maintenance and support in Kenya, begin with that Monday morning. A useful agreement defines who receives the call, how the team establishes impact, what information staff should preserve and how the business resumes correct work. A quick acknowledgement is valuable, but it is only one moment between the first failure and the return of a reliable dispatch operation.
Use this fictional branch outage to compare support proposals. It includes an application, a database, a network connection, an external messaging provider and people who depend on the service. Your own risks and hours may differ. The method is to rehearse a specific interruption and inspect the responsibilities, decisions and evidence at each stage.
Identify the services the agreement actually covers
Make a service inventory before asking for prices. Name the dispatch application, customer portal, database, hosting environment, branch network, devices, integrations, backups and notification services involved. Identify the owner, provider and access arrangement for each. A support contract covering the application may exclude the router that connects the branch or the external system that supplies release instructions.
For each component, record the business task that depends on it. The dispatch desk needs confirmed orders and the ability to release a driver. The customer service desk needs to see whether a delivery is underway. Finance may need an end of day export but can tolerate a shorter interruption differently from dispatch. An inventory of technical components is useful only when the support team understands the consequences of their failure.
Separate ownership from coordination. Your application provider may be unable to repair a third party network directly. It may still be expected to diagnose enough to identify the likely dependency, supply evidence to the relevant provider and update the business while the issue remains open. Clarify that coordination responsibility. Otherwise several suppliers can each close their own ticket while the branch still cannot operate.
Include environments explicitly. Support for production may not include the test system used to validate a correction, the backup environment used for recovery or the reporting service used at month end. Identify which environments must remain available and who maintains them. A production fix is hard to verify if nobody owns the test environment needed to rehearse it before release.
Define coverage around the working day
List when each branch and service actually operates. Early dispatch, evening customer collections, weekend sales and month end finance work may have different coverage needs. The buyer should distinguish the time someone can submit a ticket from the time a qualified person actively investigates it. A mailbox accepting messages around the clock does not by itself establish continuous technical coverage.
Set example scenarios at the boundaries. A critical dispatch problem starts before head office opens. A minor reporting defect arrives late on Friday. A payment interface fails during a holiday trading period. Ask each supplier how these incidents enter its process and when the agreed response clock runs. Define the relevant time zone, business calendar and scheduled maintenance exclusions in terms staff can interpret.
Name the authorised callers and deputies. A branch supervisor may need to declare a major disruption while the head office manager is unavailable. At the same time, uncontrolled requests from every employee can create duplicate tickets and conflicting instructions. Provide a practical route for frontline reports, an owner who confirms impact and a separate authorisation path for consequential actions such as restoring backups or changing production settings.
Review contact routes during an outage. If the support portal itself uses the unavailable system, the branch needs an agreed alternative. If the usual contact person loses access, the deputy should know how to reach the provider without sharing credentials. Test both routes during onboarding and periodically after staff changes. A contact list is useful only when the listed people still have the authority and means to act.
Classify impact before assigning priority
Priority should reflect the effect on the business and the availability of a safe workaround. One broken report may be a minor inconvenience on an ordinary day and a serious disruption during an agreed closing process. A problem affecting one branch can be urgent if that branch handles the only dispatch route available. Define impact criteria using your own operations rather than assuming every blank screen is equally severe.
Return to the fictional outage. Find out whether the dispatch application fails for all users, one role or one workstation. Check whether other branches can open the same orders. Establish whether orders can be viewed but not updated, whether customer requests continue to enter the queue and whether any actions have an uncertain outcome. These details guide both the technical investigation and the decision about temporary operations.
Separate incident priority from the identity of the caller. A director reporting a cosmetic issue should not automatically displace a branch facing a serious operational interruption. Likewise a frontline clerk should have a route to escalate a high impact problem. Ask the provider how it changes priority when new evidence arrives and who may challenge a classification. Preserve the reason for the change in the incident history.
Use representative test cases when negotiating the agreement. A queue that is slow but functional, an inaccessible branch, a suspected duplicate dispatch and an unavailable monthly report should produce different responses under your defined criteria. Have the supplier classify all four and explain the assumptions. Disagreement at this stage is useful because it exposes a boundary the contract needs to clarify before the first live incident.
Distinguish acknowledgement, workaround, restoration and resolution
An acknowledgement means someone has received the incident. An investigation means a responsible person is examining it. A workaround may let staff continue selected tasks under a controlled process. Restoration returns the service to an agreed usable condition. Resolution addresses the issue sufficiently for the incident to close under the contract. Use these terms consistently when comparing support promises.
Ask what evidence marks the end of each stage. An automated receipt can record acknowledgement, but it may not satisfy an agreement requiring an engineer to engage. A web page returning successfully may show technical availability while dispatch still cannot release a real order. Restoration should be tested against the business task affected. Permanent resolution may require a later change after a temporary configuration restores operations.
Set expectations for communication. During a serious outage the branch needs a named incident owner, current impact, action underway and next update time. It may not yet need a speculative explanation of the cause. Customer service needs information it can accurately share without promising a restoration time the technical team has not established. Prepare a simple update format the provider can use even when little has changed.
Decide how clocks pause or change. The provider may need an authorised decision from the buyer or access to a third party system. A pause should record the specific request, responsible person, time and effect on the agreement. A vague waiting for customer status can hide delays or confusion about ownership. The business should still receive updates appropriate to the incident even while an external dependency remains outstanding.
Give the service desk useful evidence
A frontline report should identify the task, time, location, affected role and what the person observed. Include the relevant order references and whether any action may already have succeeded. Avoid asking staff to copy passwords, full customer lists or unrelated screenshots into a ticket. A short, well designed intake form can give the engineer enough context while reducing unnecessary disclosure.
For the uncertain third order, record the attempted action and observed response. The clerk should avoid pressing release repeatedly until the team establishes whether the first action reached the system. Support can inspect the relevant transaction and integration history using authorised access. The expected outcome is a single valid dispatch or a clear route to create it once, not simply the disappearance of the error message.
Capture timing without assuming every clock agrees. A branch device, server and external provider may use different time settings. Record the time zone or reference used and correlate events using order or request identifiers where possible. A few minutes of clock difference can send an engineer looking at the wrong event. The service desk should know which references help reconstruct an action without including sensitive business content.
Close the loop with the reporter. The branch supervisor should see the incident number, current owner and next update route. If several staff report the same outage, link the tickets to one operational incident while preserving useful observations. Otherwise support may spend its first critical period asking three people the same questions and giving each a different account of the problem.
Design the temporary operating procedure
A workaround should preserve the ability to reconcile later. The branch might record dispatches on approved temporary forms with unique references and limited authority. Decide which actions may continue, which require supervisor approval and which must wait for the system. The right boundary depends on the risk of duplicate release, loss of customer information and the company’s operating policy.
Use an example. The supervisor confirms that the first two orders were already released. The third order has uncertain status. The temporary process might permit the first two deliveries to proceed against existing evidence while holding the third until support checks its state. Record the decision and the person responsible. Treating every order as new in a temporary spreadsheet could send another driver for an already released shipment.
Agree how information is stored during the interruption. A paper form or controlled offline register should record only what staff need to perform the approved work. Keep it accessible to the appropriate people and protect it from loss or unauthorised sharing. Avoid a workaround that relies on sending complete order lists to personal devices because the agreed backup procedure is hard to find.
Name the person who ends temporary processing. When the application returns, staff need a controlled switch back rather than several clerks entering temporary forms independently. Reconcile each temporary reference to an existing or newly recorded transaction, then mark it reconciled. A service can appear restored while duplicate work continues to enter the system from forms that were never collected or assigned to a reviewer.
Test backups against the last correct transaction
A backup is useful when the organisation can restore it and explain what data it contains. Ask the provider to demonstrate restoration in an isolated environment, identify the recovery point and verify that the application can open and interpret the restored records. A file existing in storage is different from a tested recovery capability. Include configuration and dependencies required to make the restored data usable.
Give the restore a business test. The first two orders were released after the backup. The third was uncertain. The recovered database may show all three as unreleased even though two drivers have left. The team needs independent evidence and an approved procedure to reconcile actions after the recovery point. Blindly replaying every pending release could duplicate physical deliveries that already occurred.
Discuss how much data loss and interruption the business can tolerate for each service. Those tolerances guide backup frequency, recovery arrangements and cost. Use concrete examples such as the number of dispatches requiring manual reconstruction during an hour of trading. The buyer and provider should agree achievable objectives based on the actual design and test them. A promised recovery target unsupported by an exercise remains unproven.
Check access to backups. Who can initiate a restore, who approves replacing production data and who can access sensitive records in a recovery environment? Rehearse retrieval when the usual administrator is absent. A backup whose key or instructions are available to only one unreachable employee may not meet the business’s practical recovery needs. Maintain access arrangements under the organisation’s approved security policy.
Maintain the software before incidents accumulate
Preventive maintenance includes reviewing dependencies, applying appropriate updates, checking capacity, inspecting failed jobs and testing recovery. Define which activities the provider performs, how often under the proposed agreement and what evidence the buyer receives. A statement that maintenance is included tells the buyer little about what happens between incidents or which systems remain the buyer’s responsibility.
Schedule changes around business operations. A maintenance window may suit head office yet interrupt an early dispatch branch. Notify affected people, identify the action being taken and define what will be checked afterwards. A release plan should include a usable rollback or recovery approach that accounts for data changes and transactions occurring during deployment. Restoring application files alone may not reverse a changed database or an external message already sent.
Use representative checks after maintenance. Open an order, review a confirmed release, run a safe test of the dispatch path and verify that the external queue is processing. Avoid creating real customer deliveries while testing. A server health check can pass while the application fails because a credential expired or a provider changed an interface. Test the business path as well as the infrastructure.
Review recurring alerts. A task that fails every morning and succeeds on retry may be harmless under an agreed design or a sign of a growing dependency problem. Ask the provider to classify repeated failures and propose proportionate action. Suppressing alerts without understanding them can conceal a later serious incident. Conversely, an alert feed full of routine noise can cause staff to overlook the one event that matters.
Make support access accountable
An engineer investigating a live incident may need temporary access to application logs, configuration or production records. Define the approval route, scope, duration and evidence of access. Prefer a method that identifies the individual performing the work rather than an account shared across several suppliers. The business needs to understand who changed a setting and how the change can be reviewed afterwards.
Separate diagnostic work from authority to change production. An engineer may inspect a failed queue without being authorised to replay financial or dispatch transactions. Replaying the uncertain third order requires a business decision about whether it already succeeded. The incident plan should identify who can make that decision and how the engineer records the authorised action. Technical access alone does not establish commercial authority.
Test an emergency change. Support identifies a configuration correction that should restore the queue. Record the proposed change, affected service, expected effect, approval and rollback plan appropriate to the urgency. After application, verify both technical recovery and the status of the three example orders. Document what changed so the next engineer does not undo a deliberate fix while investigating an apparently unrelated issue.
End the access when the work ends. Check that temporary support privileges expire or are removed and that sensitive diagnostic files are handled according to the agreed arrangements. Review the audit record with a fictional incident during onboarding. If the provider cannot explain who entered the system or what was changed, resolve the gap before real customer records become part of an urgent investigation.
Review the incident after the branch resumes work
Close the incident only after a responsible business person confirms the relevant service can be used and the affected transactions are accounted for. The first two orders should retain their original dispatch evidence. The third should have one clear outcome. Temporary entries should be reconciled. Customer service should know what it can tell each affected customer. A green monitoring screen alone cannot supply those answers.
Write a short incident review. Record the trigger where known, impact, timeline, decisions, workarounds, recovery and unresolved questions. Distinguish observed facts from hypotheses. An incident may expose several contributing conditions, such as an unexpected provider change and a missing alert. A review that blames the last person to touch the system may discourage reporting and miss the conditions that made the failure disruptive.
Assign corrective actions with owners and evidence of completion. One action may improve monitoring, another may clarify the temporary dispatch form and another may involve a supplier configuration change. A recommendation without an owner can survive every monthly review without being implemented. Retest the original scenario after the fix. The branch should see a practical improvement in detection, response or recovery.
Look for patterns across incidents. Frequent short interruptions may consume more operating time than one visible outage. A response target consistently achieved while restoration remains slow may indicate missing diagnostic access or an external dependency. Review the distribution of incident durations and the business functions affected. The aim is to identify which investment will reduce consequential disruption, not simply to present a favourable ticket closure percentage.
Monitor the work that can fail quietly
Some incidents announce themselves with a blank screen. Others allow staff to keep working while a queue quietly stops sending release instructions. The application remains available, customers can place orders and head office sees no obvious failure. The warehouse gradually runs out of actionable work. Ask the provider which checks would detect this condition and who receives an alert early enough to investigate before drivers begin asking where their orders went.
A useful monitor measures a business symptom as well as a technical signal. The server may have enough memory while unacknowledged instructions age beyond the agreed window. Give the support team a way to inspect pending count, oldest pending time and rejection reasons. Choose thresholds using normal operating patterns and the business’s tolerance for delay. A quiet overnight queue should not trigger the same response as a growing queue during a scheduled dispatch wave.
Test the monitor with fictional transactions. Pause the receiving service in an isolated environment, submit a release and observe whether the expected alert reaches the responsible person. Then restore the receiver and verify that the release is processed once. Confirm what happens to the alert when the queue clears. An unresolved alert for an already recovered issue adds noise, while an automatically closed alert without a record can hide a recurring weakness.
Decide who sees operational monitoring. A branch supervisor may need a simple warning that dispatch releases are delayed. An engineer needs technical diagnostics. Customer service needs a statement about what commitments can safely be made. Design these views for their audiences and keep private order content out of broad alerts. A good monitor makes action clearer without distributing the underlying customer record to everyone who receives incident messages.
Handle a third party failure without losing ownership
Suppose the dispatch application works but its messaging provider stops delivering notices. Orders still exist and drivers can receive work through an approved alternative. The incident’s scope is different from a full application outage, yet customers may miss confirmations. Determine who can identify affected notices, what status the provider actually confirms and whether the business should use another authorised communication route. A sent flag inside the application may represent only an attempted handoff.
Ask the support provider to demonstrate the escalation packet it would send to the external supplier. It should contain relevant timestamps, identifiers, observed responses and an explanation of impact, with sensitive content restricted appropriately. The buyer should know who has authority to contact the provider and who maintains the necessary account relationship. A technical team unable to open a supplier case because all account access belongs to a former employee can lose valuable time.
Track the external incident under the original business incident. The external provider may assign its own reference and issue updates on its own timetable. Keep those references connected and preserve the internal owner who communicates with branches. A supplier stating that its service is restored should trigger a local verification of pending notices and current dispatch state. It does not automatically prove all messages delayed during the interruption were delivered.
After restoration, decide which notices remain useful. A delayed customer confirmation for a collection already cancelled can mislead the recipient. Review outstanding messages against current order states before requesting a bulk resend. Reconcile delivered, failed, superseded and still pending notices. This exercise demonstrates why an external outage can require business judgment even when the technical provider has completely resolved its own failure.
Put ordinary service requests on a different path
Staff also need password help, access changes, report adjustments and small configuration requests. These may be important without representing incidents. Define a service request route with the approvals appropriate to the task. A request for access to another branch’s records should not gain priority simply because the caller labels it an outage. Conversely, a genuine role configuration defect affecting all dispatchers should not wait indefinitely in a queue for routine account changes.
Give requesters examples. An employee who forgot a password follows the approved recovery process. A new supervisor needs access authorised by the appropriate business owner. A report that calculates differently from its accepted specification may be a defect. A request for a new profitability measure may be an enhancement. The service desk can classify the work, identify an owner and explain the expected route without forcing the employee to master the contract terminology.
Review routine requests for patterns. Repeated password recovery failures may indicate confusing instructions or an unsuitable setup for shared branch devices. Frequent requests to correct a particular report field may expose ambiguous definitions. One small configuration change may eliminate a stream of tickets. The monthly service review should consider this improvement work alongside major incidents and make clear which changes require additional approval or budget.
Test the boundary with one fictional request during onboarding. Ask a newly appointed branch supervisor to seek authority to approve stock adjustments. Observe the business approval, technical implementation, verification and end date where applicable. Repeat the request using an unauthorised caller and confirm the software provider does not grant access solely because someone knows the employee’s name. A support agreement should make legitimate changes timely while preserving the organisation’s authority over its own records.
During renewal, ask the provider for a sample of routine requests and what changed because of them. A useful account might show that a clearer login procedure reduced avoidable lockouts or that an updated report definition reduced monthly corrections. This helps the buyer distinguish reactive ticket handling from maintenance that makes the operating environment easier to use over time.
Compare support proposals through the rehearsal
Give each provider the Monday morning scenario and ask who acts during the first ten minutes, what evidence they need and how they handle the uncertain order. Ask them to describe the next business update, the temporary process, the restore decision and the final reconciliation. Record which actions are included, excluded or dependent on another provider. The same exercise makes different contract terms easier to compare.
Request a worked price for your real operating profile. Include routine maintenance, coverage hours, incident handling, planned changes, recovery rehearsals and any third party fees. Clarify usage limits, emergency rates, travel arrangements and the cost of adding another branch. A low monthly retainer may cover only initial triage, while a higher one may include engineering time and preventive work. Compare the responsibilities as well as the totals.
Define exit and handover. The organisation should be able to retrieve its records, current configuration, service inventory, incident history, operating instructions and agreed access materials under the contract. Identify who revokes outgoing supplier access and who supports the transition. A healthy support relationship can still end because the organisation changes systems or brings work in house. A rehearsed handover protects continuity during that change.
Keep a printed or otherwise independently accessible copy of the agreed incident route at the branch, according to your information handling policy. It should identify the authorised contacts, alternative channel and first facts to record. Test that a relief supervisor can find the instructions during the Monday rehearsal without asking the usual manager where the file lives. If that simple step fails, the business has discovered a gap it can fix before discussing sophisticated monitoring or buying additional engineering coverage for the next busy trading period.
Take the incident script to the provider you select and schedule the first rehearsal under the agreement. The result should be practical enough for a branch supervisor to use before the next driver leaves. More guides to buying and operating business software in Kenya are available on the ZamaCore blog.