Problem and request work

Problems help a service team investigate a recurring fault. Each record has a number, statement, root cause, opening date, service, owner and status. Service requests record a different kind of work: a requester asks for a service action, and the team tracks its type, due date, completion date, service and status. Both can reveal questions that deserve a clear article.

A problem owner may identify the root cause behind repeated incidents. The Knowledge Editor can use that finding to revise an article that previously covered only a temporary workaround. A request team may discover that requesters repeatedly misunderstand a step. The editor can explain the step in the article body while the request remains a separate record with its own decision and completion dates.

• Investigation. Problem status separates open work, active investigation, known errors and resolved findings.
• Request decision. Submitted requests stay visible for a person to examine before a status change to Approved or Rejected.
• Knowledge handoff. The article owner uses the outcome of problem or request work to improve general instructions.

Problems and requests both refer to a service. Use that reference to see which service’s instructions may need attention. A problem’s root cause is a finding about the fault; the article body is the maintained explanation the team wants readers to use.

Decide when a repeated incident becomes a problem investigation and who owns the root-cause record. Agree how the request type is written so teams can compare similar requests. The Service Manager should define who makes a request decision and how the requester hears the outcome through the team’s normal channel.

Give the Knowledge Editor a way to learn when a root cause changes the advice in a published article. The editor can compare the old answer with the new finding and send the revised text for review. If a request procedure changes, check the due dates and current request status before changing the instructions readers follow.

Start with several incidents on one service. The Service Manager opens a problem and assigns an owner. As the investigation moves from Open to Investigating and known error, the owner writes the current finding. The Knowledge Editor checks whether a published article suggests an outdated workaround. If it does, revise the body and have the Article Reviewer check the new answer. Then take a submitted service request and confirm that the request’s type, due date and requester still make sense under the updated guidance. Preserve the problem and request histories.

• Problem investigations — Open findings, service, owner and root-cause text.
• Requests awaiting decision — Submitted requests with requester and due date.
• Published article library — Current guidance to compare with the findings.

Use service question to guidance to see how the case reaches an editor. Feedback and revision helps when readers later report that the revised answer is still unclear.