Product updates

Open the schedule of any busy meeting room and you will probably see a column of names. When someone books a room and leaves the title empty, UnSpot fills in the organizer’s name instead, and if the meeting was created right on the display at the door, it says “Room Display”. The room is taken, but nobody can tell what for or how important it is: not colleagues, not the office manager, not the person at the door wondering whether they can borrow it for five minutes.

What’s new

Meeting room booking rules now include a Require meeting title policy: “A meeting title is required for all meeting room bookings”. An administrator turns it on for a specific room, in the Booking rules window on that room’s page. The policy is off by default, so nothing changes for rooms where you leave it alone.

With the policy on, a meeting in that room cannot be created or saved without a title. The organizer’s name and “Room Display” are no longer filled in automatically: the person booking types the topic themselves. The rule applies wherever meetings are created or edited, both in UnSpot and on the meeting room display, and it applies to every role, administrators included.

What about quick booking

Quick booking still works for such a room. Instead of creating the meeting instantly, it opens the full booking form with everything the person already picked filled in, so all that is left is the title. That is one extra step, and it is about what the meeting is for.

What you get

The room schedule reads like an agenda again: you can see which slot is a client call, which is a team meeting and which is an interview. The display at the door shows the topic, so it is easier to decide whether to knock or wait. And an office manager can negotiate a reschedule more easily when they see what they are moving, not just whose booking it is.

The policy is set per room. It makes most sense where many people look at the schedule: large meeting rooms, rooms for client meetings, rooms with displays. Small rooms for quick calls can stay as they are.

Many companies run several offices, but collect entry events through a single access control system: one PACS server for every building, or one integration for the whole city. Until now, in this setup UnSpot knew that an employee had come to work, but not where. That skewed PACS-based analytics: you picked a specific office, and the visits count still included entries to every building at once.

The access point tells the office

Every PACS event arrives with the name of an access point — a turnstile, a lobby gate, a door on a floor. Incoming webhooks in JSON format now have an Office PACS access point mapping block: the administrator picks an office and lists its access points. Using this mapping, UnSpot determines which office the employee entered and stores the office with the event — it shows up in the History of Office Visits (ACS) report.

A webhook can map any number of offices, with up to one hundred access points each. The same access point cannot belong to two offices, so there is no ambiguity. If an event comes from an access point that is not on the list, it is still saved — just without an office.

Office analytics that is really about the office

The office filter in the By office and By desks analytics now applies not only to workplaces, but to the entries themselves. Select your Frankfurt office and you see entries to that office, not to every building the company has. With no office selected, the charts are built exactly as before.

When you load PACS data from a file (the Upload PACS data button in By office), the office is determined the same way: in the UnSpot format it comes from the office name column, in other supported formats — from the access point.

How to start

The mapping lives in Integrations → Incoming webhooks: open an existing webhook or create a new one, add offices with Add office and enter the access points exactly as your PACS names them. From then on, new events are linked to offices.

What you get

Analytics shows the real attendance of each site, not a company-wide picture. You can compare offices, see which one is underused and where desks run short, and make decisions on leases and seating based on actual numbers — even if a single PACS serves all your buildings.

In any sufficiently large company, the names in the systems and the names in real life are two different sets. The directory says “Kathryn E. Whitmore”; everyone calls her Kate. Someone’s corporate account is a transliteration nobody recognises. There are two Alex Petersons in the same department, and the only way to tell them apart is an employee number nobody remembers.

Until now UnSpot showed whatever came from the directory: first name and last name. On the office map, on the displays outside meeting rooms, in the “Who is in the office” list — everywhere.

The Display Name field

Employees now have a field of their own: Display Name. When it is filled in, that is what the interface shows — on the Users and Displays pages, in tooltips on the office map, in meeting rooms and lockers, in the “Who is in the office” sidebar, in the user card and on the screens by the rooms.

When the field is empty, everything looks as it did before — first name and last name. You do not have to configure anything to keep things as they were.

Why an office cares

First, recognition. A booking on the map is labelled the way colleagues actually refer to the person, not the way HR entered them. That sounds minor right up to the moment you are looking for a free desk next to someone specific.

