Services Inventory and Attributes

Service Indicator Set

[Multi-Value]

Description — The observable or measurable signals defined for this Service — the Service Indicators that constitute the measurement foundation for Service Expectations. Aligns with the third element of the IF4IT Single Service Definition Pattern. Captured as descriptive enumeration or as reference to the formal Service Indicator catalog.

Benefit(s) — Makes Service measurement explicit. Enables Service Owners and Service Managers to govern what is observed about the Service. Provides the basis for Service Objectives and Service Reports.

Source — Manual.

Examples — "Time to fulfill standard request; first-contact resolution rate; backlog age" or "Request volume; approval time; provisioning success rate; failed authentication events"

Notes — Refer to the IF4IT Service Management Best Practices document for the Service Indicator discipline. Service Indicators are defined by the Service Owner.

Service Objectives

[Multi-Value]

Description — The targets, thresholds, or desired ranges for Service Indicators. Aligns with the third element of the IF4IT Single Service Definition Pattern. Captured as descriptive enumeration or as reference to the formal Service Objectives document.

Benefit(s) — Translates Service measurement into performance intent. Enables Service Providers and Service Actors to understand what they are trying to achieve. Supports Service Owner determination of whether performance is acceptable.

Source — Manual.

Examples — "Standard access requests receive initial review within one business day; backlog age below 10 business days remains below 5%" or "API error rate below 0.5% over a rolling 30-day period"

Notes — Service Objectives are paired with Service Indicators — each Objective is a target against an Indicator. Refer to the IF4IT Service Management Best Practices document for the Service Objective discipline.

Description — A reference to the formal Service Agreement document — which may be a formal Service Level Agreement, an internal operating commitment, a support agreement, a customer-facing service commitment, or a documented understanding between the Service Owner and the Service Requester Community. Aligns with the third element of the IF4IT Single Service Definition Pattern.

Benefit(s) — Provides the authoritative pointer from the inventory record to the Service Agreement. Enables compliance, contract, and audit teams to trace Service-level commitments to their authoritative documents.

Source — Manual.

Examples — Confluence page URL; SharePoint document URL; Reference to Contract record (SVC-AGREEMENT-EMPLOYEE-ONBOARDING-V2)

Notes — Not every Service has a formal SLA. Many Services have informal but documented agreements (e.g., a published support commitment). The agreement form may be formal or informal; what matters for governance is that an agreement exists and is referenced.

Description — When the Service is operationally available — the business hours, support hours, holiday coverage, and time-zone coverage that define when consumers can engage the Service. Aligns with the IF4IT Service Management Best Practices "Define service coverage and support model expectations explicitly" guidance.

Benefit(s) — Eliminates ambiguity about Service availability. Supports requester expectation-setting. Enables Service Desk routing and escalation aligned to actual Service availability windows.

Source — Manual.

Examples — "24x7 globally"; "Business hours 8:00 AM - 6:00 PM US Eastern on US business days"; "Business hours per regional support center"

Notes — Should describe the actual availability window in a form requesters can understand. Holiday coverage, after-hours availability, and time-zone considerations should be captured here when they materially differ from the headline availability statement.

Description — The support coverage model for the Service — how support is structured, what coverage is provided, and what is excluded. Aligns with the IF4IT Service Management Best Practices coverage and support model expectations guidance.

Benefit(s) — Eliminates ambiguity about what support is available. Supports requester expectation-setting and Service Desk routing.

Source — Manual.

Examples — 24x7 with on-call escalation for severity-1; Business hours with best-effort after-hours; Best-Effort only; No support (self-service only)

Notes — Should distinguish standard support coverage from emergency / severity-1 coverage where they differ. After-hours support, holiday support, and on-call availability should be captured where they materially differ from the headline coverage statement.

Service Engagement Channels

[Multi-Value]

Description — The approved channels through which Service Requesters interact with the Service. Aligns with the IF4IT Service Management Best Practices "Register and expose services through fit-for-purpose Service Engagement Channels" guidance.

