Что нового в продукте

Откройте расписание любой загруженной переговорной — и, скорее всего, увидите столбик фамилий. Когда сотрудник бронирует комнату и не заполняет название, UnSpot подставляет вместо него имя организатора, а если встречу создали прямо на дисплее у двери — «Room Display». Комната занята, но чем и насколько это важно, не понятно ни коллегам, ни офис-менеджеру, ни тому, кто стоит у двери с вопросом «можно я на пять минут?».

Что появилось

В правилах бронирования переговорной появилась политика «Требовать название встречи» — «Название встречи обязательно для всех бронирований в переговорной». Её включает администратор на странице конкретной комнаты, в окне «Правила бронирования». По умолчанию политика выключена, и для комнат, где её не трогали, ничего не меняется.

Когда политика включена, встречу в этой переговорной нельзя создать или сохранить без названия. Имя организатора и «Room Display» больше не подставляются: тему встречи вводит сам автор брони. Правило работает везде, где создаются и редактируются встречи, — и в интерфейсе UnSpot, и на дисплее переговорной — и действует на все роли, включая администратора.

А как же быстрое бронирование

Быстрое бронирование для такой комнаты не потеряется. Вместо мгновенного создания встречи откроется полная форма, куда уже перенесено всё, что человек выбрал, — останется дописать название. Лишних шагов ровно один, и он про суть встречи.

Что это даёт

Расписание переговорной снова читается как повестка: видно, где созвон с клиентом, где планёрка, а где собеседование. Дисплей у двери показывает тему встречи — проще понять, можно ли заглянуть или лучше подождать. Офис-менеджеру легче договориться о переносе, если он видит, что именно переносит, а не только чья это бронь.

Политика настраивается для каждой комнаты отдельно. Её разумно включить там, где расписание видят многие: в больших переговорных, в комнатах для встреч с клиентами, у переговорных с дисплеями. Маленькие комнаты для коротких созвонов можно оставить как есть.

У многих компаний несколько офисов, а данные о проходах собирает одна система контроля доступа: общий сервер СКУД на все здания или одна интеграция на весь город. Раньше UnSpot в такой схеме знал, что сотрудник пришёл на работу, но не знал, куда именно. Из-за этого искажалась аналитика по данным СКУД: вы выбирали конкретный офис, а в расчёт посещений попадали проходы во все здания сразу.

Точка доступа подсказывает офис

Каждое событие СКУД приходит с названием точки доступа — турникета, проходной, двери на этаже. Теперь в настройках входящих подписок в форматах JSON и Sigur есть блок «Связь офиса с точкой доступа СКУД»: администратор выбирает офис и перечисляет его точки доступа. По этой связи UnSpot определяет, в какой офис пришёл сотрудник, и сохраняет офис вместе с событием — он виден в отчёте «История посещения офиса (СКУД)».

Офисов в подписке может быть сколько угодно, точек доступа у каждого — до ста. Одна и та же точка не может принадлежать двум офисам, поэтому путаницы не будет. Если событие пришло с точки, которой нет в списке, оно всё равно сохранится — просто без офиса.

Фильтр по офису теперь учитывает проходы

Фильтр по офису в разделах «По офисам» и «По местам» теперь применяется не только к рабочим местам, но и к самим проходам. Выбрали петербургский офис — видите приходы именно в него, а не во все здания компании. Если офис не выбран, графики строятся так же, как раньше.

При загрузке данных СКУД из файла (кнопка «Загрузить данные СКУД» в разделе «По офисам») офис определяется так же: для формата UnSpot — по колонке с названием офиса, для выгрузок Sigur, RusGuard, PERCo и Bolid — по точке доступа.

Как начать

Связь настраивается в разделе «Интеграции → Входящие подписки»: откройте действующую подписку или создайте новую, добавьте офисы кнопкой «Добавить офис» и укажите точки доступа так, как они названы в системе контроля доступа. С этого момента новые события будут привязываться к офисам.

Что это даёт

В аналитике видна реальная посещаемость каждой площадки, а не общая картина по компании. Офисы можно сравнивать между собой, видеть, какой из них недогружен, а в каком не хватает мест, и решать вопросы аренды и рассадки по фактическим цифрам — даже если на все здания у вас одна система контроля доступа.

Переговорная с замком на двери — вечный компромисс. Если дверь открывается картой любого сотрудника, комнату займут без брони, и тем, кто её честно забронировал, придётся искать другое место. Если держать ключ на ресепшене или вручную вести списки доступа в СКУД, это лишняя работа для офис-менеджера и очередь за ключом перед каждой встречей.

Дверь открывает бронь

Если в офисе работает СКУД Sigur, UnSpot теперь сам решает, кого пускать в переговорную, — по её расписанию. Раньше делегирование доступа работало только для рабочих мест. Теперь оно работает и для переговорных: сотрудник прикладывает карту к считывателю у двери, Sigur спрашивает UnSpot, и дверь открывается, если человек — организатор или участник встречи, которая идёт в этой комнате прямо сейчас.

Кому нужно войти без встречи

В переговорную заходят не только участники совещаний. Поэтому в блоке «Правила доступа в переговорную для пользователей» на странице комнаты можно выбрать до трёх групп пользователей — у каждой своё условие:

• когда переговорная свободна — нет текущего бронирования;
• когда переговорная занята — идёт встреча;
• в любое время — независимо от расписания.

