This is a vendor-authored opinion piece. Lakeside sells digital employee experience (DEX) software, so the customer results below are the company's own claims and not independent research. The SRE concepts are older than the pitch, though, and they are worth understanding whatever tooling you use.
The core argument: fast is not the same as preventive
Giordimaina's central distinction is between reacting quickly and preventing recurrence. An automated fix may mean the employee barely notices and no engineer gets involved. He grants that this is valuable. But if the same condition returns tomorrow, IT is still spending effort on a known problem.
He says the cost lands on both sides. Employees lose time when technology misbehaves, and IT spends time investigating and remediating familiar conditions.
He also quotes an unnamed partner who wanted to hear about emerging risk while it was still at 0–2% deviation from baseline. By 5–10% beyond baseline, the partner said, the service desk would already be lit up. Giordimaina clarifies that these figures are deviations from that organization's own baseline, not the share of employees affected.
That anecdote is unverified, and the percentages are not a standard. Treat them as an illustration of the goal, which is to see deterioration before it shows up as support demand. Every organization needs its own baseline and escalation thresholds.
What SRE actually brings to endpoints
SRE grew out of Google's approach to running large production systems. Google's own material describes the core vocabulary:
- SLI (service-level indicator): a measurement of performance.
- SLO (service-level objective): a target value or range of values for a service level that is measured by an SLI.
- Error budget: 1 minus the SLO, so a 99.9% SLO leaves a 0.1% error budget.
- Toil: work that is manual, repetitive, automatable, tactical, without enduring value, and that grows with the service. Google's blog on tracking toil quotes this definition from its SRE book.
Google's guidance also contains some cautions that matter when moving the ideas to laptops and desktops.
A 100% target is a trap. Google's SRE Workbook says an SLO of 100% leaves you only time to be reactive, because less than 100% availability is guaranteed to happen. That is close to the situation Giordimaina describes, in which the fastest possible reaction is the whole strategy.
Targets should match what users notice. Google Cloud's documentation advises that SLOs be no higher than necessary. If users cannot tell 99% from 99.9%, use the lower number, because the higher one costs more and changes nothing for them.
Measure the service, not individual devices. The SRE Workbook says an SLO focused on overall service health, rather than individual devices, is more flexible and sustainable as the service grows. This is the hardest part to translate to a workplace estate. A defensible endpoint SLO would target a user-facing outcome. Examples might be "the collaboration client is usable" or "sign-in completes within an acceptable time." It would not target a raw CPU counter. That is my own reading of Google's principle. It is not a method Google prescribes for endpoints, and none of the organizations in the column are shown to use it.
The toil lens: watch what keeps coming back
Google's SRE team aims to keep toil below half of each engineer's time. That is Google's internal aim and not a quota for anyone else. Its guidance on measuring toil is practical:
- Gather lightweight metadata on the work: the type, the difficulty, and who did it. Google stresses that precision is not the goal, and that heavy tracking makes people feel micromanaged.
- Estimate time spent on each type of work at a regular interval. Monthly or quarterly works well.
- Look for patterns in tickets, surveys and incident response, and prioritize by the total human time spent.
Google also warns that not everything should be automated. Rarely performed tasks are hard to automate safely, because the assumptions behind the script may change before it runs again. If a lot of time goes into that kind of work, it suggests looking at the underlying design. Giordimaina makes a similar point: sometimes automation is the right answer, and sometimes the evidence points to an application, configuration or update problem that can be fixed at the source.
Google's advice to treat automation like any other production system applies to desktop remediation scripts too. They need testing, failure handling and review when they misfire.
The customer examples, with caveats
Giordimaina offers three examples. None is independently audited, so treat them as vendor-attributed.
- Fortune 100 insurer: He says about 25% of call-center downtime was invisible to IT. He reports that combining endpoint telemetry with proactive automation cut ticket volume 35% in a year, and that one self-service automation avoided more than 45,000 tickets. A Lakeside healthcare page cites a 35% reduction in tickets for a company with 300K employees. That is similar, but it is a different description and I would not treat it as confirming the column's other figures.
- Large hospital network: He says a few recurring issues generated disproportionate service-desk activity. They included file synchronization, security services, CPU utilization, network services and collaboration tools. He reports roughly 50,000 fewer incidents a year and about $1.6 million in estimated savings. I found no independent corroboration of these numbers, and the customer is unnamed.
- PIMCO: He says its infrastructure team used endpoint evidence and change correlation to cut root-cause investigations from days to minutes. Lakeside's own customer story supports the qualitative picture. It describes PIMCO's VP of Infrastructure wanting to go from complaint to root cause in minutes, and it says the platform can surface changes such as an Office update or security patch visually. It also says automated ServiceNow tickets can carry context for help desk engineers. The page does not give a before-and-after figure for investigation time, so "days to minutes" rests on the column.
The PIMCO example is the most useful for Microsoft-centric shops. Change correlation matters because Office updates and security patches are classic suspects when something breaks. Google's error budget policy notes that changes account for roughly 70% of its outages.
Closing the loop: did the fix actually work?
The column's most practical point is about verification. IT usually has evidence that an action happened: a script completed, an update installed, a device restarted. That is not proof that the user's experience recovered or stayed recovered.
Giordimaina suggests asking three questions after an intervention:
- Did the issue disappear?
- Did the affected experience return to its expected range?
- Was the improvement still there a day or a week later?
He says this matters more as AI takes on diagnosis and remediation without an engineer reviewing every signal. If an AI agent starts a response, IT still needs outcome evidence, or it risks automating more activity without making anything more reliable. This is a sensible argument. It is also, conveniently, one that favors buying more telemetry.
A practical workflow you can borrow
Here is a vendor-neutral process pulled from the column and Google's guidance:
- Pick a critical workflow, such as sign-in, VPN, a collaboration app or file sync. Define a user-relevant measure and a target no stricter than users need.
- Set a baseline and treat deviations as prompts to investigate, not automatic proof of a widespread incident.
- Mine tickets for concentration. Find the few recurring causes that eat the most hours.
- Choose between automating and fixing the cause. Use automation for repeatable, safe remediation. Escalate to engineering when the evidence points to a bad update, an application defect or a configuration problem.
- Re-measure after the fix, against the original indicator and over a meaningful interval.
- Treat your automations as software. Test them, track failures and review them.
Bottom line
The column's message is easy to endorse: judge progress by fewer repeat incidents, not only faster handling. The case-study numbers are marketing-grade evidence and should be read that way. The SRE ideas themselves, including toil tracking, outcome-based targets and verifying fixes, come from Google's published practice. They are worth testing on a single recurring pain point before you rebuild a whole operations model around them.