A client asks where the conversations they have with you are held. You can name a supplier, or you can name a machine your own team runs, and which of those you get to say was decided long before anyone asked, by choices made once and then lived with for years.
Where the platform runs
The options are a shared service that a supplier operates, or a deployment your own team stands up and runs. This choice sets the region the servers sit in, the laws that reach the data, whose other customers share the same system, and who can be asked to produce records. RoomHex is the second kind: the machines are yours and the domain is yours.
How an account comes to exist
Either anyone who reaches the address creates a login, or an administrator provisions each account after a review. The choice decides the population of the deployment: everyone who found their way in, or everyone somebody approved. RoomHex takes the second route.
Who holds the host role
Someone in each meeting approves arrivals waiting in the lobby and operates the restricted controls. Organisations either hand that role to whoever created the calendar entry, or to the person accountable for the subject under discussion. The second choice takes a moment when the invitation is written and decides who is answerable if the wrong person is admitted. Everyone else joins as a presenter or a guest, and a guest cannot open the host controls at any point in the session.
The host is fixed when the meeting is created, so write that choice into wherever your invitation template lives.
Taking access away
Removal happens at two levels, and they answer different problems. A host or administrator can remove a participant from a running session, which closes the session for that person while it continues for everyone else. Removing the account itself is a separate action and is what an administrator does when a person leaves the organisation. Decide which roles hold each power and how quickly they can use it.
- A live incident needs someone in the room holding the host role, since the removal happens inside the session.
- A departure needs the account action, because one removal from a call leaves the account working.
- Name the responders in advance, since response time depends on who is available at that hour.
Administration across sites
An organisation working from several locations picks how much each site administers for itself. A single deployment covers all of them, and how far a branch runs on its own is something you set. The decision is which policies are written once for the whole organisation and which each branch sets locally. Central policy keeps behaviour uniform and adds a step whenever a branch needs an exception; local policy moves faster and produces variation you then have to describe. Contacts and schedules sit in the same deployment either way.
Whichever way it goes, write down which settings are central and which are left to the branch.
What the choices cost you later
With a shared service, the meeting history, the schedules, and the account list sit in the supplier system, and leaving means a migration on their terms and their timeline. With a deployment on your own machines, the software keeps running where it is, and the open questions are support and updates. Ask what you would need on day one of a wind-down and check that the current arrangement can produce it.
Standing up the deployment puts the machines, the network boundary, patching, and backups on your team. Reviewed provisioning puts an approval queue on someone's desk. Naming hosts and responders takes a decision before it takes effect, and each of those duties has to sit with a person who has the hours for it.
- self-hosted
- governance