WXCUST-I-4096 : Shaun Robinson's Allow cross-organisation lobby bypass for VIMT/CVI
WXCUST-I-3322 : Guest's Allow some to join a organisation with the same account they are in an org with previously
WXCUST-I-10450 : Guest's Allow space owners to eject guests trying to call in without having to start a meeting
WXCUST-I-14113 : Guest's Microsooft Teams CVI - Ability to view and manage Microsoft Teams lobby participants
WXCUST-I-6390 : Saif Ananbeh's add the ability for the hosts to change their personal room security settings
WXCUST-I-13387 : Shereen Al Turk's allow some attendees to join before host and others not
WXCUST-I-12460 : Duha Salem Almanaseer's Add function to webex space meeting to admit Guests automatically
WXCUST-I-13457 : Guest's Extend options how participants join a Webex meeting - Lobby / no Lobby
WXCUST-I-6723 : Matteo Bonaita's enforce the option to enable mandatory lobby for SIP and PSTN accesses
WXCUST-I-11781 : Jehadadnan Theeb's Join the personal room without waiting in the lobby
WXCUST-I-6033 : Guest's Allow list domains for secure lobby setting
WXCUST-I-12098 : Manar Ali Mohammad Al-Amyreh's Admit attendees automatically
WXCUST-I-4223 : Mohammed Ismail Rafideen's Users from same domain (Organization) can enter the meeting even it is locked and no need to wait in lobby, provide option to add certain domains to avail same function
In summary, two themes emerge from other contributors' ideas -- security on the one hand, and friction reduction on the other.
The Control Hub is busy-enough as it is without having to add trusted domains (see your admin's answer to the last-referenced idea above) unless absolutely unavoidable. If something can be achieved without requiring a Control Hub configuration change, then it probably should be.
Most of the above asks can be merged and generalised into single ask, bringing requested enhancement to more Customers faster and overcoming the dissatisfaction with the operation of the Lobby in the Meetings product implicit in the aforementioned Aha!s.
With possible exceptions, most people hold meetings with people that they have met before or are likely to do in future. Therefore many of the above asks can be achieved by learning from the host/co-host's previous choices. For example, the first time you admit someone from another part of your own organisation into a meeting from the lobby you may choose for the system to remember that choice (admitting them without having to wait in the lobby).
Combined with the system "knowing" attendees on the basis of having sent a meeting invitation email to them, this leads to the system prompting you about attendees that it does not "know" and with whom you have not previously met. For these (and only these) "unknown" attendees, the host/co-host is prompted when the meeting opens with treatment choices (see below); those treatment choices being remembered. The host/co-host is also able to "un-remember" a remembered attendee at will. Removing an attendee from the remembered list means that the next time they attend, they'll be given the default teatment prompting you to answer and have your new choice applied to future meetings.
Unknown Attendee: This attendee is not on the guest list and you have not met with before. Choose what to do:
( * ) Admit them to the meeting right now
( ) Admit them to the meeting with the others cleared to join, when I give the word
( ) Leave them in the lobby to be spoken-with by me/co-host
( ) Do not admit them (politely) but not ban them
( ) Ban them and disconnect them now
2. Apply this treatment for:
( * ) This meeting subject
( ) All of my meetings
( ) Anyone's meetings here (applies to ban)
3. Apply this treatment to:
( * ) The attendee alone
( ) Anyone from the attendee's organisation (domain)
Learning (remembering past responses) in this way addresses both security concerns (denying access to confidential meetings or banning altogether) whilst at the same time removing tedious obstacles to meeting with your team members and valued external colleagues.