When I was a young IT professional, a more senior professional introduced me to SOAP notes for helping document and manage my my tickets. More than 25 years later, I still use this method, with great effect.
SOAP notes originally got their start in the health care field, and the notes were used by providers to create a patients chart. There are four parts to a SOAP note: Subjective, Objective, Assessment, and Plan.
These parts are very helpful in creating a record of what the patient is complaining about (Subjective), what the provider has observed about repeatable and traceable facts (such as vital signs or lab results) (Objective), the providers diagnosis (Assessment), and treatments and/or procedures to be performed (Plan). Note that the plan can include diagnostics to be performed as well.
I’m sure you can see how this method can be easily used to great effect in an technology support environment. Let’s walk through a sample of a tech-style SOAP note, and pretend SuzyUser is calling the helpdesk because she is unable to connect to a particular application. A SOAP note documentation set written by the help desk agent (TechDude) might look like this:
Subjective
User (SuzyUser) has called stating that she is unable to login to AppX. She states that she has rebooted her local computer, but is still unable to login.
Objective
I (TechDude) asked the user to attempt login to AppX. Witnessed error code [Invalid Username or Password].
Verified error message by checking log mechanism on AppX.
Assessment
User (SuzyUser) needs to enter a correct username and password combination in order to successfully login to AppX.
Plan
- Ensure that SuzyUser is using the correct username and password combination.
- If SuzyUser has forgotten the correct username and/or password, reset password, following password guidelines.
- After password reset, SuzyUser to attempt login again with correct username and password combination.
- Observe results:
- If successful, close ticket as resolved.
- If not successful, forward ticket to tier 2 support, attaching pertinent AppX log file excerpt.
In this sample, the tech professional documented the problem from the user point of view, noted the observations of the problem in a repeatable manner, diagnosed the problem, and documented both a primary and secondary plan of action. While this example is admittedly a simple one, we’ve now got a completely documented case, which can be used to solve or troubleshoot future issues of the same type. And we all know that documentation is a good thing, right ?
You may or may not use a method similar to this. What method do you use for documenting problems?