Concurrent Meeting Solution

I would like to be able to have a feature/account addon/something where
we can have 1-3 people manage an entity in which that entity can
schedule multiple, concurrent, and active meetings.

Our use case
is that we have a group of people that manage another set of people that
do interviews in the evening. These interviewers and interviewees are
not always full employees of our company, some just do this specific
thing for us on occasion. Not enough to justify a full seat. Although
non-phone licenses would work, we don't want to have to manage 10-15
accounts for the various concurrent interviews we have going on at the
same time. We just want to be able to hit the 'create meeting' button in
outlook and have that schedule a meeting that anyone with the phone
number and meeting information can dial in and join. No need for a
manager there either. This would be a service I would expect to be
parallel with what we are currently using, Chime.

Hopefully I have clearly described this, if not I would be happy to elaborate more.

Are there more concurrent meetings than licenses you have available? You could use delegate access and enable "Join before host" to allow the meeting to be scheduled and attended by someone who will not be present. You can even add a password for some basic security and if you want your facilitator/interviewer to be able to have host controls (record, kick people etc) you could provide the host key and just reset the next day?

I work with OP: We have a segment of our employee base who doesn't need "A corporate phone" nor the ability to regularly host meetings. However, members of this base have the need to attend meetings scheduled on their behalf, many of which are meetings of a class that happen in the same timeslots, concurrently.

This is what generates OPs ask.

As a company function we do these meetings all the time, but the folks attending may attend one to four a month and also don't need a phone number. So there's little incentive on our end to spend the MRC/seat for low and limited usage, but high incentive on our end to schedule the meetings on their behalf under a single user, the scheduling calendar (which has a full seat for this purpose) ... except that we cant' do concurrent meetings.

I would ﻿happily﻿ pay for a concurrent meetings license for this user seat.

We have a similar use case, our professional development content is delivered by an array of "facilitators", it's a large pool who as individuals only deliver a few sessions but we ended up getting them "collab only" licenses which gives them RC meetings and Glip. Their manager then schedules on their behalf where they can then click the link and deliver the course. It's inefficient but even this is way cheaper than our previous vendor.

I completely see your need there (we'd benefit from it too!) but I don't know that RingCentral has the ability to make that change as I don't remember concurrency being an option in Zoom either. It was in a few vendors but it tended to be a pretty expensive option and it was not mixed, it was either named hosts or company wide. Our previous platform was concurrency based but the platform performed very poorly and was insanely expensive for what it was.

Your ask is unreasonable and I think there is ample justification, there is absolutely a place for service accounts that can hold N number of concurrent meetings for this purpose, especially because Zoom/RingCentral integrates with course delivery platforms where you would absolutely expect this type of model. Seems like it would not be that hard to implement but I don't know that RingCentral themselves can implemented it. Will follow the question for sure because if this did get added (and extended to the webinar platform!) it would solve a problem of mine.

The problem in my instance is two fold. I have one team that starts a meeting and will sometimes hop off to start a second an hour in while the rest of the users continue to work on the project (if the person who schedules the meeting starts another meeting, it will end the first meeting as it is using their license. If you could pass host and it actually changed the license being used this wouldn't be an issue). The second instance is that we have a team of recruiters who schedules interviews for prospects. Part of our interview process in a panel interview (the panel is not always the same people), and we often do not know exactly who will be on the panel until the day of the interview (at which point it is already scheduled with the prospect), so the recruiters use their meeting licenses for these meetings and need to be able to also schedule meetings for themselves during this same time period. "Join before host" does not allow for concurrent meetings....it lets people join the meeting lobby before the host. Even using the schedule on behalf of feature is not always a solution.

Ditto -- we have day-long meetings to manage deployment activities with teams (that may be in and out throughout the day), but then the Host of that day-long meeting also has several one-hour meetings throughout the day that they need to start/join, in and out. Whenever they start one of their hour-long meetings, it needs to terminate the full-day meeting.

I realize the day-long meeting with people dropping in and dropping out probably does not meet the standard use-case/definition of "a meeting", but it's how we use it.

As a User i want to host back to back conferences without risking of mixing different groups hence would be necessary to have more than 1 host code per User. For example as a user i want to set up a conference with client A from 10 to 11 and with client B from 11 to 12 whereby I want to be able to open the conference with client B 5 minutes before 11 and allow for the first call with client A to overrun for 5 minutes.

This probably doesn't meet your need @davide but what I can tell you is that if you don't use host codes each generation of RingCentral meetings is a unique meeting code when you schedule it. If you utilize the 'join before host' the guests get a lobby to wait in until the host joins. Not ideal but it would at least allow your use, just guests wont be able to chat until the host joins, sadly.