Service context

A support article is easier to trust when the team knows which service it describes. Services records hold a name, criticality, status and owner. Assets add a tag, serial number, location and service reference. Together they help the service desk identify the environment affected by an incident before an editor turns a fix into reusable guidance.

For example, a recovery instruction for an active internal service may differ from one for a retired service. The Service Desk Agent checks the service and affected asset on the incident. The Knowledge Editor uses the case to write the right conditions into the article body. The article itself is owned separately, which lets another editor maintain the wording while the service owner maintains the service record.

• Service ownership. Give each service a named person responsible for its operating context and status.
• Asset context. Use the asset’s service reference and location when a case concerns a particular device or installation.
• Support links. Incidents, problems, requests and changes refer to services, so the team can follow related work before changing guidance.

The service status keeps active, maintenance and retired service records distinct. Asset status gives a separate view of stock, assigned, maintenance and retired items. A status change should reflect the real operating state; it should not be used solely to move a row out of a list.

Choose a consistent service naming convention and decide who changes criticality or status. The service owner should know when an article needs updating after a service changes. Decide how asset tags are issued and how a location is written. These choices make incident records easier to compare when the team is looking for repeated questions.

Plan how the service team will tell editors about changes to procedures. A change record has a service, risk, scheduled start and end, rollback plan and status. The service owner can use that context to schedule an article review when the change affects a published instruction. Keep the article’s owner responsible for the wording and the service owner responsible for the service facts.

Use a service with an assigned asset and an open incident. Confirm the incident points to the intended service and asset, then read the incident update explaining the issue. Ask the article owner to draft a recovery note that names the conditions in ordinary language. If a scheduled change will alter those conditions, review the change dates before publishing the article. After the change, the service owner checks the current status and tells the editor whether the guidance remains accurate.

• Active services — Current service names, criticality and owners for support context.
• Assets in service — Assigned or maintenance assets with their service and location.
• Change schedule — Planned windows that may affect published instructions.

Follow a case in service question to guidance. The change and guidance process shows how an upcoming service change can prompt an article check. See integrations for the receipt record when external events are connected.