Группы необязательны. Если не выбрать ни одной, в комнату попадут только участники текущей встречи.

Как включить

Администратор открывает редактирование переговорной, в блоке правил доступа нажимает «Изменить настройки», указывает «ID точки доступа СКУД» — идентификатор двери комнаты в Sigur — и при необходимости выбирает группы. Само делегирование решения о доступе от СКУД в UnSpot включается в разделе «Настройки API». Для комнат без указанной точки доступа ничего не меняется.

Что это даёт

Доступ в переговорные больше не нужно поддерживать отдельно: он следует за расписанием. Забронировал встречу, добавил коллег — и в назначенное время дверь откроется всем участникам, без ключей и заявок. А занять комнату в обход брони не получится, если вы сами не разрешили это нужной группе. Правила задаются для каждой переговорной отдельно, так что комнаты на разных этажах можно настроить по-разному.

В любой достаточно большой компании имена в системах и имена в жизни — это два разных набора. В каталоге человек записан как «Иванова Мария Сергеевна», в жизни она Маша. В корпоративной почте кто-то значится транслитом. В отделе два Александра Петрова, и различить их можно только по табельному номеру, которого никто не помнит.

UnSpot до сих пор показывал то, что пришло из справочника: имя и фамилию. На карте офиса, на дисплеях у переговорных, в списке «Кто в офисе» — везде.

Поле «Отображаемое имя»

У сотрудника появилось отдельное поле — «Отображаемое имя». Если оно заполнено, интерфейс показывает именно его: на страницах «Сотрудники» и «Дисплеи», в подсказках на карте офиса, в переговорных и локерах, в сайдбаре «Кто в офисе», в карточке пользователя и на экранах у переговорных.

Если поле пустое, всё выглядит как раньше — имя и фамилия. Ничего настраивать не нужно, чтобы оставить как было.

Зачем это офису

Первое — узнаваемость. Бронь на карте подписана так, как человека зовут коллеги, а не так, как его завели в кадровой системе. Это звучит мелочью ровно до момента, когда вы ищете свободное место рядом с конкретным человеком.

Второе — тёзки. Два Александра Петрова превращаются в «Саша Петров (маркетинг)» и «Александр Петров», и вопрос «а это который?» отпадает.

Третье — дисплеи. На экране у переговорной имя видно издалека и мельком: три слова с отчеством читаются хуже, чем два привычных.

Поиск тоже это учитывает

Отображаемое имя участвует в поиске по сотрудникам и в глобальном поиске наравне с остальными полями. Коллегу можно найти по тому имени, которым вы его называете, а не по официальному.

Заполнять поле вручную у всей компании не нужно: его можно синхронизировать из корпоративного каталога вместе с остальными данными сотрудника.

Мелочь, которую замечают все

Отображаемое имя — из тех изменений, которые не попадают в презентации, но на которые обращают внимание в первый же день. Человек открывает карту офиса и видит команду такой, какой он её знает: не выгрузку из кадровой системы, а коллег.

Ограничение одно — 255 символов, чего хватает на любую разумную форму имени. А при удалении персональных данных сотрудника поле очищается вместе с именем и фамилией, отдельно за ним следить не нужно.

Локер — это личные вещи: спортивная форма, лекарства, зарядки, подарок, который не хочется нести домой через весь город. И одновременно это объект в системе бронирования, где по умолчанию видно, кто именно его занял.

В открытом офисе это заметнее, чем кажется. Видно, кто держит ячейку месяцами, кто занял вторую, кто вообще ничего не бронирует. Ничего страшного в этом нет — но внимание к таким деталям появляется само, и человеку становится неуютно.

Настройка «Личные бронирования»

У локеров появилась собственная настройка приватности. Она включается в правилах бронирования конкретного локера и по умолчанию выключена: действующие локеры продолжают работать как раньше.

Когда приватность включена, картина меняется ровно в одном месте. Занятые ячейки по-прежнему видны как занятые — планировать по локеру можно так же, как раньше. А вот имя и аватар владельца скрываются: в подсказке показывается, что ячейка занята, без указания, кем.

Важное исключение: свои бронирования сотрудник видит всегда, а руководитель — бронирования своих подчинённых. Приватность закрывает посторонний взгляд, а не управленческий.

Настраивается по одному локеру

Приватность задаётся не на всю компанию, а на конкретный локер, и это существенно. Локер в переговорной зоне на входе и локер в раздевалке — разные истории: в первом случае прозрачность помогает, во втором мешает.

Локеры с включённой приватностью помечены отдельным индикатором в списке пространств, так что администратору не нужно заходить в каждый, чтобы понять, где режим включён.

Тот же принцип, что и у мест

Если формулировка кажется знакомой — так и есть. Точно так же в UnSpot уже устроены личные бронирования столов и переговорных: занятость публична, персональные данные — нет.

Локеры были единственным ресурсом, который из этого правила выпадал. Теперь не выпадают.

Когда это решает вопрос внедрения

Приватность локеров чаще всего всплывает не как пожелание сотрудников, а как возражение на этапе запуска: «а это точно нормально, что все видят, кто чем пользуется?» Раньше на этот вопрос отвечать было нечем.

Теперь ответ есть, и он не требует отказываться от учёта: компания по-прежнему видит загрузку локеров в аналитике и знает, сколько ячеек занято и сколько свободно. Скрывается ровно одно — чужое имя на чужой ячейке.