I've tried Skype for Business and found it lacking. Skype for Business (now years into availability) doesn't handle screen control across the only two OSes it purports to "support" (MacOS and Windows). I think interactive drawing is also not supported everywhere.
From what I'm told, the Skype for Business back-end is not enterprise-ready, by which I mean the back-end is written to assume that one user or one set of users has admin control over all the lines set up in the system. So one user or set of users remains in charge of all of the telephony details (role-based accounts, response groups, etc.). A proper enterprise-ready program allows the admin capabilities to be limited to groups of users and delegate functionality to those groups for certain lines. This arrangement lets you have multiple simultaneous admins edit different non-conflicting details (such as setup for two different response groups) simultaneously with no problems. This means large organizations with lots of somewhat independent groups have to set up work queues where someone in each group files a request for the Skype for Business admin(s) to work on requests (e.g. Please make 123-555-1234 a response group set up in the following way...). This slows down an admin in any of those groups considerably as those admins wait for their work requests to be fulfilled or further questions to be sent back in response.
Also some of the limits in Skype for Business strike me as silly: one of them concerns response groups (a Skype for Business term for how inbound calls are routed to a series of receptionists called "agents" in Skype for Business parlance). If you want a response group where some of the agents are allowed to decide whether they want to receive the calls (known as a "formal login" response group in Skype for Business parlance), and other users are required to receive the calls (an "informal login") you can't have both of these kinds of agents in the same response group. You have to set it up so that, say, the informal login agents get the call first and (if they don't take the call after a few seconds) the call is passed to the formal login agents.
From what I'm told, Skype for Business doesn't handle nested directory service groups properly when those groups contain sets of agents (which I understand Skype for Business treats as distribution lists when one uses Microsoft's directory server Active Directory). If that's so, this means that organizations that keep tidy directory service hierarchies can't reuse their groups efficiently.
From what I'm told, the Skype for Business back-end is not enterprise-ready, by which I mean the back-end is written to assume that one user or one set of users has admin control over all the lines set up in the system. So one user or set of users remains in charge of all of the telephony details (role-based accounts, response groups, etc.). A proper enterprise-ready program allows the admin capabilities to be limited to groups of users and delegate functionality to those groups for certain lines. This arrangement lets you have multiple simultaneous admins edit different non-conflicting details (such as setup for two different response groups) simultaneously with no problems. This means large organizations with lots of somewhat independent groups have to set up work queues where someone in each group files a request for the Skype for Business admin(s) to work on requests (e.g. Please make 123-555-1234 a response group set up in the following way...). This slows down an admin in any of those groups considerably as those admins wait for their work requests to be fulfilled or further questions to be sent back in response.
Also some of the limits in Skype for Business strike me as silly: one of them concerns response groups (a Skype for Business term for how inbound calls are routed to a series of receptionists called "agents" in Skype for Business parlance). If you want a response group where some of the agents are allowed to decide whether they want to receive the calls (known as a "formal login" response group in Skype for Business parlance), and other users are required to receive the calls (an "informal login") you can't have both of these kinds of agents in the same response group. You have to set it up so that, say, the informal login agents get the call first and (if they don't take the call after a few seconds) the call is passed to the formal login agents.
From what I'm told, Skype for Business doesn't handle nested directory service groups properly when those groups contain sets of agents (which I understand Skype for Business treats as distribution lists when one uses Microsoft's directory server Active Directory). If that's so, this means that organizations that keep tidy directory service hierarchies can't reuse their groups efficiently.