LOBBY
Office Management· 9 min read

Meeting Room Naming Conventions: A System That Survives an Office Move

Display name, mailbox alias and SMTP address are three different things, and most offices only think about one of them. A naming system for Microsoft 365 and Google Workspace that still works after you move floors.

An office we know moved from one floor to two. It took about ninety minutes. What took the next four months was the room names. They had eleven rooms named after Dutch cities, which everyone loved, and which contained exactly zero information about where any of them were. New starters booked Rotterdam on the third floor and walked to the first. The office manager printed paper signs. Someone renamed three of the rooms in the admin console, which fixed the signs and broke every recurring booking that referenced the old display name in its location field.

This post is about the naming system, not the names. If you are here for a list of good room names, we have that separately in meeting room name ideas, and you should go there instead. What follows is the part that IT owns: how display name, mailbox alias and SMTP address differ, what actually drives sorting and grouping in Outlook Room Finder and Google Calendar, what goes in the name versus in metadata, and how to rename a room without leaving wreckage.

A room has three names, and they are not interchangeable

Every room resource carries at least three identifiers that people conflate constantly:

  1. Display name. What humans see in the address book, the meeting invite, and on the wall display. In Exchange, the room name is capped at 64 characters. Google suggests keeping the resource name to 45 characters or fewer.
  2. Alias. The bit to the left of the @ in the mailbox address. Changing an alias in Exchange updates the primary email address automatically if the mailbox is subject to email address policies, which is a bigger side effect than most people expect.
  3. SMTP address. The address that actually receives meeting requests. In Google Workspace the resource email is read-only and generated when the resource is created, so it does not follow renames at all.

The important consequence: the display name is the only one of the three you can change freely. The other two are identity. Design your convention so that the human-readable part carries all the information that changes (floor, capacity, equipment) and the machine part carries none of it.

Why "Amsterdam" alone breaks things

Pure theme names fail for three specific mechanical reasons, not for aesthetic ones.

Address book sorting is alphabetical on display name

Users pick rooms from a list sorted by display name. If the names are Amsterdam, Delft, Rotterdam, Utrecht, then the second floor rooms are interleaved with the fourth floor rooms in a sequence that carries no spatial meaning. Nobody scanning that list can filter by "rooms near me" because the sort key contains no location.

Room Finder groups by room list, not by anything in the name

In Outlook, Room Finder shows room lists as the values in the Building filter. It does not read the Building property you may have set on the room. If your rooms are not in a room list, Room Finder shows nothing at all, which is the single most common cause of the "no rooms in Room Finder" complaint. The names cannot rescue you here. See Outlook Room Finder not showing rooms and room lists in Exchange Online for that half of the problem.

Google builds hierarchy out of hyphens

Google Calendar auto-creates a resource hierarchy once you have more than 10 resources whose names contain a hyphen, and splits a header group into subheaders once it exceeds 100 resources. A flat set of city names gives the client nothing to group on.

The convention

Use a structured prefix plus a human name. The prefix is machine-friendly and sorts correctly. The human name is what people say out loud.

[SITE]-[FLOOR]-[NAME]

CPH-02-Amsterdam
CPH-02-Rotterdam
CPH-04-Utrecht
BER-01-Kreuzberg

Two rules make this survive a move:

  • Site codes are three letters and permanent. Use IATA city codes if you have offices in more than one city. They will never need renaming.
  • Floor is zero-padded to two digits. Otherwise floor 10 sorts between floor 1 and floor 2. This is the single most common defect in real deployments.

Google's own suggested format for legacy resources is close to this: [city abbrev]-[building]-[floor] [room name] ([room capacity]) [Audio and video features], with the worked example NYC-14-12-Boardroom (15) VC.

Capacity and equipment: in the name or in metadata?

Both, but you should not type either one by hand.

Put capacity and features in metadata, and let the platform render them into the name. In Google Workspace that is exactly what structured resources do: you fill in building, floor, capacity and features, and Calendar generates a read-only name such as SF-MAIN-Beehive Room (4) [VC] or ZRH-OfficeA-1-FavoriteRoom (4) [Phone, VC]. The autogenerated name regenerates whenever any resource field other than the resource name, resource type or description is updated. Capacity changes from 4 to 6 and the name follows on its own.

