Requests and problems

A service request records who asked, which service is involved, the request type and the date it was made. A due date gives the request manager a planning point; a completion date records when the work finished. Submitted requests can be reviewed and either Approved or Rejected. Approved work moves through in progress to Completed as the team fulfills it.

The request should describe an action someone can complete. It is distinct from an incident, which records an interruption, and from a change, which holds a planned service modification with risk and a window. These records may relate to the same service, so the service owner can see demand and disruption in context. The requester reference also keeps the person behind the request clear.

• Decision. Review submitted requests before beginning approved work.
• Delivery. Track due and completion dates with the current state.
• Cause. Use a problem record for a recurring service issue and its root cause.

Agree which requests need manager approval and what Approved means for the team. Decide who owns work after approval and how to handle a request that is past its due date. The app’s request record names the requester and service; establish a consistent way for the team to explain fulfillment in the name or operational notes where needed.

A problem record starts when the team needs a durable investigation of a recurring issue. It has a problem statement, root cause, service and owner. Open, Investigating, known error and Resolved should correspond to real understanding, not simply to the age of the record. Decide when an incident coordinator should ask the request manager or service owner to open a problem after repeated incidents.

A team member requests access to a service. The request manager sees the Submitted request with its requester, service and due date. After checking the intended work, the manager marks it Approved. The operating team completes the access work, records the completion date and marks it Completed. If the request cannot be accepted, Rejected is a visible decision instead of a request left indefinitely in Submitted.

A separate pattern emerges when incidents on the same service recur. The request manager opens a problem, names an owner and writes the problem statement. As investigation develops, the owner records the root cause and may mark the problem known error before a durable fix. Resolving the problem does not erase the earlier incidents; they still show their own impact and timing.

• Requests awaiting decision — Review submitted service work by requester and due date.
• Current problems — Follow open investigations by service and owner.
• Active services — Confirm the service referenced by each record.

Use request fulfillment to rehearse a decision and completion. Read incident response when a recurring interruption becomes a problem investigation.