Helping the Help Desk

Of the many delightful and painfully true Dilbert cartoons, one of them features “the boss” asking Dogbert why he wants the job of being their network administrator. Dogbert replies, “I don’t like people. This is a good opportunity to annoy idiots such as yourself for my own entertainment”. The boss naturally replies, “Wow. You’re perfect. Can you start tomorrow?” This cartoon captures both sides of the Help Desk quandary: users feel the technologists are out to get them, and the technologists think the users are ill-trained.Helping the Help Desk

Of the many delightful and painfully true Dilbert cartoons, one of them features “the boss” asking Dogbert why he wants the job of being their network administrator. Dogbert replies, “I don’t like people. This is a good opportunity to annoy idiots such as yourself for my own entertainment”. The boss naturally replies, “Wow. You’re perfect. Can you start tomorrow?” This cartoon captures both sides of the Help Desk quandary: users feel the technologists are out to get them, and the technologists think the users are ill-trained.

We all have our stories: the endless wait times, only to find out there is another number to call; or the long wait only to find out your problem is “not their fault, call the other vendor”; or the person who is happy to help but hasn’t been trained on your protocol or software. I’ve personally spent days trying to get “user-installable” software successfully installed. And yet more and more technology is purposefully designed to put more of the support burden on the user, much like the healthcare system discharges patients from the hospital as rapidly as possible and puts the burden of care on the family.

This is one of the not-so-hidden weak spots in the underbelly of information technology, and as we use more and more software applications in clinical research, this object of derision is no longer at arm’s length. Indeed, software is increasingly the work environment for all participants in clinical research, from sponsor employees to sites to patients. As electronic data capture (EDC) and electronic trials management (ETM), or even just web-based connectivity schemes become crucial to trial conduct, the jokes about the Help Desk are going to fall flat.

Common Causes

What are the common causes of Help Desk frustration? As with many implementation issues, it often begins with a lack of awareness on the customer side, and insufficient resources or maturity on the vendor side. Poor planning results in unclear definitions of who is supposed to support what. What are the responsibilities of the software vendor (or network services vendor) and what are the issues the sponsor must (and should) support.

Help Desk plans must anticipate the levels of support required and who and when calls are escalated. A common failing is that so-called “third-level” or even “second-level” support is handled by the vendor’s engineers. Too often, these engineers have neither the time nor the training to be handling user problems when they are also programming the software’s next release!

There are other causes of Help Desk failures. Implementation planning must be sure to include the unexpected — indeed, the unexpected is the essence of what a Help Desk is designed to solve. Too often, help desk staff are trained simply in the same material the user is trained in, instead of the vendor and user getting together and applying experience and anticipation to imagine the problems users are likely to encounter. And then there is staff turnover to consider — even if the initial training is adequate, if there are no provisions for handling changes in the Help Desk staffing, then problems will assuredly occur.

Some empathy is in order. A day on the Help Desk can be excruciatingly boring, punctuated with very occasional calls of high crisis, either real or unnecessary, with a very upset caller. Help Desk staff, while having to meet the necessary technical requirements, must also be able to work effectively interpersonally in these unusual conditions.

Issues to Resolve

There are also some service issues to resolve. Do you need a Help Desk which is multilingual? If so, what languages are really needed? Do you need knowledgeable support available across multiple timezones? Do you need a Help Desk available to answer questions “24×7” (24 hours a day, 7 days a week). It’s easy to ask for this, but it may be expensive and counterproductive, so you should challenge your assumptions heartily before proceeding.

Very important to EDC support is the difference between support for the software and support for the protocol. Certainly most sponsors want software calls to go to the Help Desk and clinical questions to go the CRA or Project Manager. What will you do when a clinical question comes to the software Help Desk (and it will), or vice versa? These contingencies and their resolution need to be articulated clearly.

Possible Solutions

There are several things that can be done to help the Help Desk. First, a clear service level agreement (SLA) must be negotiated and written between the parties, which should spell out all expectations, responsibilities and escalation procedures. Second, your vendor and perhaps your own Help Desk should use one of the many available off-the-shelf software packages for call tracking, including an issues database that all parties can learn from. Third, if you decide neither you nor the vendor can provide adequate support, there are third-party businesses established to provide Help Desk support on an outsourced basis.

Importantly, the CRA also has a potential role to play, especially when the site is using EDC or trials management software. As the sponsor’s most visible and personal representative, the CRA can nip site frustrations in the bud through reassurance and advocacy. This means that CRAs need to take a special interest in and responsibility for the functionality and performance of software which involves them. It implies a more proactive role than being just another user, and while it may seem like an extra burden to the already burdened CRA, it is also both self-protective and job enhancing.