Microsoft 365 does not autogenerate names, so you have a choice. Microsoft's own guidance leans toward summarising the important details in the name using a consistent convention, because users see the name in the address book. The counter-argument is that hand-typed capacity in a display name goes stale the moment someone adds two chairs. Our recommendation: put capacity in the name only if you also commit to a quarterly audit script, and put it in Set-Place metadata regardless, because Room Finder filters on the metadata.

Set-Place -Identity cph-02-amsterdam@contoso.com `
  -Building "Copenhagen HQ" `
  -Floor 2 `
  -FloorLabel "Second" `
  -City "Copenhagen" `
  -CountryOrRegion DK `
  -Capacity 8 `
  -Tags "Whiteboard","VC","Wheelchair accessible"

Microsoft is explicit that Room Finder needs City, Floor and Capacity configured to work properly, and that Tags populate the Features filter. Skipping the metadata to save time is how you end up with a Room Finder that cannot filter anything.

Google Workspace: the fields that matter

In the Directory API, a calendar resource carries resourceName, buildingId, floorName, floorSection, capacity, resourceCategory and the read-only generatedResourceName. Set resourceCategory to CONFERENCE_ROOM for anything bookable as a meeting space. Legacy resources sit at CATEGORY_UNKNOWN, which is the flag that tells you a room has never been converted to the structured format.

GET https://admin.googleapis.com/admin/directory/v1/customer/my_customer/resources/calendars

Anything in that response with "resourceCategory": "CATEGORY_UNKNOWN" is a room that will not group or filter correctly. That is your migration backlog.

Keep floor names short. Google suggests a maximum of 15 characters for floor name and floor section, and the floor name must match a floor already defined on the building.

Room list membership is part of the naming system

A convention that does not also govern room list membership is only half a system. The standard pattern is one room list per building, with the room list named after the building rather than after a floor or a team.

New-DistributionGroup -Name "Copenhagen HQ" -RoomList -Alias CopenhagenHQ

Add-DistributionGroupMember -Identity "Copenhagen HQ" -Member cph-02-amsterdam@contoso.com

Two limits worth knowing before you design around this. Room Finder returns at most 100 rooms and workspaces in a search, and Microsoft recommends capping each room list at 50 to keep it responsive. If a single building genuinely has more than 50 bookable rooms, split by floor range and name the lists accordingly (Copenhagen HQ Floors 1 to 3). Also, every room in a room list should be in the same city, because a mixed-city list only appears when you filter for the city where the majority of its rooms sit.

What breaks when you rename a room

This is the part people find out the hard way.

  • Existing bookings keep the old text. The Location field on a meeting is a string that was copied at the time the meeting was created. Renaming the mailbox does not rewrite it. Recurring series booked before the rename will display the old room name indefinitely, in every attendee's calendar.
  • Display name and alias drift apart. Rename the display name only and you now have CPH-04-Utrecht whose address is still cph-02-utrecht@contoso.com. Everything works, and every future admin is confused. Rename both or neither.
  • Changing the alias changes the primary SMTP address if the mailbox is subject to email address policies. Meeting requests sent to the old address still route, because the previous primary is retained as a proxy address, but any external system that stored the old address is now pointing at an alias rather than the primary.
  • Display bindings. Any wall display, dashboard or script that identifies a room by display name rather than by immutable ID will break. Anything bound to the SMTP address or resource ID will not.
  • Propagation is slow. Microsoft states that room list and place changes take 24 to 48 hours to appear in Room Finder. Do not rename on a Friday and judge it on Friday afternoon.

How to rename safely

The order matters. Change the address first, keep the old one as a proxy, then change the display name.

Set-Mailbox -Identity cph-02-utrecht@contoso.com `
  -DisplayName "CPH-04-Utrecht" `
  -EmailAddresses SMTP:cph-04-utrecht@contoso.com,smtp:cph-02-utrecht@contoso.com `
  -ResourceCapacity 6

Set-Place -Identity cph-04-utrecht@contoso.com -Floor 4 -FloorLabel "Fourth"

Note the capitalisation: uppercase SMTP: marks the primary address, lowercase smtp: marks a proxy. Keeping the old address as a proxy is what stops in-flight meeting requests from bouncing.

For a bulk rename driven from a CSV of old address, new address and new display name:

Import-Csv .\room-renames.csv | ForEach-Object {
  Set-Mailbox -Identity $_.OldAddress `
    -DisplayName $_.NewDisplayName `
    -EmailAddresses "SMTP:$($_.NewAddress)","smtp:$($_.OldAddress)"
}

Auditing inconsistent names

