What needs improvement with TeamViewer?

We cannot see the number of monitors working on the system simultaneously. It becomes complicated to switch from one monitor to another for different windows.

There are indeed more modern and user-friendly UI designs available in the market, which may overshadow TeamViewer's UI. This could be attributed to the fact that TeamViewer has been around for a while and sticking to its legacy interface. When you're a well-established product, it becomes more challenging to adopt new UI trends and make significant changes.

This solution could be improved by offering more flexibility in terms of usage.

TeamViewer can improve connectivity. I had some problems connecting to my clients and now I use AnyDesk.

It would be very helpful if they could provide a manual for the installation process and describe more of their features. They don't seem to provide that right now.

There is nothing that really needs improvement. I have noticed that when I access another person's computer, sometimes the tab is visible, and sometimes it is not, which can be difficult. It's a little glitch.

TeamViewer could improve by having a cloud version. Having the solution on the system could cause some cyber security concerns with data. In a feature update, if there was a bios install option it would be helpful. This feature would allow TeamViewer to connect in the background to the internet and then we can switch on the computer, which would be very helpful.

Sometimes it lags. They need to optimize it a bit. AnyDesk, for example, works faster.

In a future release of TeamViewer, they should improve password access. Every time one of my clients access the free version of TeamViewer, the password changes and they cannot update the password. Even if the solution is provided for free, it should allow them to update or set the fixed password because it is very difficult to type the complicated password.

TeamViewer is publicly available and anyone can use it. This is the reason that many organizations do not permit the use of this solution. It is not considered to be secure enough.

TeamViewer could improve by having support for other operating systems, such as Linux.

In the next release, I would prefer to have a voice integration and collaboration feature to support multiple teams simultaneously.

I use Teamviewer in my personal capacity. We cannot use it for our business for IT security reasons. The solution could be improved by enhancing the use of the mobile version to be used on phones.

TeamViewer can improve by making the interface more user-friendly. It looks very basic, they can make it more modern and easy to use. In an upcoming release, it would be a benefit to have notifications from the person that you are viewing, such as when they are using the screen or closing an application. Having some response from their side would be helpful.

The solution could improve by increasing or removing the time limitation on the use of a session.

TeamViewer could be more secure.

The installation and the update agent could improve.

Its pricing can be improved. It would be nice if it is cheaper. I can use up to three computers, but sometimes I have four. So, it would be nice to have at least four computers. There is a limitation on the number of participants you can have in a meeting. That's the only reason I use Zoom in addition to this.

There is a paid version of this solution with more features available. However, they should provide more free features to the user, such as factor authentication.

I didn't like the fact that you had to install a client for remote support. If you didn't install the client, you were very limited in terms of what you could do. For a whole enterprise, it is just not an easy task to install a client on everything. Even if you're using SCCM, it is an undertaking. For transient clients that you don't necessarily support a hundred percent of the time, it would be nice to be able to connect to them and support their issues without having to install something on their machines. In my previous company, we were looking at this solution as being a collaborative tool for the enterprise in terms of video conferencing, calling, and scheduling. They were working on bringing a bunch of products together to make their suite a little more integrated, but it really wasn't at the point where we wanted it to be in terms of integration. We looked at it, reviewed it, and tested it out a bit. We then decided to go with Microsoft Teams. It has the clunkiness of having separate modules that aren't totally integrated. There are different methods for doing different things, which makes it a little bit more complicated. There should be the same way whether you are doing remote support or just calls.

They should release features such as Augmented Reality into both plain and standard versions of TeamViewer. Nowadays, you have to wait for another release, or another product version while Augmented Reality features should just be integrated into the standard version of TeamViewer. The product could be less expensive. There are many similar products that are free these days.

Sometimes, the app can be a little cumbersome when accessing certain aspects of the program. I don't know if that's a TeamViewer thing or the application I'm trying to use on the actual PC. As far as the connection, there has been no issues with the connection. It's just once I'm in the app and using it, I haven't been able to decide if I can do all functions with the app, like I can if I'm sitting actually at the computer. I don't know if that's a TeamViewer thing or a computer issue. I'm still on a Windows 7 based, six-year computer which is due for an upgrade. It's a minor issue, and some of the minor issues I have may go away once my desktop computer at work is upgraded.

You are limited with the regular TeamViewer. You have don't have sound. You cannot transfer things. It has been a long time (years) since I used the regular version. In the beginning, you will need a bit of adaptation to use the solution. This is normal. For example, if you are switching to a car with the wheel on the left to a car with the wheel on the right, you will need a bit of adaptation. Even now, we have customers who will not allow us to connect to them because of security sensitivity, e.g., military departments for clients. They will send us pictures or we can talk with somebody onsite, then we need to ask them questions. However, this process is long. It's costly also because of the time spent. Instead of spending 30 minutes, we will spend two to three hours for the same thing. A feature that they could add is chat with sound to talk.

