Your workflow engine is available, the queue is moving and every scheduled job has started. Yet a new employee still cannot use the application they need. The dashboard is green because it measures the platform; the customer is waiting because the service is unfinished.

For an MSP selling automation as an ongoing service, that gap matters. Customers need to understand what has been delivered, what is waiting and what their provider will do next. A service-level scorecard should connect technical operation to the work the customer asked you to complete.

Start with a precise definition of completion

Take an illustrative access request. A manager approves access to a business application. The automation adds the person to a group, the application processes that membership, and the service desk records the result. The service definition should say which observed condition counts as complete.

“The workflow returned success” is insufficient if success only means a request was submitted. “The intended entitlement is present and the request contains confirmation” is stronger, provided your team can actually verify it. If you cannot test final application access, describe the narrower outcome accurately rather than promising that the employee can work.

Our request-to-outcome guide explains this distinction in a broader service desk workflow. Here, the aim is to turn it into a measurement that customers and operators can both use.

Keep measures, targets and commitments separate

Google’s service-level guidance distinguishes an indicator from its target and from an agreement with consequences. For an automation service, first decide how completion will be measured. Then agree a realistic target. Any customer commitment should use the same clear definition.

Do not copy an uptime percentage into an end-to-end completion promise. The latter can depend on an approver, a customer system and a supplier queue. Write those dependencies down, including who must act when one of them blocks progress.

Build a scorecard around five operational questions

These are suggested design measures, not Autom Mate performance claims or contractual defaults. Choose definitions appropriate to the service. A scheduled leaver action, for example, has a different urgency and acceptance condition from a routine reporting request.

Agree the denominator before publishing percentages

An illustrative monthly cohort contains 40 requests due for completion. Thirty-six finish on time, two finish late and two remain blocked. The on-time completion rate for that cohort is 90%. Counting only the 38 completed requests would hide the two still waiting and produce a more flattering but less useful result.

Keep withdrawn, duplicate, test and out-of-scope requests visible in separate categories. A withdrawal received before work begins may be excluded under an agreed rule. A difficult request should not disappear from the denominator merely because it has been labelled an exception.

Use one service request identifier across retries. Ten attempts to finish one access change are still one customer request. Report attempts as a diagnostic measure if helpful, but do not inflate delivered work by counting every execution as a separate success.

Use two clocks when approval can pause delivery

Customers experience elapsed time from their initial request. Your delivery team may also need a clock for the time it controls. Keep both. For example, record total elapsed time and time after the final required approval, with each waiting period explained.

If a contract allows the delivery clock to pause, define the permitted reason and record when the pause starts and ends. Continue showing the request’s full age. A week-old approval request still deserves attention even if it is not consuming the provider’s delivery allowance.

Do the same for business hours and time zones. A request submitted late on Friday should not be assessed using an undocumented mixture of calendar hours and office hours. Put the applicable clock in the service description and on the record.

Make exceptions actionable during the week

A monthly percentage is too late for a request that needs attention today. Give operators an exception view with the customer, intended outcome, last verified step, current owner, age and next action. Include the impact of leaving the request unresolved.

Review different failure classes separately. An expired credential needs a different response from a missing customer approval. Repeated permission errors suggest a configuration issue; recurring incomplete input may require a better request form. A low manual-intervention rate is not a success if the remaining exceptions are being ignored.

Escalation should change responsibility, rather than merely add another notification. If the original owner is unavailable, the record needs a backup owner who can make the next decision.

Review the scorecard with a real request

• Select one completed, one late and one still-open request.
• Reconstruct the result from the underlying records.
• Check that retry attempts did not create duplicate successes.
• Confirm that exclusions follow a written rule.
• Ask whether the customer recognises the reported outcome.
• Agree one corrective action, an owner and a review date.

This small review often reveals more than adding another chart. It tests whether your definitions survive ordinary operational complexity.

Use the measures to shape the service

Persistent exceptions can point to a service that is too broad, a dependency without an owner or an acceptance condition nobody can verify. Revisit those boundaries in your managed automation service description before making a stronger promise.

Bring one repeatable customer service and its completion evidence to an Autom Mate MSP discussion. Defining what “done” means gives you a practical basis for the workflow, the operating process and the customer conversation.