Business Cases
Part of Automation business cases
Including support and maintenance in automation costs
Estimate automation costs for monitoring, exceptions, support, planned changes and retirement without counting work twice.
Estimate support and maintenance as continuing costs alongside the one-off build and transition. Forecast staff time, supplier charges and planned changes across the appraisal period, using consistent case volumes and periods against benefits.
Separate launch costs from running costs
Define the process, expected case volume, connected systems, support hours and appraisal period. Record who supplied each estimate and whether it includes GST, internal labour and supplier charges; apply the organisation's finance conventions consistently across options.
| Cost area | Ask for an estimate of |
|---|---|
| Delivery and transition | Design, configuration, integration, testing, training and migration |
| Platform and infrastructure | Licences or subscriptions, hosting, environments and usage-related charges |
| Business operation | Human review, exception handling, monitoring and reconciliation |
| Technical support | Incident response, diagnosis, fixes and access or credential changes |
| Planned change | Updates when a business rule, application, interface or security requirement changes |
| End of use | Replacement, data handover and retirement within the appraisal period |
Use only the lines relevant to the solution. Give each an owner, quantity, rate or quote, and confidence level. Check exactly what a supplier fee covers before adding internal or external support separately; a licence or service agreement does not, by itself, establish that business-item checking or every incident is included.
For a warehouse management system (WMS), annual maintenance and support is typically about 15–20% of the initial licence fee. Use this as a WMS-specific reference, not as a general rate for automation.
Launch Costs vs Running Costs in Automation Projects
- Delivery and Transition
- One-off costs for design, configuration, integration, testing, training and migration
- Platform and Infrastructure
- Licences, subscriptions, hosting, environments and usage-related charges
- Business Operation
- Human review, exception handling, monitoring and reconciliation (ongoing)
- Technical Support
- Incident response, diagnosis, fixes and access or credential changes (ongoing)
- Planned Change
- Updates due to business rule, application, interface or security changes (ongoing)
- End of Use
- Replacement, data handover and retirement within the appraisal period
Estimate the work behind support
List events that may require attention, such as failed runs, rejected cases, uncertain outcomes, changed source fields and releases to connected systems. For each, estimate expected events per period, effort per event and the roles involved.
Forecast support hours = expected events × hours per event, summed across event types, plus routine work that occurs regardless of incidents. Multiply the hours for each role by the applicable labour rate to estimate the internal support cost.
Use observations from an existing route or bounded pilot where available. Otherwise, show a range and name the assumption.
Distinguish routine operation from a defect: reviewing an ambiguous case is part of the future process even when the software works correctly, while investigating a failed integration is support work. Both use capacity, though they may sit with different teams and budgets.
If the benefit forecast already subtracts human review from hours released, do not charge those same hours again as an incremental cost in the financial comparison. Ask who provides support outside ordinary hours if the business result has a deadline.
Record the actual coverage stated in a proposed agreement and who remains responsible for confirming completion of each business item. Identify what evidence the support team can access and who decides whether an uncertain item can be retried.
Put changes and timing into the estimate
Connected systems and business rules may change during the automation's life. Estimate the effort to assess each change, update the workflow, test it and release it; a contingency should reflect identified uncertainty rather than hide known recurring work.
Set an explicit assumption for the number of rule, application, interface or security changes expected in each year. Estimate the effort and roles for each; if the frequency is uncertain, show a range and name the assumption rather than implying a standard cadence.
Set out costs by month or year across the appraisal period, including launch and ramp-up when training or support effort may differ from steady operation. State the date and basis of supplier quotes, and show a volume range if usage could change a licence tier or support load.
Compare the schedule with the benefit forecast using the same case volume and periods. Check whether effort saved in one team creates monitoring or repair work in another, and record that work once in the comparison.
Where a per-unit view is useful, divide infrastructure, service and support costs for a period by the number of units in that same period. The process owner, technical owner and finance owner can then confirm the tasks, estimates and cost treatment.
