Questions? Feedback? powered by Olark live chat software
Print Page  |  Contact Us  |  Your Cart  |  Sign In
The Boomer Bulletin - 2010
Blog Home All Blogs
Search all posts for:   


View all (46) posts »

Technology Opportunity Management

Posted By Eric Benson, Monday, September 13, 2010
Eric Benson

Opportunity Management and Information Technology in the same sentence—sounds odd, doesn’t it?   I’d like to show you how changing the focus of support requests to mimic an opportunity cycle can increase levels of trust, decrease the level of reactivity and increase productivity of the people in your firm.

Let’s begin with short definitions. Opportunity Management is usually a marketing and sales process to develop potential business.  Most SFA (sales force automation) systems handle opportunity management with some degree of success.  Internal Technology relates to the use (in most people’s minds) of a computer and the “stuff” that happens behind the scenes to make that computer work. 

Opportunity Management, if done properly, uses a variety of media and conversation to bring someone along a decision path.  Every email, phone call, website or face to face conversation is educational as well as confirmational. A good marketing campaign brings in leads that educate a potential client about a service.  A good sales person (or team) takes that education and helps the client define his or her need at hand.  In the accounting industry, a service can only be sold if a client understands the need for it.  Opportunity Management, if done right, is proactive, anticipates the client’s questions and closes the sale.

Now, let’s look at the way most internal technology support works.   It usually centers on an issue (the typical term) with broken technology.  An issue gets entered into a system –email, website, or conversation (direct or indirect).  A technology professional examines the issue, determines the cause and delivers a solution.  Determining the cause might involve looking at the computer, and if necessary, discussing the issue with whoever submitted the ticket.  In most help desk situations, the solution must be documented and preferably added to a central support register in case the problem comes up again.

So, where’s the connection? 

Let’s do a comparison:

Typical Sales Opportunity Cycle:

Initial Contact* → Define Opportunity* → Confirm Need* → Develop Proposal → Negotiate Terms* → Close Opportunity → Continue Client Service* → Discover New Opportunity*

Typical IT Support Cycle:

Initial Contact → Define Issue → Confirm Problem → Solve Problem → Resolve Issue→ Document Issue

I’ve adjusted the steps so they match in number, but I think the arrangement is reasonable.  They don’t look that different in flow.  Crucial differences resolve around the starred steps in the opportunity cycle:

  1. These steps are proactive
  2. They are done with direct client contact (people centric)
  3. There is a focus on continuing the relationship in anticipation of future business

IT support cycles are usually:

  1. Reactive
  2. Done with isolation from the user (technology centric)
  3. Focused on resolving the issue

What happens if we change the terminology of an IT support cycle to reflect the sales opportunity cycle, using the same starred approach?\

IT Opportunity Cycle:

Initial Contact → Define Opportunity* → Confirm Problem* → Develop Solution* → Solve Problem* → Resolve Issue→ Document Issue → Continue Client Service* → Discover New Opportunity*

So, what happens when the cycle looks like this?

  1. The cycle is a conversation between the person using the computer or technology and the support staff
  2. The solution is developed (if needed) with the requestor
  3. The solution is solved with the requestor
  4. Continued follow-ups allow for a decreased threshold to submit new issues
  5. New opportunities can be proactive measures, like training, feature requests or process improvements

I don’t think there is a way to get around the reactive nature of some IT support requests, but I do think the steps above increase discussion and make reactive requests less common.  In addition, the level of trust goes up if the requestor is involved in the discussion, even if it’s brief.  Let me give an example that’s described both ways.\

IT Support Request (helpdesk model)

Jon emails Eric explaining that Outlook is not downloading email correctly. Eric documents the issue in helpdesk solution and checks Exchange logs to see if there is a problem with Jon’s inbox.  Eric contacts Jon via electronic method (IM, email, or helpdesk post) to schedule time to look at Jon’s computer.  Jon says, “Right now.”  Eric logs in remotely, looks at issue and backs out of remote computer.  Eric documents what he did and references Jon to a wiki where the solution for his problem is.  Case closed.  (Total Time: 10-15 minutes)

IT Support Request (opportunity model)

Jon emails Eric explaining that Outlook is not downloading email correctly. Eric opens a ticket and contacts Jon to see how urgent the matter is and learns that Jon is unable to use email.  Eric offers a timeline of resolution (e.g., “I’ll call back in five minutes or less”) and checks Exchange logs to see if there is a problem with Jon’s inbox.  He documents the conversation and results in the ticket and calls Jon back, then logs in remotely to Jon’s computer.  With Jon on the phone, Eric asks Jon what’s happening, and Jon shows him.  Eric realizes that the issue is related to an improper configuration related to a core application, explains this to Jon and asks if he can take control of Jon’s computer.  Jon watches Eric fix the problem.  

After finishing Eric asks Jon if he has any other questions.  Jon says no, then opens an email and changes his mind – there is something else.  Eric and Jon have a short conversation about email signatures, and Eric documents that new request.  The conversation ends, Eric documents his solution along with a new ticket and hands it off to the compliance team for follow up.  Eric also follows up 1/2 day later with Jon to see if things are working well and also lets Jon know the email signature request has been handed off to the right team. (Total Time: 15-20 minutes)

The goal in the first example is to finish the work, and the measurable result is the closing of the ticket.  The goal in the second example is client satisfaction, and the measurable result is the creation of a second ticket that went to the compliance team.

For some of you this may seem like a stretch, and maybe an ideal scenario.  I agree—not all IT support requests can follow this model.  But a surprising number can, and the results can change the way technology support is viewed within a firm.  It requires discipline, a consistent drive to be proactive, and an education on both sides (IT and the firm) that technology can be a business driver for innovation in the firm.

Tags:  Eric Benson  Information Technology  team building 

Share |
Permalink | Comments (0)
Community Search
Sign In

Forgot your password?

Recent Blog Posts