The Unified Messaging Checklist: What You Need to Know — Transcription
Hello, and welcome to another in the AVST webinars. Today our subject is going to be Unified Messaging Checklists: What You Need to Know to Evaluate Unified Messaging Systems. My name is Neil Butler. I'm the Director of Sales Engineering at AVST, and I'll be your host for this session.
If you look at AVST's history, I think we can probably justify our right to make this kind of presentation. We've been in the market for 30 years. We're one of the leaders in enterprise unified communications solutions which certainly includes unified messaging. We're recognized as a best of breed player in those market segments we're in. We have over 10,000 customers worldwide. We've been in business since 1982. We have a lot of experience in unified messaging.
If you look at our history, 30 years ago we started with a voicemail and call processing platform. But, by 20 years ago we were already delivering enterprise unified messaging. We have a lot of experience between then and now that's helped us have the kind of information we're going to try and give you today.
Besides unified messaging, our product does custom solutions with business process. It has speech recognition components. It has a fantastic call routing personal assistant application. We basically connect everything in the industry from the oldest TDM type systems to the newest SIP type systems. So, our experience qualifies us to talk about this type of solution.
Of course, the industry recognizes that. If you look at the type of awards we've won in the area of unified communications and unified messaging, you'll see we are definitely rated the best of breed, the leading player in unified messaging.
It isn't just unified messaging. Customers partner with AVST for a number of reasons. You can sort of look through these categories and see. Certainly, replacing Legacy voicemails with new voicemails and probably that includes unified messaging, plus a wide range of high end unified communications solutions. We're extremely good at sitting inside the enterprise and connecting to the other enterprise systems. That's one of our Legacy pieces based on how long a product has been on the market.
If you look at a general list of our customers you'll see in most categories for larger customers, whether it's enterprise, higher ed, health care, or government, we have a long history of deploying solutions. And every one of these solutions is slightly different. The architecture is different. The environment the customer had was different. But, the flexibility of our product let us deliver what these customers needed. That's what keeps us in the forefront of the market.
We were lucky that we were formed many years ago by some people in a data department. Those people understood the right way to create business applications. So, rather than a monolithic, single process app like you'll find with a lot of telephony products on the market, we have a true three tiered data type application architecture. That gives us the interoperability to connect our platform while having the application tiers be separated out all running on the same platform, all fully integrated, but it lets us control how we sit in the enterprise.
We have a lot of things we could talk about in our product, but today we're going to focus on unified messaging. Unified messaging is robust and has been out on the market long enough where most people will sort of have a good understanding of what it does. The concept is it'd be much more productive for your users to be able to get all their message types from a single interface. Of course, it's a single interface that varies depending on their circumstances - at their desk typically from their email client, and when they're out and about typically from perhaps the telephone or perhaps the data channel on one of their mobile devices.
Because we've been doing this for so long - we have over 20 years at delivering these types of solutions - our product is the most flexible out there. Regardless of the device type, regardless of your needs for security, regardless of your back end infrastructure, phone system, or any of the things like that, you're going to find our solution is going to fit your needs.
So, what we're going to do today is briefly describe our solution. We're also along the way going to talk about the things you need to be careful of as you look at sourcing a unified messaging solution.
Interoperability, of course, is the first part. On one hand, this is easy. You can simply ask whatever vendor you're talking about do you connect to the type of system I have. If the answer is yes then that's a good thing. You can get started.
But, keep in mind over time that might change. We have the most flexible connections in the industry because we've learned that, particularly in larger customers between acquisitions and mergers, the need to support a more varied back end pops up quite a bit. So, in our system we can support a user that has Exchange, or Office 365, or Notes, or Gmail, or Mirapoint, or GroupWise, any IMAP 4 compatible server as well but more importantly we can have multiple connections so if you have Exchange and are considering migrating to Office 365 or Gmail, the ability to sport both at the same time is critical. Make sure if that's something that might be in your future that that's one of the questions you ask the vendors.
The next big set of questions come in, where will you store the messages? Now this affects features and functionality a bit but it has more of an effect, I think, on policies and how you're comfortable in terms of messages. Messages are a type of communication that probably fall under the concept of eCommunications and there's a lot of laws and regulations out there that regulate what you do with those, how long you have to store them? Are they subject to discoverability, etc.?
While we can't really give you a legal level of advice what we can tell you is in our system we'll give you the flexibility to control the message store that should meet your needs whatever they are. The first architectural discover is called Server Based Unified Messaging and that's because the actual unification happens on the server.
What happens is all of the messages end up being stored in the email store and managed from any of the devices that are accessing the email store so if you kind of look at this from a process point of view, if you have the CX server or perhaps a [right VAC] server and those messages are coming in and being taken by those servers they are then moved and actually stored in the email server in the user's inbox.
The upside of that is whatever devices they're using to access their email, whatever technology you've deployed is now also available with voicemail. So if you're using Outlook Web Access or iNotes to look at your email messages from a web browser, you'll now get your voice messages. If you're pushing your email messages out using Exchange ActiveSync or a BlackBerry Enterprise server perhaps, you'll now be pushing your voice messages out. If you're using cash mode on your laptops for disconnected access, you'll now also have your voice messages.
This is definitely the most feature rich version basically from a mobile employee's standpoint, from somebody that's not just going to sit in front of that email client on their desk day in and day out. From the client's side we've enhanced the client's for Exchange, Office 365 and Notes and we have a basic client that we'll kind of look at for all of the rest of the types of integrations.
This same architecture today is going through a face lift where people are talking about and actually moving their infrastructure into the cloud. If you're looking at or already have Office 365 or Gmail then we can do the exact same thing with that architecture. We can store the messages out in the server, even though it's on the cloud we have all the secure protocols needed to do that. We have the custom forms. We have all the same functionality when it's out in the cloud as we do when it's local and on site.
If you're not doing this but thinking about doing this, two questions to ask whatever vendor you're talking with, will they support whatever your future direction is and will they support a reasonable migration, meaning can I have some of my users on one internal system while I'm moving others to the external system? Because you may not want to, have an interest in doing a flash cut to move everybody at once. Just a couple of questions that you want to make sure come up in the discussions.
This architecture functions in the exact same way. The CallXpress CX server or the right VAC server takes the message when using various protocols, pushes it out into the cloud onto, to be stored on the email server. Now you get all the same benefits you get, including if you access them with the web client, like this happens to be Office 365, you'll still have access to your voice messages as well as your email and fax.
The second architecture's a little different. It's called Client-based Unified Messaging because we actually use multiple message stores. We'll leave the fax invoice messages on the CX server, we'll have the email messages on the email server and what we'll actually do is combine them in the client.
Now if you look at what happens here is you go to your client, which already has a connection back to whatever your email system is, you build another connection back to the CX server, the CX server ends up looking like an IMAP message store.
Now you have two inboxes, one that has voice and fax, one that has email. All the same kind of forms, all the same kind of functionality, and for someone that works at their desk day in and out, this is great. You have the ability to play the messages over the phone, play them from your speakers, drag the messages into folders. All of that functionality is there.
What you don't have are the remote access pieces by default so since your client is looking at our message store, when you go out to Outlook Web Access there's no way to have that look at dual message store.
We work around that. We have our own client for mobile devices so they can still get their voicemail messages when they're mobile, but that's the biggest difference between these two architectures.
We had these two architectures for about ten years and another type suddenly presented itself in terms of a request from customers. What they said is even with this client-based messaging, while I'm not storing my messages on Exchange, the users can get a hold of those messages and get them off the system. They can forward them to their home email address, they can go file attachment, save.
What some customers wanted was a more secure method, where they could still manage their messages from a desktop graphical client or a mobile client, but they really needed those messages to stay in the system.
So, for that we developed secure unified messaging. Now this architecture while used in conjunction with email doesn't actually touch the email server in any way at all. It's completely independent. So, your voice and fax messages stay on the CX server, and we've written an app that you deploy on one of your web servers to give the clients a web application that will access their messages.
And now they can play their voicemail messages over the phone, play them over the speakers, forward them to other system users, delete them, all the same things they could do from the phone, but there’s no way to get that message out of the system. And hence the name secure unified messaging.
This is also the easiest type to deploy, since once you put the web app in place there's no touch required out on any of the clients. And it's turned out to be one of the more popular ways of kind of storing messages while still giving the productivity gains of a desktop client.
Now the first three we just talked about, the secure, server, and client, those all require a user license. Another question you want to ask when you talk to somebody is how are your UM features licensed? Do I have to buy it for everybody at once? Can I choose the different message stores?
On the CX system I can have some users with client-based, some users with server, and some users with secure. We have complete flexibility in that message store.
Now this last type of unified messaging is really more of a notification tool than a unified messaging tool. This is a version that a lot of systems offer. Ours does as well. And this one has the big difference of being unlicensed, meaning it's free.
On CX, we don't license voicemail users. You can put as many voicemail users on the system as you want, and any of those users can be enabled for this feature without you having to buy an additional license. So this has an advantage of kind of getting you a chance to start in with looking at this value for unified messaging without actually having to pay anything.
Now what's really happening here is our product, a standard part of our product, we have a very advanced notification engine, and we can call you at up to nine numbers and tell you, you have a new message. We can send you an SMS message, true SMS message. We can send you an SMTP message. We can send messages only when certain types of messages come in. It's a very powerful engine.
And one of the features it has is when we send you that notification as an email message, we can include a copy of that message with that email. So now what you'll get in that email is just an email that says, “Hi, you have a new message, it's from John Smith,” and then there'll be a .wav file attachment. And you can play that .wav file attachment on whatever device you're using to handle your email.
Now that's not the actual message. That's a copy. What that means is there's another copy still back on CX. So if you delete the email, it'll still be on your CX server. Now there's ways if you really want to just have it in the email, you can simply tell CX to basically delete all the messages for that user every night at midnight so they won't build up in the mailbox.
But typically this copy is something that's used as kind of a niche application. For contractors, perhaps, you aren't going to put on your email infrastructure, or when someone goes on vacation and just wants their messages sent out to their personal email. So keep in mind this fourth type of unified messaging has no license charge with it.
Now having looked at the architecture, we now can kind of look at where the discussions tend to go in the purchase of unified messaging. What's interesting is we don't spend as much time talking about features as we do about what everyone tends to call the five Cs, compliance, confidentiality, configuration, capacity, and cost. And the reason for this is all the attention that has been paid to things like discovery and compliance in the email world. Some people are fairly sure that applies to the voice messaging world as well.
Now I don't know of any laws that have really been put into play that spell it out exactly. I think this is largely a due diligence part for you as a customer to see what fits your particular industry's needs. So what you definitely want to do when you're evaluating unified messaging systems is talk about these with the vendor.
Compliance, that starts with you. Talk to your people, your IT people, people in your legal department, and you need to understand where you would like to put those voice messages. What meets what you believe are the legal requirements in your industry? You need to have them in your email server so they are available for discovery. You feel that if you put them in the email server that makes them available, so you'd rather not. You need to lay down exactly what you're looking for. Then, in our case, we're going to be able to deal with those fairly easily with you.
The second piece is confidentiality. Besides just the laws about discovery, there are a lot of implications to messages. The obvious example is HIPAA in the health industry. It is very particular about what you do with any kind of message that has any patient information. You might have a health care organization where a third of their people are dealing with sensitive information, and they just don't want those voice messages to go in the email where they can then actually be broadcast off into some other location. But, at the same time, the administrative people and the management people who travel really would like their messages in that store so they can get them conveniently from any of their devices.
That kind of decision comes down to the third, the configuration topic. Our system is flexible. Certain users can have certain kinds of message stores as you believe is required. Make sure you have that discussion. Not a lot of systems can do that. I think it's a very important part not only in this initial implementation, but think if down the year somebody says, no, now the law's come out, everyone has to archive their voicemail. The ability to just reprogram a system quickly and comply with that as opposed to perhaps having to replace a system is something you should definitely consider.
You have to understand capacity, message size, the load on servers, and the load on the network. While this is less of a concern as time goes on, as the network gets bigger, stronger, faster, it is still a discussion you should have.
We have a number of features on our system that lessen the impact. Our typical network load, let's say you're storing messages in exchange, will probably be 40 percent less than anyone else's because we do cached copies of the messages on our servers and things along those lines. So, it's something to consider.
Then, of course, the last piece is cost. Cost is not just what it costs to buy, obviously, but the long term TCO, the total cost of ownership. How easy is the system to maintain? How flexible is it if you have to change the architecture around? That's a lot of information to have to go through in this process, but it really does require you to make these kinds of decisions before you pick which company you want to source the product from.
We're happy to have conversations with you about this, but to kind of leave it more in your hands, to let you be open about it, we also have a unified messaging checklist. This checklist covers all these concepts we just talked about: interoperability, storage types, all the things that we think you should have as discussion points when you evaluate and any vendor for unified messaging.
This is kind of a product neutral document as much as we could make it so. Obviously, it talks about the kind of features that we can deliver to make sure if you're interested in those you can get them from the other vendors as well. So, we're going to make this checklist available to you, and you can feel free to go and download this checklist and use it as a guideline when you start evaluating going to a unified messaging solution.
Our product does much more than unified messaging. It's a very powerful call processing engine. It's a custom business tool for creating unique solutions for information access in your environment. Hopefully, if you are looking at just unified messaging you'll broaden your view a little. Once you start looking at the products you're going to evaluate, make sure you look at more than just unified messaging. The fact that we can integrate all of this functionality into a single server makes our solution very, very appealing beyond just as a unified messaging piece.
Hopefully, you found this interesting. If you'd like to get the unified messaging white paper here's the web address. You can go out there and download it. There are a lot of white papers, but right on the very front of that page is the unified messaging checklist. Feel free to download anything else that captures your interest.
Lastly, we hope you enjoy these types of webinars. We hope they're helpful, and we'd really love to get questions and comments from you. Is this the kind of thing you want to see? Would you have liked more depth, less depth, different topics? Any kind of comment at all, feel free to send that to email@example.com.
I'd like to thank you for taking the time to come to this webinar. Hopefully, you found it interesting, and, if not, there's the address where you can do something about that. Thanks.