I complained a lot about Teamspeak falling behind modern voip solutions, so I have a few proposals what can be done. I don't know how similar that design is to Discord (I don't regularly visit that app and didn't analyze it too deeply), but I assume in general similar apps converge to similar designs these days.

This is a somewhat users/admin/client side point of view.

1. Connect
1.1. The user starts the voip client by either clicking a link in a web site or starting a standalone client
1.2. If there are connection details provided with the link, the user connects to the given server/channel.
1.3. On the absence of connection details, the user connects to the last server/channel he was connected.
1.4. If there are neither connection details provided nor a last known server, the client starts with an empty tree in its UI. Or to the Teamspeak public server if you like.

2. Credentials
2.1. as long as the user didn't define any credentials, the client uses an anonymous guest identity that is identical on every server.
2.2. the user can connect his client to identities from Google, Facebook, Microsoft whatever social media that supports identity linking. If he doesn't want to, he can generate an identity on MyTeamspeak. For closed communities, an identity server is provided as sub-service on one Teamspeak server. Keys are not stored locally on any client, username+password+2 factor auth is used to authenticate. In the Teamspeak server database, tokens from the identity providers are stored, never passwords and never password hashes.
2.3 The client connects to a server with the credentials he used the last time for this server
2.4. If the client didn't connect to a server before, he tries to connect with the credential he set as primary
2.5. If the server requires some identity the client did not yet provide, the user is prompted to provide it

3. Client UI
3.1. The client's main window contains a tree, whose top level entries are all servers the client did connect to in the past. This replaces any bookmark or connect menu. Instead of a direct connect menu, there is a '+' button to add a new server entry to the UI.
3.2. The 2nd level (and down) hierarchy is the client channel tree of the corresponding server.
3.3. If the client is connected to a server, a live channel tree view of that server is displayed. If the client is not connected to a server, a cached view is displayed.
3.3. A client can jump from server to server by just clicking on a live or cached display of a channel on a different server. It looks like as if all servers with all their channels are always available to him. He doesn't 'connect' to or 'disconnect' from a server - he starts the app and is in the last channel he was when he closed the app. Or some default channel he defines if he wants to. Then he just changes channels without seeing that he is in fact changing servers.
3.4. A new server has one default channel. Every additional channel on a server is created as sub channel from the default channel. In the UI tree, the server entry itself is the default channel.

4. Permissions
4.1. The permissions are role-based, configured with acl (access control lists)
4.2. Every item for that access has to be managed, has a 'create', 'read', 'change', 'delete' and 'manage' permission. Depending on the type of item, additional permissions may be necessary. For example a channel has an additional permission called 'join'. A permission is either 'allow' or 'deny'. In absence of any permission, access to that item is denied. Permissions can be inherited from higher level items.
4.3. Permissions can be assigned to groups. For example, to be able to connect to a server, you need a 'login' permission to the server and the 'read' and 'join' permission to the default channel. This group may be called 'login'. There may be many groups, for example each channel may have a group that regulates access to it.
4.4. Groups may be nested. This way, access to resources can be collected and accumulated to a higher level. A group 'moderator' may contain all groups that define moderator access to several channels.
4.5. Users may be assigned to groups. A user that is assigned to the group 'moderator' is able to perform moderator duties according to the permissions in that group and nested groups.

5. Policies
5.1. Policies are rules that are assigned to channels and take effect to this channel only or this and all sub channels. Each policy contains a condition and an action.
5.2. Policies may contain settings to enforce in this channel. Examples: format of user nicknames, duration of inactivity, etc.
5.3. If the condition part of a policy matches, the action is executed. For example: if condition 'inactivity time > 30 min' matches, action 'move to hannel "afk"' is executed.

6. Chat
6.1. The client UI is divided horizontally or vertically and one displays the server+channel tree and the other the chat of the currently joined channel.
6.2. Channel chat is saved in the server database and can be scrolled back, so users can read what was written while the user was not in that channel (scrollback may be controlled by permissions)
6.3. chat is rich text with user icons, emotes and embeddeable images, chat message tree indented in Whatsapp/sms app style

7. Whiteboard and desktop sharing
7.1. Users may share their desktop or single desktop apps, and everyone in a channel may connect to and see what is shared.
7.2. an alternative/additional source for desktop sharing is a whiteboard with simple text writing and drawing facilities. Everyone can write and draw who the initiator of the session gave permission to.


Have fun.