Поговорити з АнноюБільшість інструментів для спільних контактів виходить із того, що вся компанія живе в одній екосистемі. Реальність строкатіша. Типова ситуація, яку ми бачимо: компанія працює в Google Workspace, а аутсорсинговий відділ продажів, бухгалтерська фірма чи нещодавно придбана «дочка» — у Microsoft 365 та Outlook. Обом сторонам потрібен той самий список клієнтів — актуальний, у власній адресній книзі, на власних телефонах.
Ані Google, ані Microsoft не вміють цього нативно. А усталені інструменти спільних контактів у цій ніші працюють лише всередині Google: лейбл Google, яким поділилися з іншими користувачами Google. Щойно хоч один отримувач опиняється в Outlook — ви знову розсилаєте CSV-файли поштою.
Rolyio побудований саме навколо цієї прогалини: власник лейбла може бути в Google, а отримувачі — в Outlook, або навпаки. Ось цей сценарій від початку до кінця.
Сценарій
Acme працює в Google Workspace. Їхній менеджер із операцій продажів веде лейбл «Клієнти» в Google Contacts — 400 контактів, які оновлюються щодня. Acme також співпрацює із зовнішньою агенцією продажів, десятеро людей якої сидять у Microsoft 365. Агенції потрібен список клієнтів в Outlook: в автозаповненні пошти, у мобільному застосунку Outlook, на телефонах — коли клієнт телефонує.
Стара відповідь — щотижневий експорт CSV: агенція постійно відставала на тиждень, дублікати накопичувалися з кожним імпортом, а коли співпраця завершувалася, забрати дані назад було неможливо.
Як це працює з Rolyio
Один лейбл, дві екосистеми
Менеджер підключає свій обліковий запис Google на app.rolyio.com; користувачі агенції підключають свої облікові записи Microsoft. Rolyio нативно розмовляє обома мовами:
- На боці Google лейбл — це справжня група контактів Google, та сама, яку ви бачите в contacts.google.com.
- На боці Microsoft еквівалент — категорія Outlook: Rolyio використовує головні категорії разом із призначенням категорій кожному контакту.
Rolyio не створює третього місця, де живуть контакти. Контакти залишаються в кожного провайдера; Rolyio зберігає звʼязки спільного доступу, ролі та рівно стільки стану, скільки треба для коректної синхронізації. (Є один свідомий виняток: знімки видалених спільних контактів зберігаються в Кошику 30 днів, щоб помилки можна було виправити.)
Спільний доступ через кордон екосистем
Менеджер відкриває лейбл «Клієнти», обирає «Керування доступом» і додає десять адрес агенції з роллю «Перегляд». Отримувачі, які вже підключили обліковий запис, активуються одразу; ті, хто ще не входив, відображаються зі статусом в очікуванні й активуються автоматично після першого входу — без жодної координації.
На наступній синхронізації кожен користувач агенції знаходить в Outlook категорію «Клієнти (Shared)» з усіма 400 контактами. Оскільки категорія — нативна конструкція Outlook, контакти зʼявляються скрізь, де є контакти Outlook: на десктопі, у вебі та в мобільній адресній книзі.
Що означає кожна роль між екосистемами
Ролі поводяться однаково незалежно від того, з якого боку «паркану» користувач:
- Перегляд — отримувач одержує контакти; якщо він відредагує якийсь локально, на наступній синхронізації переможе версія власника.
- Редагування — отримувач може додавати контакти до своєї категорії «(Shared)», і вони перетікають назад у лейбл Google власника. Його правки наявних контактів теж синхронізуються назад.
- Може ділитися далі — отримувач може надавати доступ далі, наприклад керівник агенції додає нового співробітника.
Тобто користувач Outlook із правом редагування може додати контакт в Outlook — і той опиниться в групі контактів Google власника. Повна матриця задокументована в статті ролі та права доступу.
Механіка синхронізації: два провайдери, два ритми
Дві екосистеми дають нам різні інструменти, і Rolyio використовує найкраще з доступного на кожному боці:
- Microsoft підтримує сповіщення про зміни через вебхуки Graph, тож зміни з боку Outlook доходять до Rolyio майже в реальному часі.
- Google не має push-механізму для контактів, тож Rolyio опитує API приблизно кожні 60 секунд з інкрементальними токенами синхронізації. Є й кнопка ручної синхронізації — коли зміну треба провести просто зараз.
Між обліковими записами рухаються лише спільні дані — Rolyio ніколи не торкається контактів поза спільними лейблами. Конфлікти розвʼязуються за принципом «останній запис перемагає» з урахуванням ролей, а дедуплікація йде за адресою email: якщо у користувача агенції клієнт уже був збережений в Outlook, спільний доступ не створить дубліката.
Одне чесне обмеження
Microsoft Graph не дозволяє перейменовувати категорії. Тож якщо власник перейменує лейбл на боці Google, зміну не вдасться застосувати до категорії Outlook «на місці» так, як це сталося б для отримувача в Google. Це обмеження платформи, про яке варто знати, а не ризик втрати даних.
Зворотний напрямок теж працює
Усе описане вище так само працює в дзеркальному варіанті: компанія на Microsoft 365 може володіти лейблом (як категорією Outlook) і ділитися ним з отримувачами в Google Workspace чи Gmail, які одержать його як групу контактів Google «(Shared)». Змішані команди — частина отримувачів у Google, частина в Microsoft, на одному лейблі — це звичайний випадок, а не особливий.
Коли співпраця завершується
Саме тут міжекосистемний спільний доступ окупається найбільше. Коли контракт Acme з агенцією закінчується, менеджер прибирає агенцію зі списку доступу до лейбла. На наступній синхронізації спільні контакти зникають з адресних книг Outlook користувачів агенції. Порівняйте з епохою CSV, коли дані просто йшли — назавжди, в чужу поштову скриньку.
Як це налаштувати
Увесь процес займає кілька хвилин: підключіть обліковий запис з кожного боку, запросіть команду, відкрийте лейбл і поділіться ним. Якщо ваша організація розділена між Google і Microsoft — або працює з партнерами, у яких так, — це різниця між «у кожного є якась версія списку» і «у кожного є список».