What is our primary use case?
We use TeamViewer's infrastructure. We have TeamViewer host clients running on devices, some wired in offices, some connected to WiFi or even cellular, and we use it to get quick access to the devices for technical support.
The other use case, which is a little bit weird, is that all of our clients are in healthcare so they are very particular about who gets into their network and who has access to their network. What we've found is that when a client has our company's software on one of the servers in their network, sometimes they don't want to give us access to their network to maintain our software. So whenever they have a problem with our software, we open a TeamViewer session from a desktop inside their network to our tech support group, and that person gives us access to the server so that we can maintain our software.
Again, that use case is a technical-support-type application, but it's a little bit different than us managing our own devices in the field. It is a tool that allows us to access our devices on somebody else's network under their supervision, without needing our own unfettered access. It makes it easier for IT security to approve us and it makes it easier for the client to get us in, particularly in circumstances where there's some urgency around that.
The vast majority of our users use TeamViewer on Windows machines. Some are desktops, some are tablets, and the latter range from a Surface Pro to a more substantial, military-ruggedized type of tablet.
How has it helped my organization?
The big benefit is that we can do things pretty quickly and easily, remotely. In many cases, we save a service visit to the field, which would otherwise require us to have a very large field service force or we would need to pay for and train somebody else's field service force. Quite literally, without TeamViewer's capabilities, we wouldn't be able to run our business.
What is most valuable?
Remote desktop control is what we use in TeamViewer for 99.999 percent of what we do.
We occasionally use the integrated text chat. There are circumstances we've seen where certain applications don't respond because they've got some sort of security built into them so that a remote user isn't able to control them. We can log in with TeamViewer, view the screen, and then leave instructions in the text chat that say, "Okay, please do this. Now, please do this. Now, please do that." We can actually guide the client through what they need to do, even for applications that don't allow a remote-control user to modify them.
The other thing that we're beginning to use more is the feature where, at the end of each session, you can type a quick note as to why you were logging in to that device. We've started putting in notes saying things like, "I went in to update Windows software," or, "I went in to fix a bug," or, "I went in to update our own software." We have not gone to the next step of reporting on, analyzing, reviewing, or using those comments as a way to drive additional follow-up. But it does at least give us the first step so that if somebody says, "Hey, why were you in my machine?" we can produce documentation that says why.
The TeamViewer system has some built-in security. The TeamViewer client connects to the TeamViewer host securely. Only a certain number of authorized users on our side have access to the system. Even within that, an individual endpoint can be assigned to a group, where not everybody has access but, rather, just one or two people who are part of a support team might have access to that particular device. So TeamViewer has given us tools to be able to segregate who has access to different things. That's been pretty helpful in dealing with some of our clients who have more "buttoned-up" security. They're able to say: "These two people have access to the devices." We have designated support people for that client who can go into their device and nobody else can even see that the device exists. That's really helpful.
The remote connection process is totally simple. It's as easy as it comes. We do install the software on field devices, but we also have TeamViewer's widget on our website. So, if you go to the support page on our website, you can click a link and download a white-labeled TeamViewer app that pops up and gives you a service key that you can fill in. That's an interesting tool. It makes it easier for customers who are not one of our owned assets to quickly download and light up a TeamViewer session so that we can help them with software configuration updates. Sometimes it's not even things that are our problem, but they don't know who else to call, so they call us.
What needs improvement?
I find it pretty easy to use. They redesigned the interface a while ago, and, honestly, when I first looked at it, it seemed sort of clumsy, but, now that I've gotten used to it, it's pretty darn easy. At first, everything was totally different. Doing simple things that I used to do, like connecting to a certain device, went from being obvious to a situation where there were just so many more features available that I had to click through to find the simple thing that I was trying to do.
In addition, and I don't know if it's TeamViewer's problem or not, I do find that sometimes we'll have a device in the field, and I'll click on remote control and it says "Can't authenticate." I'll double click in a different part of the TeamViewer interface and it'll say "Can't authenticate." Then I'll do it a third time and it connects. It's possible that it's just bad luck. It's also very possible that it's some bug within TeamViewer so that with the first click I'm waking up the TeamViewer connection, and with the second click I'm starting the connection but it's taking a long time because it's in a bad cell zone. Then, the third time, it's working because finally the thing is awake and recognized and is passing everything through. It may have nothing to do with TeamViewer, or it may be a TeamViewer issue. I don't know. That's the only thing I've really noticed that is problematic from our perspective. We'll see a device, we'll see it's online and that it should be available, but when we try to connect it doesn't connect. So that's a challenge.
In terms of additional features, the more TeamViewer can work with, and on, different devices, that would be helpful. We're doing some R&D with Cisco for some modems that have an IOx, which is a Unix-based compute area. If we could control that device using TeamViewer, that would be cool because, otherwise, we have to buy a Cisco cloud management software system to monitor those devices; similar to the Cradle Point. I'm not aware of any sort of onboard storage where we could install TeamViewer on a Cradlepoint, but if that is the case, then they should let people know about it because that would be a useful tool.
One of the things that would be a cool feature, and I'm not sure how TeamViewer could make it happen, would be to take an ad hoc TeamViewer session from our support website and, in the course of that, install the TeamViewer host, so that a client device would then become part of our network of machines we can get to relatively easily. That would be a huge time and energy saver. One of the things we find is that there will be a device and the users of that device have to use our software from time to time, but they don't use it often enough to really be good at it. So each time they use it, they go back through the learning-curve process. If we were able to quickly jump on their machine and walk them through what to do and how to do it, that would make it easier for them and easier for us.
For how long have I used the solution?
We've been using TeamViewer for four or five years. We started out on version 8 and we're up to 15 now.
What do I think about the stability of the solution?
The stability has been very good with the possible exception, as I mentioned earlier, of that three-clicks-to-connect issue, which seems to come and go. My guess is that it's something related to our devices being on cellular connections in areas with really bad cell service. But I've noticed it typically occurs when there's either a Windows update or a TeamViewer update, so it makes me wonder if maybe Microsoft introduces some sort of incompatibility that screws up TeamViewer and then there's a TeamViewer update that fixes it. We just have to remember to keep TeamViewer up to date on all of our clients in the field.
What do I think about the scalability of the solution?
We only manage 30 devices. I could see, if we had a thousand devices, that the management part might become a little more complicated. Given that you can separate different devices into groups, and you can give different people access to different groups, it might be relatively straightforward. Huge scalability isn't something that we've had to deal with yet.
The monitoring, asset management, and endpoint protection are things we just haven't had the time or the mental energy to test. If they work as advertised, those seem like they'd be great features for simplifying remote management. In terms of expanding use of TeamViewer, those are next on the list.
We'll be looking at endpoint protection; the patch-management and device health monitoring. Those are things we're very interested in. We want to do them to see how much, if any, additional CPU load and communication load is put on the device. We are a little concerned that we're going to clog up these fairly lightweight devices out in the field with a lot of administrative overhead instead of leaving them to do what they're supposed to do. We would probably do one or two as a test, just to see how it goes, and then start to crank it up. We have about 30 devices in the field that we monitor with TeamViewer; it's not like we've got tens of thousands.
How are customer service and technical support?
We have used technical support very sparingly, but when we've used it they've been great. They are very responsive, very knowledgeable, and they typically resolve our issue with one or two calls.
Which solution did I use previously and why did I switch?
We actually initially started using it because we're based on the east coast in Boston and Washington, D.C. and we had a client in Chicago who had our software on a number of devices. He wanted those computers to be someone else's problem, namely our problem. He asked us to have some sort of solution in place so that we could quickly visit the computer, check that everything was working, upload Windows updates, upload software updates for our software — whatever was needed to make sure that they were happy and healthy, including rebooting them from time to time. That's how we started with TeamViewer. Since then, more and more machines have been added to the list; some with this client and some with other clients. We found it so easy with that first client that we wondered why in the world we weren't using it with everybody else.
How was the initial setup?
We find the initial setup of TeamViewer very straightforward, but not everybody finds it as straightforward as we do. It takes minutes. Deploying TeamViewer is incredibly easy.
What was our ROI?
I don't really have a firm answer for how many end-users can now be supported with one support person, versus how many could be supported in the past. We didn't really have a pre-existing field support organization. But it's very clear that by using TeamViewer and not needing to go do field views visits, that we're a million times more productive. The eight hours of travel that might've been part of a field visit to go help one customer now become eight productive hours that you can be helping other customers or doing other things.
A lot of the TeamViewer stuff is done by people who do technical support for sales or technical support for core development. If they can quickly pop into a user's computer, check something out, fix something for them, and go back to their work, they get a lot more development work done than if they have to get in a car and drive somewhere or get on a plane and fly somewhere to do that same look at the client's setup and what needs to be fixed.
If you take a $100,000-a-year employee and enable him to spend 20 minutes per service call instead of eight hours per service call, that's a pretty darn impressive return.
TeamViewer is a great value. We obviously wish it was less expensive because we want everything to be free all the time. But we do recognize that sometimes you have to pay for things, just like we try to convince our clients that they should pay for our software.
TeamViewer is $600 or $700 per port per year, which we find that to be just fine. If we paid $100 per port per year we'd be happier, but we're very happy with the quality of the service and the capabilities that gives us. So it's been a great value for us.
I could go look up how many TeamViewer sessions we do per year, how many where we couldn't get the information through some other method, but that's where it becomes complicated to say specifically what the ROI is.
It's clear that it's a valuable product.
It's probably not valuable for everyone because there might be people who've got devices or systems where they have to hear it or smell it running to be able to diagnose what's going on. That's not really TeamViewer's strength. Its strength is getting visibility into a remote desktop, at least as far as we know, so that you can diagnose and treat a computer issue.
Which other solutions did I evaluate?
We've used a LogMeIn and there was something else that we've used, a solution that a partner of ours used which we tried for a while. TeamViewer seems to be a much more complete, stable, and reliable solution.
It's hard to make comparisons because it's been so long since I used LogMeIn. Longer ago than that, I used to use a VNC product that conceptually did the same stuff: gave me remote access to desktops. That was clunky, but it was probably as good as could be expected given the tools at the time.
As a user who has been given remote support access via LogMeIn, what people have done with LogMeIn's help function seems easier than what we do with TeamViewer. That may be entirely because we're not organized well enough in our TeamViewer implementation to be doing it the right way. I certainly don't want to bash TeamViewer's capabilities, because I think it's more likely that we just don't know all the things we could do.
With LogMeIn Rescue, the technician gives you an ID number. You put the ID number in and they're in your computer. And TeamViewer can probably do the same thing. I just haven't gone through the process of learning how to make that happen. The way we do it via our website is that you click a link, you download something, it pops open, it gives you an ID, the person then tells you the ID, then you're in. It's a couple of extra steps, rather than just being a web browser access.
What other advice do I have?
If somebody asks me what I recommend for remote support, I always recommend TeamViewer. If they say, "I use LogMeIn, and I love it," I wouldn't be surprised. I've been a user of LogMeIn's remote support, and it seems like a pretty effective and easy-to-use tool. I'm sure the market is big enough for more than two players, but we're pretty comfortably ensconced with TeamViewer as our solution.
Do it. It's outstanding. It's very simple. We love it.
TeamViewer has a lot of additional features. They do audio and even video chat through TeamViewer. They do patch management, asset control, and all sorts of other things and we've actually thought about some of those other services, but we haven't taken the plunge yet.
We have not integrated TeamViewer with a single sign-on application. We actually use the TeamViewer host as often as we can on our remote devices. The device in the field is always on and always connected, and the people on our side who need to log in and access those devices will use the standard TeamViewer authentication process, which is pretty thorough. It's a username and password and it has a visual Captcha and then, when you register a device, it also emails and says, "Hey, we saw that you just signed in on this device from this location. Is that you?" They know what they're doing.
The idea of using TeamViewer for 5G deployments and smart poles with IoT devices is potentially interesting because we have a lot of Cradlepoint modems out in the field and Cradlepoint has a cloud management console. If it would be possible for us to use TeamViewer to access and manage those devices, that would be interesting because we pay $80 a year per device for the license in the Cradlepoint console.
In terms of end-users of TeamViewer in our company, we only have three ports and we have five or six usernames. There are three or four guys who do most of the work, remoting into various devices and rooting around to see if they can fix something or if there are things that need to be fixed.