Concepts¶
SLApulse helps teams turn issue history into an ICU-style operating model for SLA health.
Most teams already manage work in a source system such as Jira. That source system knows which issues exist and which statuses they moved through. SLApulse adds a separate interpretation layer: it decides which status changes matter for SLA measurement, calculates targets, shows current risk, and explains whether the work met the agreed service level.
The problem SLApulse solves¶
SLA follow-up is difficult when the source workflow is richer than the contract.
A source project may have many statuses:
New -> Triaged -> In Progress -> Waiting for Customer -> Ready for Test -> Done
The contract usually cares about fewer moments:
- when the issue entered SLA scope
- when the first response happened
- whether time should pause while waiting
- when resolution happened
- whether the issue is finished
SLApulse maps detailed source history into those SLA meanings, then calculates compliance consistently across current operations and report windows.
SLA intensive care¶
The ICU approach separates the current operating picture from the historical evidence:
| ICU concept | App area | Main question |
|---|---|---|
| Admissions board | Command Center | Which projects are ready, live, collecting, or blocked by setup? |
| Vital signs | Operations / Health Monitor | How healthy is the workspace right now? |
| Triage | Operations / Triage Board | Which issues should be worked first? |
| Observation ward | Operations / ICU Ward | Which critical or deteriorating SLAs must stay visible? |
| Chart and discharge notes | Analysis / Issues and Reports | What happened, why, and what evidence can be shared? |
| Configuration | Setup area | Which source data, rules, users, and billing make the signal reliable? |
The ICU approach does not replace workflow mapping or SLA policy configuration. It sits on top of the same calculated SLA state and makes current risk easier to act on.
Source history versus SLA meaning¶
SLApulse does not assume every source status has SLA meaning.
Some statuses change the SLA state:
| Source movement | Possible SLA meaning |
|---|---|
| New customer request | Start |
| Work begins or first answer sent | Stop Response |
| Waiting for customer | Pause |
| Ready for test or solved | Stop Resolution |
| Closed | Terminal |
Other statuses may be useful history without changing SLA:
| Source movement | SLA effect |
|---|---|
| Internal board column change | No effect |
| Team ownership change | No effect |
| Technical refinement status | No effect |
No-effect statuses can still appear in issue history and on the lifecycle timeline, but they should not change compliance.
Reliable start is required¶
SLApulse only counts an issue when it has observed a reliable Start.
This protects reports from counting old issues that were already closed, paused, or partially complete before SLApulse saw the beginning of the SLA period.
Example:
| Observed first status | Result |
|---|---|
New mapped as Start |
Issue can count in SLA. |
Closed mapped as Terminal |
Issue is excluded unless a later real Start is observed. |
Waiting for Customer mapped as Pause |
Issue is excluded until a Start is observed. |
Excluded issues are not treated as failed. They are left out because SLApulse does not have enough reliable history to measure them fairly.
Two SLA measurement styles¶
SLApulse supports two common ways to measure SLA.
Response and resolution¶
This style measures two phases:
| Phase | Meaning |
|---|---|
| Response | How long it took to first respond or start handling the issue. |
| Resolution | How long it took to resolve the issue. |
Use this when the contract has separate response and resolution targets.
Deadline mode¶
Deadline mode measures one overall target from Start to a deadline.
Use this when the contract says that an issue must be completed before a single target time, rather than splitting response and resolution.
Business hours versus continuous time¶
SLA time can be measured continuously or within business hours.
| Clock mode | Use it when |
|---|---|
| Continuous | The SLA runs 24/7. |
| Business hours | Only configured working time should count. |
Business-hours policies use the project's working calendar. Warning notifications for business-hours SLAs are also scheduled and sent inside open business time.
Operational ICU view versus contract view¶
SLApulse separates current operations from historical compliance.
| Area | Main question |
|---|---|
| Command Center | Which projects need attention or setup work? |
| Operations | What are the current SLA vital signs and which issues should be handled first? |
| Analysis | What is the detailed issue state, timeline, explanation, or completed-measurement result? |
| Setup area | Which projects, rules, calendars, users, and billing settings control the workspace? |
This means an issue can appear in Reports but not in the operational ICU views. For example, a terminal breached issue may still count in historical reporting, but it no longer needs current operational attention.
Mental model¶
Use this model when reviewing SLApulse data:
- Source data says what happened.
- Status mapping says which events matter.
- Project filters say which issues are eligible.
- SLA rules calculate targets and outcomes.
- Command Center shows project readiness and pressure.
- Operations shows current operating risk through Health Monitor, Triage Board, and ICU Ward.
- Analysis explains detail and contract follow-up through Issues and Reports.
- The Setup area changes the configuration behind those results.
When numbers look unexpected, work backward through those layers.