Problem solve Get help with specific problems with your technologies, process and projects.

VoIP in the Enterprise: Converging users

Implementing VoIP? Consider end-user acceptance and provide employees with the tools to take advantage of the technology.

Converging voice and data technologies can be challenging. Dealing with technical issues like incompatible hardware, implementing an end-to-end quality-of-service (QoS) scheme, and coercing some function out of the higher-layer protocols is usually the foremost thing on the mind of architects and designers during an implementation project. This is because these arcane areas are still unproven compared to the golden oldies like FTP (File Transfer Protocol) or SMTP (Simple Mail Transfer Protocol), and a fear of the unknown naturally causes some anxiety on the part of the technical team.

So it is not surprising that another important aspect of a project does not receive much attention. That aspect is converging your users. After all, no matter how elegant and reliable your system is, if the users aren't using the system, it can't be successful. In this newsletter we will discuss what you should consider about interaction with your users during the design phase of your project.

Understanding the impact
Before you can communicate effectively with your users, you need to understand how their routine will change with the new system. For instance, if you're just implementing VoIP, you might change the dial plan so that users dial 9 to access an external trunk and 8 to access a VoIP trunk. How will you explain the benefit of using the VoIP trunk? And how will you explain what numbers they can reach through it? Are you changing from three-digit dialing to five-digit dialing? Will you be able to extend the enterprise phone system to home or remote users?

If you are implementing an IP telephony system, with IP phones and a softswitch, how will users' experience change? You might be surprised by some of the questions they will ask. For instance, it might not be obvious to some if they're supposed to shut off their phones at night, or if their LAN user ID and password are required. Consider creating a frequently asked questions document for basic instructions as well as telephone features. Many basic features on telephones like speed dial and voice mail are now more powerful, but more complicated. For instance, dialing could be tied into directory access or Microsoft Outlook address books, and voice mail may be now be retrievable through an e-mail client via unified messaging.

The morning after
Another key to user communication is explaining how the new system is supported. For instance, if users can't get to their voice mail, should they call the old data team, the old voice team, or some completely new team?

You should also give some thought to how they can reach support during an outage. Back in the old days, when the network "went down," the users could just pick up the phone and call the help desk. And when the phones were misbehaving, they could send an e-mail or use an instant-messaging application. But if both go out together, what happens? Odds are users won't want to use their personal cellular phones, and building fire codes almost certainly prohibit sending smoke signals. Worse, they are probably accustomed to dialing only the help desk extension, and if the users are forced to dial your support pager with a long-distance number from an external phone, they may not have the area code or exchange memorized. Find a way to make this information available when they need it.

Finally, give users a short and simple checklist of things to verify before calling for support. For instance:

  • If the phone service isn't working, do they get a dial-tone?
  • Can they dial some local numbers, but not external or long-distance?
  • Can they ping a set of IP addresses locally and across a WAN?
  • Is the call set up, but too garbled to understand?
  • If they hear an echo, make sure they note who heard it and who they were calling.

Answering these questions and others will go a long way towards reducing your support headaches. Setting reasonable expectations keeps users from reporting new features as bugs or problems, and understanding and predicting user issues will help you get ahead of the curve by reducing your problem-determination and resolution time. That, in turn, gives you time to work on a solid design for your next project.

About the author:
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.

More on this topic:

Read all of Tom Lancaster's VoIP Tips.

Visit our extensive collection of Best Web Links on Voice/data Convergence.

Dig Deeper on Unified Communications Resources

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.