Once the root cause is determined and clearly logged, the time has come to start looking for a possible solution and a work-around. In many cases, the optimal work-around should be clear by now and can be logged in the problem. After registering the work-around, the linked incidents should be commented with the suggested work-around so feedback can be gathered to see if the work-around is valid. During this process it is possible that some incidents end up being unrelated to the problem and they should thus be handled separately.

In many cases a change will be needed for the true resolution of a problem. Perhaps a software program needs to be upgraded or patched; perhaps a service should be delivered differently to prevent the root cause from occurring. There can be many more solutions such as these, but they are clear cut examples of changes to the services provided and should be handled in the change process. At this point a request for change can be logged, see the next chapter for more information on this subject. Until the change has been handled or rejected, the problem process should be stalled.

Sometimes the solution is in further educating support engineers or users on the service. This is usually best handled a little more informally with the support manager. Reporting the findings to the support manager and suggesting the required training to prevent the incident should be sufficient to get the process started. The information on how to prevent the root cause of the incident from occurring can also be logged as the problem is closed in step five.