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.
25 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.
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
