PayRun Cloud: Green Dashboard, Unhappy Customers
PayRun Cloud provides payroll processing to 240 small employers. Its service level agreement promises 99.9% monthly availability, and its status dashboard has shown green for 11 consecutive months. Yet customer satisfaction has fallen 22 points. Analysis shows that 38% of pay runs are delayed or rejected because employee data from customers' HR systems arrives in the wrong format or with missing bank details. Two customers account for 31% of revenue. Customers blame PayRun; PayRun blames customers' HR suppliers. The sales team wants to add a self-service analytics feature, arguing that 'availability is excellent, so the problem is perception.' The operations team wants to add more monitoring. The customer success team has no authority to require data-quality checks before a pay run is submitted. A major customer has given 60 days' notice.
1. Explain why 99.9% availability does not demonstrate that PayRun Cloud is delivering value. Use utility, warranty, outcomes, costs and risks in your answer.
Read the worked answer
Availability is one element of warranty - fit for use - but value depends on the outcome the customer wants: employees paid accurately and on time. PayRun's dashboard measures the availability of its own components, not the end-to-end pay run. The 38% delayed or rejected runs show that utility is insufficient: the service may function, but it does not handle the data formats and missing bank details it receives. Those failures transfer costs and risks to customers - correction effort, delayed wages, compliance risk - and the SLA does not cover them. A service is a means of enabling value co-creation, not a guarantee of a single metric. The customer's HR system and its supplier are part of the value network; if their outputs are poor, the outcome suffers even when PayRun is 'up'. Sales calls this perception, but the 22-point satisfaction fall and the 60-day notice are evidence of unmet outcomes. Monitoring more of the same would improve detection, not value.
2. What should PayRun Cloud change in its service relationships to improve value co-creation, and with which parties?
Read the worked answer
PayRun should treat the customer's HR system and HR supplier as part of the service relationship, not as external blame. It needs joint service-level expectations covering data quality, submission cut-off times and error handling, plus a clear division of responsibilities. The service offering could include a pre-submission validation service or an API that rejects bad records early; that changes the utility and reduces customer cost and risk. Customer success needs authority to require data-quality checks before a pay run is submitted, and sales should stop selling analytics as a distraction until the core outcome is stable. Engagement should be segmented: the two customers representing 31% of revenue need a named relationship manager and a recovery plan within the 60-day notice. The provider should also collaborate with HR suppliers on format standards. Value is co-created, so PayRun cannot deliver payroll outcomes alone; it must manage the relationship and the shared responsibilities explicitly.
3. The sales team wants to add a self-service analytics feature. How should PayRun decide whether to fund it?
Read the worked answer
Assess it against focus on value and the current service relationship, not against competitor features. The question is whether analytics improves the customer outcome - accurate, on-time pay - or only adds information after the fact. If it helps customers see and correct data-quality problems before submission, it could support value co-creation; if it simply reports availability, it repeats the existing dashboard. PayRun should also consider the 60-day notice and the 38% failure rate: a feature that does not address the main cause of dissatisfaction is unlikely to retain the at-risk customer. A small discovery iteration with five customers could test whether analytics changes behaviour and reduces rejected runs. If not, defer it. This is start where you are and keep it simple and practical: use existing data and fix the core flow before adding scope. The decision should be recorded with the expected outcome and measure, not just a feature request.