We don't really use the chat feature. Some of the additional features, like the meeting stuff, is making it too cluttered. Also, we don't need TeamViewer to be a competitor to our video conferencing service, although that basic service might be nice for people who don't want to go through the extra expense. We are basically satisfied with TeamViewer for doing remote support. We use InvGate, which is a help desk and asset management tool that we are currently using. They announced about six to seven months ago that they will be integrating TeamViewer into their help desk system. We haven't heard any recent developments yet, but we know that is on their horizon.

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.

It's not the program itself that's an issue, but there is a need for some better documentation on how to use the web portal Management Console. That seems to be a bit lacking in directions, if you aren't paying attention and you don't know what to do. Better documentation would make it a little bit easier to set things up in different groups and share groups between people.

If were to I put myself in the seat of a small business owner, I would prefer TeamViewer to be more of a pay-once-and-own-it solution, rather than paying via a subscription model (although I am using the free version). Only annual subscriptions are available. It makes paying for it the first time seem a little daunting. It also renews automatically, annually, and you are only allowed to cancel it by applying for the cancellation 28 days in advance through a support ticket. They should really tend to that.

Speed and performance have been addressed. I know there was a security blip a few years ago and they now do the extra authentication, which I appreciate and clients appreciate. I haven't had the contact TeamViewer in so long. When I originally started with TeamViewer, they didn't prompt the user to log the details of the connection. You'd have to manually go back into the TeamViewer Manager and log your comment, after you had closed it. Then you'd go back into TeamViewer, go to that connection and assign a comment to it, which I would sometimes forget to do, especially if I was jumping from call to call to call. I sent in a feature request asking them to add the prompts and I'm sure other people sent in the same feature request. They did that many years ago.

The remote connection process is reliable, good, and fast. On occasion, when it can't connect to a machine, the error messages aren't always helpful to tell you why you can't connect, as the message doesn't help troubleshoot whether it is too slow, too much interference, etc. I usually have to run to another computer and figure out what is going on, then restart it. The diagnostics could be improved.

If they could figure out a little better solution for the iOS stuff other than just a screen share, even though it's an Apple thing, and Apple doesn't like to give up control of their devices. If they ever got to that point, and I could manipulate an iPad or iPhone, that would be awesome. Since we have a bunch of iPad users who are struggling with doing different things, it would be nice to be able to just jump on and actually show them, "Here, do this, this, and this." Similar to what we do with the laptops, e.g. for training.

