ベストプラクティス & トレンド / 記事

3 tips to set, measure and report on SLAs

Just for fun, I typed, “I hate SLAs” into Google. Don’t try it at home. Google auto-populated my search bar with “I hate Slash” instead, and I spent five minutes reading articles like “Slash: Axl Rose Hates My Guts."

In a way, it's actually the perfect lead-in to today’s topic. Axl and Slash have been at it for years, but so have IT managers and SLAs. It's not that we hate SLAs, or refuse to be seen on the stage with them in matching leather pants. It's just that SLAs are notoriously difficult to measure, report on, and meet. They're even harder to configure and change in many of today's service desks, too. We know we need a way to track our performance against our top business objectives, but the current way just isn't cutting it.

What can Jira Service Desk do about it? We’ll get to that, but the tooling is less important than the concepts. So first, let’s cover some basics.

それはさておき、SLA って何?

As a service provider, a Service Level Agreement (SLA) is a plain-language agreement between you and your customer (whether internal or external) that defines the services you will deliver, the responsiveness they can expect, and how you will measure performance.

What's the difference between an SLA vs a KPI?

An SLA is an agreement between you and your customer that defines how the relationship will work in the future. Key Performance Indicators (KPIs) are the metrics chosen to gauge how well a team performed against agreed standards.

An IT service desk, for example, typically agrees to provide technical support for a wide variety of services and devices within the business, and offers guarantees around things like uptime, first-call resolution, and time-to-recovery after service outages. KPIs are the specific metrics that are chosen to track whether the IT service desk fulfils these guarantees.

Sounds simple, right? In theory, yes. In practice, though, IT teams often run into one or more major challenges:

  • Tracking SLAs is difficult, and changing them is even harder. To see how they’re performing against SLA, many IT managers have to extract a ton of raw data, write custom queries, and build elaborate Excel formulas and reports. Plus, the SLAs often have to be custom or hard-coded into many service desks, meaning it can take days of development effort to change them.
  • SLAs don’t always align with business priorities. SLAs seldom seem to change or evolve at the same pace the business does. In fact, more often than not, they’re inherited. Someone set an SLA a decade ago, and today it’s honored “just because.” Frustrating, isn’t it?
  • There is zero flexibility in reporting. Even though there are a ton of unique circumstances influencing SLA attainment (like how long it takes for a customer to reply to you, etc.) most SLA reports don’t easily account for them. You either met your SLA or you didn’t. There’s no way to highlight something in a report that shows why, or helps you continually improve.

If you’ve experienced one or more of the challenges above, I feel your pain. So let’s start with a few simple tips for setting smarter SLAs. Then, we’ll cover three ways you can use Jira Service Desk to build them easier and make them more flexible and effective.

First, revisit your SLAs and create the best ones possible

Above, we talked about how SLAs can feel a bit arbitrary – like we’re not always measuring something that directly supports your company’s bigger business objectives. To make sure you’re not only measuring the right things, but also meeting the expectations that other parts of the business have of you, we recommend revisiting your SLAs at least once a year. Follow this simple process:

  1. ベースラインを設定する。現在の SLA を確認し、その SLA に対するパフォーマンスがどうなっているかをチェックすることから始めましょう。あなたが提供していることは何か、およびその内容が会社とカスタマーのビジネス目標にどれくらい合っているかを確認します。
  2. Ask how you’re doing. Talk directly with your customers and solicit constructive feedback. What are you doing well, and what could you do better? Are you offering the right services?
  3. Build a draft of new SLAs based on the steps above. Get rid of the services you no longer need, and add the ones that will make customers even happier and bring more value to both the business and IT.
  4. Get support from management. To be successful, SLAs need the blessing of your IT leaders, and the leaders of your customer organizations, too. Start by getting your own management to buy in, and then ask them to help you negotiate with your customer’s management team.

If you've followed the above process, your SLAs should now be in pretty good shape.

Service Level Agreement best practices

Once you’ve brokered the best SLAs for your current business and customer needs, you’re ready to implement them. So here we go: three tips for taking SLAs to a whole new level of ease and effectiveness. I'll use Jira Service Desk to demonstrate how it's done (special thanks to Atlassian Experts Valiantys for the great video tutorials).

Tip #1: Create an SLA that stops tracking time to resolution while you’re waiting for a customer to reply

IT departments need to be able to measure their own response times effectively in order to provide the best possible service. It isn't as easy as it sounds, either. Measuring SLAs gets complicated quickly as slow-responding customers and third party escalations cause response times to look far worse than they may actually be. Unfortunately, many measurement and reporting systems can't accommodate exceptions like these, so the service desk team ends up looking far worse than they are actually performing.

Setting up smarter SLA reporting

In Jira Service Desk, we added a clever little feature that makes it easy to get far more accurate reports. In a nutshell, you can configure any SLA to pause automatically based on any trigger you define, from a simple ticket status change to a change in assignment or escalation.