Benefit(s) — Makes the requester-engagement surface explicit. Enables governance of channel consistency. Supports Service Engagement Owner accountability for cross-channel content.

Source — Manual.

Examples — "Service Catalog (ServiceNow); Intranet (HR portal); ServiceDesk phone (x4357)" or "API Gateway (api.enterprise.com/customer-lookup)"

Notes — Refer to the IF4IT Service Catalog Best Practices document for catalog-as-engagement-channel guidance and the IF4IT Service Management Best Practices document for the broader Service Engagement Channel discipline.

Description — The specific, governed definition of what completion means for a Service Outcome or Service Response. Aligns with the IF4IT Service Management Best Practices "Define what completion means for every Service Outcome and Service Response" guidance.

Benefit(s) — Eliminates ambiguity about when a Service Request is genuinely fulfilled. Supports Service Records closure discipline. Reduces disputes between Service Requesters and Service Providers about completion.

Source — Manual.

Examples — "Access fully provisioned in all target applications; requester notified; evidence captured in Service Record" or "API response returned within SLO; response payload validated against schema"

Notes — Should be expressed in operationally verifiable terms — what can be observed or measured to confirm completion.

Description — The authoritative system of record for Service Records associated with this Service — the platform where individual Service Request transactions are captured, tracked, and reported. Aligns with the IF4IT Service Management Best Practices "Manage Service Records as governed records of request, action, status, evidence, and outcome" guidance.

Benefit(s) — Provides the pointer from the Service definition to the operational records. Enables auditors, compliance teams, and Service Owners to find the operational evidence of Service performance.

Source — Manual.

Examples — ServiceNow; Jira Service Management; BMC Remedy; API Gateway logs (Splunk); Workflow engine (UiPath Orchestrator)

Notes — A Service may have Records in multiple systems (e.g., front-office ticketing for human-engagement plus API gateway logs for technology-engagement). Record the primary system; use Notes to enumerate additional Records sources.

Description — How Service Requests routed through the Service Desk are handled for this Service — which queue receives them, what initial triage applies, when they are escalated to Service Providers / Service Actors or to SME teams.

Benefit(s) — Makes the operational routing path explicit. Enables Service Desk staffing decisions informed by Service-level routing. Supports the Service Desk’s role per the IF4IT Single Service Definition Pattern as the operational front door for Service Management.

Source — Manual.

Examples — "Service Desk Tier 1 receives requests; routine fulfilled directly; complex escalated to Access Management SMEs" or "Direct to API platform team (no Service Desk involvement)"

Notes — Empty for Services that do not flow through the Service Desk (e.g., direct-API Services).

Description — The structure that defines who performs Service Action work for the Service. Aligns with the IF4IT Service Management Best Practices "Define fulfillment responsibilities for every Service Provider and Service Actor" guidance.

Benefit(s) — Makes Service fulfillment structure legible. Supports decisions about whether to consolidate, distribute, automate, or outsource Service fulfillment.

Source — Manual.

Examples — Single-Team, Multi-Team, Cross-Org, Vendor-Fulfilled, Automated

Notes — Valid values: Single-Team (one team fulfills all Service Requests), Multi-Team (multiple internal teams share fulfillment), Cross-Org (fulfillment crosses organizational boundaries), Vendor (a Vendor performs primary fulfillment), Automated (a system or workflow performs primary fulfillment).

Description — A reference to the documented escalation procedure for this Service — how Service Requests requiring escalation are handled, who is involved, and what escalation timing applies.

Benefit(s) — Provides the operational escalation reference distinct from the Escalation Contacts attribute (which captures who) — the Escalation Process captures how.

Source — Manual.

Examples — Confluence procedure URL; Service Desk runbook URL; SharePoint document URL

Notes — A reference, not the procedure itself. The procedure lives in the enterprise’s knowledge management or runbook tooling.