In another Dilbert cartoon, Dogbert is now manning the Help Desk phones and tells a caller, “I’m the new ‘No Help Whatsoever Desk’. My job is to make sure you never call again.” Our job is to help make sure that first, calls to the Help Desk are indeed infrequent, and second, when they do come in, the user is truly helped, quickly and accurately.

We all have our stories: the endless wait times, only to find out there is another number to call; or the long wait only to find out your problem is “not their fault, call the other vendor”; or the person who is happy to help but hasn’t been trained on your protocol or software. I’ve personally spent days trying to get “user-installable” software successfully installed. And yet more and more technology is purposefully designed to put more of the support burden on the user, much like the healthcare system discharges patients from the hospital as rapidly as possible and puts the burden of care on the family.

This is one of the not-so-hidden weak spots in the underbelly of information technology, and as we use more and more software applications in clinical research, this object of derision is no longer at arm’s length. Indeed, software is increasingly the work environment for all participants in clinical research, from sponsor employees to sites to patients. As electronic data capture (EDC) and electronic trials management (ETM), or even just web-based connectivity schemes become crucial to trial conduct, the jokes about the Help Desk are going to fall flat.

Common Causes

What are the common causes of Help Desk frustration? As with many implementation issues, it often begins with a lack of awareness on the customer side, and insufficient resources or maturity on the vendor side. Poor planning results in unclear definitions of who is supposed to support what. What are the responsibilities of the software vendor (or network services vendor) and what are the issues the sponsor must (and should) support.

Help Desk plans must anticipate the levels of support required and who and when calls are escalated. A common failing is that so-called “third-level” or even “second-level” support is handled by the vendor’s engineers. Too often, these engineers have neither the time nor the training to be handling user problems when they are also programming the software’s next release!

There are other causes of Help Desk failures. Implementation planning must be sure to include the unexpected — indeed, the unexpected is the essence of what a Help Desk is designed to solve. Too often, help desk staff are trained simply in the same material the user is trained in, instead of the vendor and user getting together and applying experience and anticipation to imagine the problems users are likely to encounter. And then there is staff turnover to consider — even if the initial training is adequate, if there are no provisions for handling changes in the Help Desk staffing, then problems will assuredly occur.

Some empathy is in order. A day on the Help Desk can be excruciatingly boring, punctuated with very occasional calls of high crisis, either real or unnecessary, with a very upset caller. Help Desk staff, while having to meet the necessary technical requirements, must also be able to work effectively interpersonally in these unusual conditions.

Issues to Resolve

There are also some service issues to resolve. Do you need a Help Desk which is multilingual? If so, what languages are really needed? Do you need knowledgeable support available across multiple timezones? Do you need a Help Desk available to answer questions “24×7” (24 hours a day, 7 days a week). It’s easy to ask for this, but it may be expensive and counterproductive, so you should challenge your assumptions heartily before proceeding.

Very important to EDC support is the difference between support for the software and support for the protocol. Certainly most sponsors want software calls to go to the Help Desk and clinical questions to go the CRA or Project Manager. What will you do when a clinical question comes to the software Help Desk (and it will), or vice versa? These contingencies and their resolution need to be articulated clearly.

Possible Solutions

There are several things that can be done to help the Help Desk. First, a clear service level agreement (SLA) must be negotiated and written between the parties, which should spell out all expectations, responsibilities and escalation procedures. Second, your vendor and perhaps your own Help Desk should use one of the many available off-the-shelf software packages for call tracking, including an issues database that all parties can learn from. Third, if you decide neither you nor the vendor can provide adequate support, there are third-party businesses established to provide Help Desk support on an outsourced basis.

Importantly, the CRA also has a potential role to play, especially when the site is using EDC or trials management software. As the sponsor’s most visible and personal representative, the CRA can nip site frustrations in the bud through reassurance and advocacy. This means that CRAs need to take a special interest in and responsibility for the functionality and performance of software which involves them. It implies a more proactive role than being just another user, and while it may seem like an extra burden to the already burdened CRA, it is also both self-protective and job enhancing.

In another Dilbert cartoon, Dogbert is now manning the Help Desk phones and tells a caller, “I’m the new ‘No Help Whatsoever Desk’. My job is to make sure you never call again.” Our job is to help make sure that first, calls to the Help Desk are indeed infrequent, and second, when they do come in, the user is truly helped, quickly and accurately.