Manage entitlements and SLAs
Entitlements decide what support is owed; SLAs decide how fast
An entitlement defines the support a customer is entitled to: the account or contact it applies to, the entitlement channel (Email, Phone, Web, Facebook, Twitter), start and end dates, and whether it applies automatically or the agent selects it. Entitlements must be activated to take effect, and only one entitlement applies to a case at a time - when several match, the most specific or most recently created wins, so overlapping entitlements are a classic trap.
An SLA defines KPIs (first response by, resolve by) and is scoped to entities when the SLA is created (Case, Work Order, and so on). Enhanced SLAs use SLA items, each with an applicable when condition, and actions for warning, success, and failure. The Applicable From field determines which timestamp drives the timer; leave it blank and the SLA will not apply. Timers can be paused (for example when the case status is On hold or Waiting for details) and resume when the case returns to Active.
Traps: only one SLA applies per case; an SLA only evaluates the entities chosen at creation; and warning and failure actions are workflows, so they run asynchronously and may not fire instantly during testing.
Rule of thumb: model SLAs around the customer promise, one KPI per promise. Worked example: eight business hours for first response with a warning at 80% (6.4 hours) and failure at 100% - the warning action belongs on the SLA item, not on the case form.