Here's how it works:

約 1 分で SLA を作成しました。チケットのステータスが更新されるたび、時計の動きが止まります。カスタマーからの情報待ちの時間が反映されるため、常に正確なパフォーマンスがレポートされます。

卓越した SLA を作成するためのその他のヒント

  • シンプルでわかりやすい命名規則を使う。エージェントは、SLA の名前を見て、何を評価するものかをすぐに理解できる必要があります。
  • 大きくて複雑な SLA を一連の小さなものに分割して、全部ではなく個々のワークフローを評価、レポートできるようにする。こうすることで、SLA を更新して最新の状態に保つことも容易になります。

Tip #2: Set different performance goals based on ticket priority levels

On an average day, your service desk team won’t consider a printer failure it’s highest priority ticket. But the CEO’s printer? That’s another story.

実際には、影響を受けるのはビジネスのどの部分か、誰がチケットをオープンしたのか、さらに複雑な条件が絡み合ったもの (たとえば四半期末に販売予約システムに障害が発生した場合) など、実に多様な方法でチケットに優先順位を付けています。

You should expect the same flexibility from your service desk software, and we’ve got you covered. In Jira Service Desk, you can create SLA performance goals based on just about any combination of parameters you define. Configuring these SLAs is easy, can be done in-house, and requires absolutely zero customization or software development – i.e., you can change them as needed without spending a fortune.

以下の例では、カスタマーはチケットが P1 か P5 かに応じて、異なる SLA パフォーマンス目標を設定しようとしています。どのように実行したかご覧ください。

Now, each time a new ticket is opened, Jira Service Desk checks the ticket against all of the goals you have defined in your SLAs, and assigns the appropriate SLA time target based on the first matching JQL statement.

Plus, you can create new goals for just about any parameter, and change or edit them easily to keep your team’s priorities completely aligned with changing business needs.

優れた目標を設定するためのその他のヒント

  • Get creative. You can use any custom field or criteria within your Jira Service Desk project. Basically, if it’s stored in Jira Service Desk, you can create and measure SLAs with it.
  • とはいえ、目標を作り過ぎないよう自重する。エージェントが目標を明確に理解できる必要があります。特殊な状況が多すぎるのもよくありません。目標を作れば作るほど、目標ごとの変動要素が増えるため、理解して遵守することが難しくなります。

Tip #3: Keep some SLAs running 24/7, and restrict others to normal business hours

サービスデスクチームが月曜から金曜まで、通常の就業時間に働いているとしたら、どのサービスでも本当の 24 時間年中無休のサポートを提供することはできません。オンコールサービスデスクチームやカスタマーが料金を支払う優先サポートがあるとはいえ、サービスによっては、昼夜を問わない平日対応や即時対応を保証することが少なくありません。

問題は、土日に「時計を止める」サービスデスクの構成が困難になる場合があるということです。会社の休日など、独自のルールを作成したい場合はさらに複雑です。

To handle situations exactly like this, Jira Service Desk allows you to build and select different calendars for each goal you assign to an SLA. This way, you can assign a 24 x 7 service window to all P1 tickets, and a “business hours only” service window to all other tickets.

Here’s how you do it:

これで、チケットが P1 でない限り SLA は勤務時間内のみ有効となります。定義したとおり、次の就業日の勤務が始まると再開されます。P1 チケットの場合、解決するまで時計は止まりません。

カレンダーを使用するためのその他のヒント

  • 別の場所にいるチームをサポートするためのカレンダーを作成する
  • 祝祭日や会社の休日を忘れずに追加し、休日は変わる場合があるため毎年チェックする

How else can you do more with SLAs in Jira Service Desk?

To wrap up, I’ll leave you with a few ways to use SLAs even more effectively in Jira Service Desk.

First, check out the Atlassian Marketplace. It’s the second biggest enterprise app store in the world, and you’ll find tons of powerful add-ons for Jira Service Desk that provide easy answers to some of your most complex needs. We recommend starting with the notification assistant add-on to do things like sending automatic notifications to the incident manager if an SLA is breached. It runs on JQL, too, so you can fire off notifications for just about any query result you like. You can also use Twilio’s API with Jira Service Desk to create very powerful, easy-to-implement workflows, like sending an SMS to your service desk team every time a P1 ticket is created.

最後に:SLA について多少は安心できましたか? 後は Slash と Axl を何とかできればいいのですが。

著者について

Nikki Nguyen

Product Marketing Manager, Jira Service Desk

Although my life in IT is behind me, it's not too far away. I'm now a recovering systems administrator evangelizing the way teams work by using Jira Service Desk. I've found a love of combining customer service with technology. Tweet me @NikkiHNguyen

さらに詳しく
Jira Service Desk logo

より多くの問題をさらに素早く解決

無料トライアル