Second, namesakes. Two Alex Petersons become “Alex Peterson (Marketing)” and “Alexander Peterson”, and the “which one?” question disappears.

Third, displays. On a screen outside a meeting room the name is read from a distance and in passing: three words with a middle initial read worse than two familiar ones.

Search understands it too

Display Name takes part in user search and in global search alongside the other fields. You can find a colleague by the name you actually use for them rather than by the official one.

And you do not have to fill the field in by hand for the whole company: it can be synchronised from your corporate directory together with the rest of the employee record.

A small thing everybody notices

Display Name is the kind of change that never makes it into a slide deck but gets noticed on day one. Someone opens the office map and sees the team the way they know it: colleagues rather than an export from a personnel system.

There is one limit — 255 characters, which covers any sensible form of a name. And when an employee’s personal data is deleted, the field is cleared along with the first and last name, so it needs no separate attention.

A locker holds personal things: gym kit, medication, chargers, a present you would rather not carry across town. It is also an object in a booking system where, by default, everyone can see who took it.

In an open-plan office that is more visible than it sounds. You can see who keeps a cell for months, who took a second one, who books nothing at all. There is nothing sinister about it — but attention to those details appears by itself, and people start to feel watched.

The Private bookings setting

Lockers now have a privacy setting of their own. It is switched on in the booking rules of a specific locker and is off by default, so existing lockers keep working as before.

With privacy on, exactly one thing changes. Taken cells are still shown as taken — planning around a locker works just as it did. What is hidden is the owner: the name and avatar disappear, and the tooltip simply says the cell is occupied.

One important exception: employees always see their own bookings, and managers see their team’s. Privacy closes the casual glance, not the managerial one.

Configured per locker

Privacy is set on an individual locker rather than company-wide, and that matters. A locker in the lobby and a locker in the changing room are different stories: in the first, transparency helps; in the second, it gets in the way.

Lockers with privacy enabled are marked with an indicator in the space list, so an administrator does not have to open each one to see where the mode is on.

The same principle as desks and rooms

If the wording feels familiar, it should. Private bookings already work exactly this way for desks and meeting rooms: occupancy is public, personal data is not.

Lockers were the one resource left out of that rule. Not any more.

When it unblocks a rollout

Locker privacy usually comes up not as a wish from employees but as an objection during rollout: “is it really fine that everyone can see who uses what?” Until now there was no good answer.

Now there is one, and it does not mean giving up on measurement: the company still sees locker utilisation in analytics and knows how many cells are taken and how many are free. Exactly one thing is hidden — somebody else’s name on somebody else’s cell.

Ask an office manager how many locker cells are currently taken for no good reason. Most will honestly say they have no idea: finding out means going to look, then matching what you saw against who is assigned where. So nobody finds out — until the first complaint that there is nothing free.

The data was in the system all along. What was missing was a way to learn about it without going into the system on purpose.

Two new locker events

Integrations → Outgoing webhooks now offers two new events, both about storage cells.

Booking canceled fires when a booking is released automatically by the Booking horizon policy. The email goes out on the day of cancellation, so whoever is responsible knows immediately that a cell is free — and can offer it to the person waiting instead of waiting to be asked.

Locker booking exceeds X days covers the opposite case. You set a number of days, and once a day you receive an email listing every cell held longer than that, with a link to each locker so you do not have to search.

Why the second one matters more than it looks

Not everyone switches the booking horizon on. In many companies, automatically cancelling someone’s booking is too blunt: people use lockers differently, and a hard rule punishes the forgetful and the genuinely long-term user alike.

The long-booking subscription solves the same problem more gently. Nothing is cancelled automatically — you simply see where a cell has been sitting untouched. A human decides what to do next: for one person it is a normal working pattern, for another the locker has been occupied since a project that ended last spring.

The recipient is a person, not an address

In both subscriptions the recipient is a UnSpot user rather than an arbitrary mailbox. That looks like a detail right up to the day the responsible person leaves: the emails would keep going nowhere and nobody would notice. Now the subscription is tied to a real person in the system.

Spaces are picked from a list, so one subscription can cover several lockers at once.