While TeamViewer has some great benefits, there are also some significant challenges and bugs. The biggest problem in our environment is that it's difficult, or sometimes even impossible, to properly manage granular access to a Host. It's a huge problem that mostly affects the Mac platform, but even with Windows Hosts the entire concept of how access to Hosts is configured centrally is a bit of a mess, especially compared to the true elegance of how LogMeIn worked. With LogMeIn, we could centrally assign techs to a Group of Hosts, and those Techs could control that entire group of Hosts. Even a one-off contractor could be temporarily or permanently given access to a Host, just using their email address. In addition to Group-based assignments, you could assign additional Hosts individually to a tech, so that they could control a single additional Host in addition to the main Host Group(s) that they had access to. It was extremely elegant, easy ton configure, made instant sense, and worked perfectly. For example, I could have a group called "Servers" in LogMeIn, and I could give my infrastructure staff access to all of those servers. If I also wanted one of my Developers to be able to access a couple of those servers, I just gave them access to those individual Hosts in LogMeIn Central. By comparison, TeamViewer is a complete mess. The way they do it is a total nightmare, and it does not work well. In TeamViewer, Techs can be given access to Host Groups...but a TeamViewer Host can't be in more than one Group...and Groups is the only way that you can give access to a user. So the kind of granular control, giving access to Group(s) but also being able to give access to individual Hosts, is completely missing. The workarounds for this are messy: you can either split off any Hosts that may need individual control by other users into separate Groups, or you can have the Techs that need individual access manually add the Hosts to their "My Computers (Local)" Group in their own client, having to know the Host ID, etc. In addition, the administration of Groups and access to Hosts in general is fragmented and confusing, with strange limitations. For example, let's say one of my departments needs to create a Group of Hosts. Only the individual tech who created the Group can control it: no one else can change the name or make other changes...only that tech that created it and therefore "owns" it can. TeamViewer's "best practice" recommendation is to use a generic "Master" account to create and manage all Groups, having to login with that Master account rather than your own individual account, which is bad for many reasons, including making MFA more difficult and it has serious security and management implications. By contrast in LogMeIn, when a privileged administrator creates a Group, it just belongs to the organization, other similarly-privileged administrators can manage the Group, other techs can see it, and it all makes total, elegant sense. Hosts can be assigned to multiple Groups or individual Techs, etc: it's extremely flexible and straightforward. TeamViewer's macOS Host is unfortunately not up to scratch with the Windows Host: it's missing some extremely important features. I sincerely hope that the TeamViewer macOS development team is going to address the problems in the near future. For example, you can't configure multiple "unattended control" passwords on the macOS Host, to give Host access to different departments or individual users but using different passwords. The Windows Host, by contrast, allows multiple unattended control passwords. Another way to accomplish this on the Windows Host is via Windows OS authentication, allowing users with either Windows local or central Active Directory (AD) credentials to authenticate to TeamViewer. This feature is also missing on the macOS Host: there's no way to authenticate using local macOS accounts (which LogMeIn allowed), nor can you authenticate using AD credentials, even if the Mac is bound to AD. So on the macOS Host, there's exactly one unattended-control password to control that Host, which is a big problem in my environment with giving granular control to server Hosts. There is a workaround, but it's completely obnoxious: TeamViewer has an automatic Host-generated password, one that usually changes after every session. It's designed for the local user who's using the Host machine to be able to give a tech a one-time password for a single support session, and the password changes the next time. There is a Host setting, however, that instructs the Host to keep that random password the same after each session, so I can use that as a bad hack to allow individual techs to control Hosts where they shouldn't know the main unattended-control passsword (after they add the Host manually in their "My Computers (Local)" Group....sigh). Unfortunately, this workaround breaks when you restart the Host or relaunch TeamVIewer on the Host, as even with the "Don't Change" setting for the random password, it still changes whenever TeamViewer Host launches. So after every update or reboot, we have to distribute the new random password to some techs...time-consuming and messy. Another big issue with the macOS Host is that it does not have a method of avoiding locking the screen at the end of a session. The setting to lock the Host's screen after a control session seems fairly random, and if the controlling tech forgets to manually disable that "feature" during the session, the user (or server) gets the screen locked in their face when the tech finishes. That causes a lot of problems, especially with some of our servers that need to remain unlocked and by annoying the heck out of users. On the Windows Host, there is an Advanced setting to instruct the Host to never lock its screen after a remote session, but that setting is missing on the macOS Host. There are some miscellaneous features missing on the macOS Host, like auto-hiding the TeamViewer panel and preventing accidental quitting of TeamViewer. These features were deemed necessary (and they are) in the past and thus were implemented on the Windows Host: they should also be available on the macOS Host. Another issue concerns Windows virtual machines. Unfortunately, TeamViewer has historically depended on the Host's MAC address as part of generating the unique TeamViewer ID, because the MAC address was a fairly immutable thing back in the day. However modern virtual machines (VMs) have dynamic MAC addresses, which means that suddenly a Host gets a new TeamViewer ID, and you have no idea what it is, with no way to control the VM. TeamViewer Tech Support tried to help with some workarounds to try to assign static TeamViewer IDs, but none were successful. Their recommendation is to manually manage MAC addresses on VMs, which is a non-starter in clustered environments where dynamic MAC addressing is needed. TeamViewer needs to stop depending on MAC addresses as a part of generating the TeamViewer ID: LogMeIn figured it out and so TeamViewer should be able to. A final concern is the accidental renaming of Hosts with an unattended-control password. As we've increased the use of TeamViewer, we've found that our techs accidentally rename Hosts in the background while they think they're entering the unattended password for that Host. The Host actually gets renamed with the unattended control password, which is obviously a huge security issue. We're trying to be mindful of that bug to prevent it from happening, but it's extremely problematic.

There is nothing to improve; TeamViewer already works perfectly. But still, I think the price factor for small business.

Since TeamViewer version 13 introduced a Native Linux rather than running the Windows version through an emulation layer, that has been great. However, certain features didn't make it into the initial two releases. So far, the Linux version no longer has support for meetings. It wasn't a feature, and very often a group that we put together recently was looking for a way to do online meetings. I thought, "I have a subscription to TeamViewer that includes that." I do, but that function no longer works in Linux version. I am sort of waiting for that to come back. Support for mobile devices from Linux has been missing since the Native client was rolled out. This was a nice option, especially when trying to walk somebody who was struggling to understand something on their phone. I don't do a whole lot of support for mobile devices, but if I could just direct them to the Google Play Store to go grab the TeamViewer app, they could give me a number to connect to and I could see the screen with them. I'm very grateful that there is a Native Linux client. That is a step forward and in the right direction. It shows TeamViewer's commitment to the Linux platform. I am very pleased about it, but there are some things that I used to have when the Linux version was just the Windows version packaged with the necessary emulation layers to make it work. I miss some of those features which used to be there prior to the Native Linux version. Hopefully, they will make it back into the product in the not too distant future. It would be nice to see some of those other features that we used to have come back, using them on Windows and Mac. I can no longer connect via web links, which is not the end of the world, but it's a mild annoyance. I used to be able to click something from my browser, then boom, there you go. At the time, it was the old TeamViewer that was based on the Windows software. I had to take some initial steps to configure an environment where those links worked, but once Linux was up, it was no different than on Windows. I could be on the web or in a remote monitoring platform, and if I needed to connect with one of my client devices. I would select from there, and say, "Connect to TeamViewer," and it would jump right in. I can't do that anymore.

The price is a killer for the amount I normally use it.

Wish it would support multiple support persons at the same time to assist a client for situations that need team collaboration.

* The business interface is clunky and not well-documented. * It should have ability to display notes in the computer list.