The Remote Control Chat feature allows technicians to communicate directly with end users during remote sessions. This streamlines troubleshooting by keeping conversations within the session, improving clarity, and enhancing the support experience without needing separate communication tools.
Follow this request to get an email when its roadmap stage changes.
31 comments
Use the email address associated with your Level account.
I would also love this feature
Second this as well, important feature to streamline support.
A must-have feature for any RMM tool.
Yes please - and thank you for continuing to make Level an awesome RMM.
This feature would be amazing!!
What about the ability for an end user to initiate a support ticket/chat directly from their desktop and not just within a remote session?
Also the other way around, msp initiate chat before engaging a remote session to see if thats the right time to fix the issue.
screenconnect already has this. it would be amazing if they let us use our tools we already own
This would be fantastic! Most of the time, I'm having to open another channel/form of communication. Please make this happen, sooner rather than later!
Need please
This would be a very useful feature.
That would be a top tier feature
I disagree - many platforms I have used, have deprecated it. Only way I care for this from level? is if it is NOT tied to an email account
A QuickConnect extension would also be great for serving customers who are not on Level.
Needed.
New to level, and I miss this daily.
Hey everyone! I was just talking to the team about this and we're curious about a few things: 1 - Is it important that the chat history be permanently stored? Or would it be better that the conversations be ephemeral? 2 - Related to #1, if the chat can pop-up at the login screen (pre-session) then it's possible that multiple users of the same machine could see a chat because the chat session would be per computer and not per user. What are opinions about this? Privacy becomes a concern if one user can resume another user's chat. 3 - Related to #2 - what about terminal servers/ remote desktop servers with many sessions? 4 - If an end-user responds after the tech has moved on to other devices, is it ok to auto-respond that the tech is no longer connected? Or is it important that the session stay active? That means we now need to be thinking about notifications for the techs. Not something we currently have. 5 - What else are we not thinking about? Thanks for your feedback as we work on designing this feature!
I don't think chat's need to be permanently stored. Seeing the chat pre-session would also be helpful. I don't have any clients on RDP servers, so I am not sure how that would work. Yes, auto-respond that the tech is no longer connected would be my preference. I don't need another notification system to manage. Ha ha.
Maybe temporarily stored (30 days?) in case we need to review history either to collect information related to ticket work or review tech conduct, etc. In this case, it can be machine-based, and the end user shouldn't see any history. Maybe keep chat logs/history in the portal somewhere? I've got nothing for this one. an auto respond would suffice, or even just a "tech no longer active" message on the endpoint before auto-closing the chat.
30 days or less would be nice for RTK requests.
1 - I would like to see chat history stored on level side as a way to audit the chats for tech conduct or similar as noted by Kevin. Possibly stored and attached to the Recent Sessions an option to see/download the chat log. With each new session starting a new log. 2 - I don't think there is a need to have the chat pop-up at the login screen. As if the user isn't at the computer, we would then move to sending them an email. 3 - We don't have many users on terminal servers, but usually we'll be connecting to the machine they are using to connect to the terminal server chatting through that and not through the terminal server itself. 4 - Auto respond that the tech is no longer connected would be good, with the ability to modify response as well.
For me ephemeral would be fine, and I'd be happy with a completely clean chat each time you initiate a new Remote Control session to a device. I don't need users to initiate the chat or chat to exist at all beyond the Remote Control session (if it does get logged somewhere that would be fine too). When you Remote Control onto a device you get the little "xxx from xxx is remotely accessing your computer.". I'd envision chat being attached to that, and when it's displayed both sides can text chat, once that's gone so is the chat session. In Remote Control you have to pick which session to connect to from the drop down (Console, RDP etc). I think you should only be able to chat with the session you are connected to, which would resolve the terminal server/remote desktop server piece. For me chat is purely about saving me a phone call or a separate Slack/Teams/Gpogle Chat, while the user shows me something on their screen, or me explaining something I'm doing. One extra thing, it would be nice if 2 (or more) techs were connected via Remote Control to the same device if they could chat with the device user in a multi way chat. Sometimes things require an extra pair of eyes to input.
This pretty much sums up what we need. Our adhoc RMM supports chat and it's invaluable for quickly resolving customer issues without having to phone the customer and get through to the end user.
1 - No. Maybe 30 days or even less. 2 - Pre-session would be helpful. Especially to make sure we can remote in. 3 - We hardly have users doing RDP on servers, so I'm not sure if this would be an issue. 4 - I think we can just inform the user the session is no longer active. No need to send notifications.
1 - Doesn't need to be permanent, but 30-90 days would be nice. 2 - We're pretty used to chat not working from a login screen, could be awesome to have, but otherwise happy for it to be tied to the logged in user session. 3 - Absolute must, should have the option to switch between active sessions for remote control and chat should be applied to whatever session you're viewing (assuming your solution will be tied to remote control) 4 - I think thats a good idea, the chat should notify the user that the tech has left, but if they need to send a message back then maybe it could be an email alert to the tech? No feedback for 5, but I will say if this gets added, we can seriously consider Level to replace our current RMM. No remote chat is a non-starter for mass-deployment for us unfortunately.
Hi Brian, 1. Permanent is a security concern, but even multiple days is potentially a problem if this chat is persistent for all users. We have both RDP servers and shared workstations, so limiting this to 8-24 hours would be a good arbitrary number. Ultimately, make it a setting in the system and allow for individual computers/folders to override the defaults should it suit our needs. 2. Pre-session can be useful, but this assumes we are using logoff or reboot as a troubleshooting measure, and honestly this would justify getting the user on the phone. Keep it simple, pre-session chat is more trouble than it is worth. 3. RDP servers is a where all interactions need to be isolated to the selected session, as we don't wish to have several users seeing the little notification that someone is connected, when we can't actually see their screen at that moment. Nor do we wish to be chatting with every user of an RDP server at once. 4. The simplest solution for this scenario is notify the user in the chat as soon as a technician disconnects. If they attempt to send another message, remind the user there is no technician connected and provide them with our support contact information or a custom message we can configure. One thing that would go a step beyond the basics is leveraging an integrated PSA... if the integration exists, offer the user an option to create a ticket directly from the chat. Bonus points if you can also query any existing open tickets for that user, which assumes the PSA can correlate the computer user with a PSA user. 5-1. Something that is less common, chat without remote control. However, to not overstep the role of a PSA, this should only be possible when initiated by the technician. Once the technician closes the chat (provide an 'end chat' button for both parties), revert back to #4 above. Bonus points here as well should there be an integrated PSA, allow the technician to either correlate the chat to an active ticket, or spawn a ticket from the chat session. Keeping in mind, any integration with a PSA would mean the chat session needs to be ephemeral, or Level needs to only include chat messages tied to the current session. I presume this could be accomplished by tracking the session ID with each chat message behind the scenes. 5-2. Another thought is making sure the chat can support embedded images natively, pasted from the clipboard. The single worst feature of any chat system I've used is forcing files to be attached when all I am sending is screenshots from my computer. In the same fashion, file attachments should be just as easy - either copy/paste or drag & drop. To make sure we aren't wasting cloud space, images and attachments should be stored temporarily on both sides of the connection - I do not wish for Level to explode their cloud storage expenses trying to retain millions of images and files for persistent chats. Maybe this can be an add-on or an integration to existing cloud accounts. Let me know if you have any questions!
Hi Brian, any updates on what Level staff is thinking about for this feature?
This feature and function would be a lifesaver for our organization. We always used this when remoting into our clients computers. It was great to be able to chat with our clients while working remotely on the computer. Sometimes its hard to call and talk. Its more efficient to just start a chat with the end user
Just giving this another vote to get this feature added. Its tough when we have a client when we have remoted into the computer to provide support and have no way of Realtime communicating with them. So many organizations do not have phones in the locations where the user needs support or have a cell phone available. It so convenient to just start a chat with the user
Yes! Desperately waiting for this feature! Greatly needed tool for IT MSP's remotely connected to end users. Once you have this, I won't need ScreenConnect anymore.
Surprised this isn't done yet it's a much better solution than having to organise a teams session particular when time is critical.
