Problem Overview: We at BTech do a great job of rallying the team to solve any systemwide issues impacting our customers. Problems are used for situation where we do not have a permanent solution to a reported production issue. The use cases for the Problem module could be when we are dependent on a vendor or partner that needs to do some coding to fix an issue in our environment. We should also leverage problems, at time of new product or service deployment to capture any go live issues or missed requirements. Hopefully we can apply a workaround to the incident being reported and track the permanent fix through a problem record. Problem Definition from ITIL V4: What is a problem? According to ITIL 4, a problem is a cause, or potential cause, of one or more incidents. Problems can be raised in response to a single significant incident or multiple similar incidents. They can even be raised without the existence of a corresponding incident. Please see the URL below for Fresh Service overview of the Problem Module. We are using the out of the box set up for the Problem Modules. https://support.freshservice.com/en/support/solutions/articles/234451-working-with-problems When should you open a Problem?: If a feature will not be enabled as part of a new project inititiave, it is advised to open up a problem prior to go live, and share that problem number with the Service Desk who can associate any incidents reported to that problem. This will help prioritize the problems based on impact and reported issues. If an incident is reported that we do not know the root cause, a problem should be opened until a fix is identified. If an incident is reported that we do know the root cause, you might consider a problem to manage the details of implementing the fix. A change might also be sufficient for some of the use cases. If you need to work with a vendor on the root cause and solution, a problem will need to be opened. Problem Status Definitions: Open - Initial status used for triage of any problem. Should be looking for root cause of specific problem. Change Requested - Status used when requesting work to be completed by vendor, or from an internal BTech business partner. Stays in this status until the work is acknowledged and slotted for work to be started. With Vendor - Used once the vendor has acknowledged the request and are working on the solution. Stays in this status until slotted for deployment in the Swinerton systems. Monitor - Once the solution has been deployed, use this status to monitor impact of change on production, and move to close once you have confidence the solution resolves the original problem reported. Closed - After sufficient monitoring has occurred, please move the problem to closed, update key fields, and close any related changes, incidents and service request.