Run this before you design the convention, not after. It shows you every room where the display name and the alias have already diverged, plus the metadata gaps:

Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
  ForEach-Object {
    $place = Get-Place -Identity $_.PrimarySmtpAddress
    [PSCustomObject]@{
      DisplayName = $_.DisplayName
      Alias       = $_.Alias
      Address     = $_.PrimarySmtpAddress
      HiddenFromGAL = $_.HiddenFromAddressListsEnabled
      City        = $place.City
      Floor       = $place.Floor
      Capacity    = $place.Capacity
    }
  } | Export-Csv .\room-name-audit.csv -NoTypeInformation

Sort the CSV by DisplayName. Anything where the alias does not obviously derive from the display name is a room that has been renamed once already. Anything with a blank City, Floor or Capacity will not filter in Room Finder. Anything with HiddenFromGAL set to true will not appear at all, no matter how good the name is.

A convention that survives the next move

Three properties make the difference:

  1. Nothing in the immutable part of the identity (alias, SMTP address) encodes anything physical. If the address is room-utrecht@ rather than cph-02-utrecht@, a floor change is a display name edit and nothing else.
  2. Everything physical lives in metadata that the platform renders. Google does this for you. In Microsoft 365 you do it with Set-Place and accept that the display name is a cached copy.
  3. Room list membership is reviewed on the same schedule as the names. A perfectly named room that belongs to no list is invisible in Room Finder.

If you are starting from scratch, our Google Workspace room resources IT checklist covers the field-by-field setup on that side.

The buy side of this decision

None of this needs a product. It is PowerShell, the Google admin console, and a spreadsheet, and for an office with 5 to 15 rooms it is an afternoon of work that you will not repeat for years.

Where the naming work pays off visibly is on the wall. Lobby reads the room resource directly from Microsoft 365 or Google Calendar and shows the current name, so a rename done properly propagates to the screen without anyone printing anything. It comes as a physical e-ink display on 7.5-inch e-ink hardware, as a virtual display that is just a URL in a browser tab, or as a room overview board listing every room on one screen for a reception area.

The hardware is bought direct from the manufacturer and we take no markup on it. E-ink displays start at USD 69 per device, dropping to USD 62.99 at 10 or more, before tax, duties and shipping. Buy once, own it, hangs on one screw, 3 to 6 month battery.

On the software side, Free is free forever for up to 3 active displays with 15-minute e-ink updates and no credit card. It is not a trial. Unlimited is USD 30 per month billed yearly, which is USD 360 a year, or USD 50 per month if you pay month to month, for unlimited rooms and displays. Pro Unlimited is USD 60 per month billed yearly, USD 720 a year, or USD 100 per month month to month, and adds 5-minute e-ink updates, custom templates, your own logo with Lobby branding removed, room feedback with free QR stickers, a Slack /book command, priority support, Lobby-hosted e-ink screens rendered and served in the EU, Active hours and Smart Updates. Yearly billing saves 40 percent and there is no annual contract lock-in.

What it will not do for you: it does not rename rooms, it does not manage room lists, and it does not fix metadata. The rooms product also does not do desk booking or visitor management, and there is no AV control, no occupancy sensing, or enterprise SSO and SCIM at scale, there is no MDM on the e-ink hardware, and on-premises Exchange requires hybrid. If your naming is a mess, a display makes the mess legible from five metres away, which is useful but is not the same as solving it. Lobby is made by Vikba ApS in Denmark and is not affiliated with Microsoft or Google.

If you want the convention you have just designed to show up on the door as well as in the admin console, that is what Google Calendar room displays are for.

TL;DR

  • Display name, alias and SMTP address are three separate things. Only the display name is safe to change casually.
  • Keep physical facts (floor, capacity) out of the address. Put them in the display name and in metadata, and treat the display name as a cache.
  • Use [SITE]-[FLOOR]-[NAME] with a permanent three letter site code and a zero-padded floor number, so floor 10 does not sort between 1 and 2.
  • Google generates room names from structured fields automatically. Microsoft 365 does not, so you maintain the name and Set-Place metadata separately.
  • Room Finder groups by room list, not by the Building property. Cap room lists at about 50 rooms and keep one city per list.
  • Renaming does not rewrite the Location field on existing bookings. Keep the old SMTP address as a proxy, and allow 24 to 48 hours for Room Finder to catch up.

Related reading

Sources

Try Lobby — free forever up to 3 displays

Room booking that just works.

Get started →