Tailoring Service Management in a Remote-First Product Company
Helio Systems is a 300-person remote-first software company with nine product squads using Scrum and Kanban. Its two-person internal service desk handles 1,200 tickets a month, 70% of which are access, laptop and SaaS requests. The company still runs a heavyweight incident process: every Sev1 triggers a 12-person bridge, a 40-field ticket and a post-incident report due within 48 hours. Sev1 target is four hours; last quarter 11% of incidents were repeat incidents and 34% of post-incident reports were late. Engineers bypass the desk and ask squad peers for help. The COO wants service management to support product velocity and not add bureaucracy, while the security team wants evidence of access control. The company is preparing for ISO 27001 certification and a 40% headcount growth in 12 months.
1. Which practices should Helio tailor, adopt or drop, and how should it decide?
Read the worked answer
Decide by value, risk and volume, not by fashion. Adopt lightweight request management for the 70% of tickets that are access, laptop and SaaS requests, with automation and self-service. Adopt knowledge management and a simple incident process. Tailor problem management to focus on repeat incidents and access failures. Drop the 40-field ticket and the automatic 12-person bridge for every Sev1; replace them with a severity matrix, a small incident command role and an optional bridge. Keep security evidence for access control, but capture it through automated workflow logs rather than a heavy form.
The reasoning is that VeriSM management practices are a portfolio to compose for context, not a package to install. A remote-first product company needs fast flow and clear risk controls; a 40-field ticket adds data entry without reducing risk. Use a practice review with squad leads, the service desk and security. For each practice, ask what outcome it protects, what evidence it creates and what it costs. Pilot changes for 30 days and measure cycle time, repeat incidents and audit evidence. This gives the COO velocity and the security team defensible records.
2. How should incident and problem management be redesigned to reduce repeat incidents without slowing squads?
Read the worked answer
Separate incident response from problem investigation. For incidents, use a severity matrix based on customer impact and safety, not on title. A Sev1 gets a named incident commander, a shared channel and automated status updates; the 12-person bridge is optional. Fix-forward authority should be explicit, with a time limit and rollback. For problem management, trigger investigation when an incident repeats, when an error budget is exhausted or when the same access failure appears three times in a month. Assign the problem to the squad that owns the service, not to a central meeting.
Use blameless post-incident reviews focused on contributing conditions and actions. Limit reports to one page and track actions in the squad backlog. The 11% repeat rate suggests that actions are not being completed; measure action closure and recurrence, not report timeliness. The 34% late reports are a signal that the report is too heavy. Automate evidence capture from chat and monitoring. Review incident trends monthly with squad leads. This reduces repeat incidents by fixing causes in the same team that does the work, while preserving fast response.
3. How can the service desk demonstrate value to the COO and security team beyond ticket counts?
Read the worked answer
Report outcomes the COO cares about: time to restore access, time to provision a laptop, new-hire readiness on day one, employee satisfaction with support and the percentage of requests resolved by self-service. For security, report access control evidence: percentage of access granted through approved workflow, orphan accounts removed, time to revoke access after leaver, and audit exceptions. Add a flow metric such as touch time per request and the number of handoffs.
Reasoning: ticket counts show workload, not value. A desk that closes 1,200 tickets but takes three days to grant access is a bottleneck. Link metrics to product velocity: lost engineering hours from access delays, repeat incidents and onboarding delay. Present a quarterly service review with three or four measures, a trend and one improvement bet. Use the ISO 27001 preparation to show that lightweight automation creates better evidence than manual forms. The service desk should be positioned as the owner of request and access outcomes, not as a ticket factory. That framing earns support for automation investment.