Insights & updates from our experts

One of the primary things you need to figure out whenever your team is formulating your incident management process is describing in words what a Sev0(your highest incident priority) looks like. “Website doesn’t work” is certainly no enough. “Website is up but a key resource (ie CSS file) is missing, rendering the website unusable” is still not enough. “A single page on the website is 404’ing” is not a major but could be a minor incident.
Sev-1’s are incidents where level of impact is such that the company will go out of business if you don’t fix the issue soon. The first thing you need to do is define the company commitments first. Every view of the website will complete in X ms. It will return a status code in the 2XX range (or <500 or whatever). Describe whatever commitments you want to make to the customers of that website, and then measure those. Then, when any one of those is violated, count the number of times any violation happens. That count of violations then drives how severe an incident is. (ie, define SLOs, measure SLIs, examine the ratio of requests that violate one or more SLOs out of all requests received).
Depending on the site it might be necessary to slice things up more, measuring all of those things by route or service or whatever, but I think fundamentally always defining explicitly what the commitments are first–with actual numbers–is the right approach. There can always be other key metrics too beyond the basics. For example, if the site sells things, counting the value of failed transactions might be important too, so you can understand how much a problem is costing you in actual dollars. It really depends on thinking about the service being provided first and working back through what commitments you want to make to customers from there. But again, with actual numbers that are measuring the customer experience. Depending on that, you can take the most important metrics and aggregate the number of violations and then formulate your severities/priorities for different ranges.

A Note From the Road: What SPARK Taught Me About Time
During the second SPARK event in Antwerp, I stood at the back of a training room and watched a customer build a custom integration with our new iPaaS, wiring Xurrent to another system in her stack that had never talked to it before. No services rep doing it for her. No statement of work, no project plan with a kickoff and a go-live date. Just a person with live beta access in her hands, connecting two systems by hand, and finishing it before her coffee went cold. A year ago that would have been a multi-week project with a budget attached. She looked up, a little surprised it had actually worked, and said something I have not stopped thinking about since. She said it just gave her her week back.

How Long Should ITSM Implementation Really Take in 2026?
Most vendors will tell you ITSM implementation takes six months to a year — but modern, configuration-first platforms have rewritten the math entirely. See what real implementations look like in 2026, and why a long rollout is now a choice, not a given.






.webp)





.webp)
.webp)














