Sticking To The Script

As a Broadcast Engineer, I am filling out resolution descriptions on a daily basis.  I have made it a common habit to conform my resolutions to a few simple guidelines which provide a wide variety of benefits. I figured this would be a helpful topic to put out there…….

The basic rules to my descriptions are to keep them simple, keep them on point, and when needed to provide the essential elements of the resolution so that if someone is presented with the problem again in the future and are looking for a solution then my explanation will benefit them.

I have compiled a simple checklist which works for every resolution description I have come across in my career.

1.) Be an observer first whenever possible.

2.) Include co-worker’s efforts whenever being helped. 

3.) Provide direct information about the issue once confirmed. 

4.) Leave out measures that were not directly a part of the solution.

5.) Give the direct results of measures taken.

6.) Acknowledge the resolution was confirmed in some manner.

7.) Express when the resolution created normal operations to return.

8.) Always provide Initials and date in the resolution information.

So, to get started I always start my resolution with a clarification of the issue. I do this as an observer myself whenever possible. 

For instance, if a ticket says the user experienced an issue migrating material through the transcoder. I will start my resolution by finding out exactly what material did not process and exactly which transcoder the issue was with as an observer to put me at the level of the user.      

I always include co-workers in this statement if they were present, as team unity is always a solid foundation for a successful resolution process. I make it a habit to include anyone who helped throughout the entire resolution description. Being selfless any time you can is a good rule to stick by.  It helps you to stay in everyone’s good graces which is never a bad thing.

So, by taking these two methods into account my first sentence of this resolution example would go something like this…….

(We observed material item xyz stuck in the transcoding process by transcoder xyz.)  

This statement was very simple and straight to the point, and gives credit to all involved.

Next provide a direct explanation of what actions were taken to remedy the issue.

Sometimes an issue will have other variables and as such you may not start with the correct measure that leads to the solution. This is however extra information. I typically exclude such information because it has no relevance toward the solution and can potentially raise more questions than answers.  

In the first example determining the issue I have added those additional measures that need not be there…….

(We then checked the material on the media grid for potential errors, we found none. Next, we checked the transcoder application and found it had errors and was unresponsive.)

Now in this next example of the issue determination I have simplified the issue…….

(We then checked the transcoder application and found it was unresponsive.)

Notice I still included the term “WE”.  

Next provide the solution. Again, leave out additional measures that did not result in the solution.

(We shut down the transcoder application and relaunched the application.)

Now give the direct results.

(The material then migrated successfully.)

Verify your results with the user.

(We verified resolution with xyz.)

State the status of the completed resolution.

(Normal operations resumed.)

AG/xyz/abc 09/21/2017.

So, in the end the entire resolution description will look like this:

We observed material item xyz stuck in the transcoding process by transcoder xyz. We then checked the transcoder application and found it was unresponsive. We shut down the transcoder application and relaunched the application. The material then migrated successfully.   We verified resolution with xyz. Normal operations resumed.

ACG/XYZ/ABC 09/21/2017.

By sticking to this format, we have given an accurate assessment of the overall service provided. We diagnosed the issue. We have acknowledged all participating parties in every step. We left out useless information. We gave the resolution. We verified it. We stamped it.

There you go. Hopefully this advice can assist in staying on point in your resolution descriptions in the future and get you used to maintaining a consistency level in a regimented format moving forward.

If this advice helped you please let me know. I enjoy all the feedback. Thanks again and happy engineering…….

Adam C. Guest


Leave a Reply

Your email address will not be published. Required fields are marked *