Problems

A problem record gives a recurring or significant service issue its own name and statement. It links to the affected service and a person responsible for the investigation. The opening date shows when work began. The status moves from Open to Investigating and can identify a known error before the team records Resolved. The root cause field holds the conclusion when the investigator has enough evidence.

An incident still records a specific interruption with its own priority and timing. A problem asks a different question: what underlying issue needs analysis for the service? The Service Manager can review both kinds of work by service without using an incident status as a substitute for a root cause decision. A Knowledge Editor can use the resolved finding to inform an article about the same service, with the article reviewed through its own process.

• Frame. Name the problem, describe the observed issue and link the service and owner.
• Investigate. Record the working state and maintain the root cause as evidence develops.
• Resolve. Make the outcome visible in the problem status and carry useful findings into service knowledge.

Decide when several incidents justify a separate problem record and who assigns its owner. Agree what the problem statement should contain so it describes observed behavior rather than a presumed cause. Define when the team uses known error and what evidence is required before Resolved. Establish how a Service Manager will compare open problems with active incidents for the same service. The problem owner should be clear even when several people contribute to the investigation.

Suppose several incident records concern the same service over successive days. The Service Manager opens a problem, names the issue, adds the service and assigns an owner. The owner writes the observed pattern in the problem statement, marks it Investigating and records the root cause after checking the evidence. If the team has identified a repeatable fault before a permanent fix, the status can be known error. When the underlying issue has been addressed, the owner records Resolved. The Knowledge Editor can then draft an article for that service, but publication still requires its review and publication step.

The owner can use the service reference to compare the problem with active incidents without merging their histories. An incident may be resolved before the underlying cause is understood. The problem remains open for that investigation. Once the cause is confirmed, the owner can explain the finding to the Knowledge Editor in terms colleagues can use on a later case.

• Open problems — Active investigations and known errors with their service and owner.
• Active services — The service context and owner for deciding who should review the finding.

See problem investigation and service ownership.