QR-коди для клієнтських проєктів, розділені навмисно

01

Простір на клієнта, теки на проєкт

Простір — це одиниця поділу: у нього власні учасники, коди, теки, теги, матеріали, шаблони, налаштування аналітики й власний домен, а перемикаєтесь між ними з бічної панелі. Клієнт не бачить простору, в якому його немає, і це властивість структури, а не чиєїсь пам’яті.

Усередині простору код лежить рівно в одній теці й несе скільки завгодно тегів. Теки пасують місцям і об’єктам — майданчик, продуктова лінійка, хвиля кампанії — і вкладаються так глибоко, як того вимагає робота. Теги пасують тому, що перетинає теки, а це зазвичай сама кампанія.

• Один простір на клієнта, перемикається з бічної панелі
• Теки для місць і об’єктів; код лежить в одній за раз
• Теги для кампаній, що перетинають теки; кодів може мати кілька
• Матеріали, стікери й шаблони належать простору, а не вам

02

Дайте кожному рівно той доступ, якого вимагають стосунки

Ролі видаються в межах простору і діють на кожен код у ньому: адміністратор, редактор, аналітик і глядач, поруч із власником. Налаштування показують матрицю прямо: хто може створювати й редагувати коди, дивитися аналітику, керувати теками й тегами, запрошувати учасників, експортувати дані та видалити простір.

На практиці це означає, що контактна особа клієнта може бути аналітиком і читати кожну цифру, не торкаючись графіки, а стейкхолдер може бути глядачем, який бачить роботу й нічого не змінює. Експорт даних можна звузити до самого власника, а простір — налаштувати так, щоб він вимагав двофакторної автентифікації від усіх у ньому.

03

Покажіть роботу до того, як вона дійде до друкарні

Посилання для перегляду ставить код перед людиною, у якої акаунта немає взагалі: право дивитися, необов’язковий пароль, дата згасання і можливість відкликати тієї ж миті, коли рев’ю скінчилось. Це чесна альтернатива надсиланню скриншота, який за годину перестає відповідати коду.

Усередині простору коментарі живуть на самому коді, а погодження подається до конкретної ревізії з нотаткою і вирішується тим, хто має право. Це перетворює «яку версію вони затвердили» зі суперечки про ланцюжок листів на запис із датою.

04

Не будуйте нічого заново на початку кожної кампанії

Шаблони зберігаються як редагована сцена, а не як зведене зображення, тож макет клієнта лишається придатним до правок і через рік, замість бути картинкою, яку комусь доведеться перемальовувати. Бібліотека матеріалів і стікери тримають їхні логотипи й знаки в тому просторі, якому вони належать.

Кожен код зберігає свої ревізії, тож зміну, зроблену поспіхом, можна прочитати назад: чим вона була, чим стала і хто її зробив.

05

Обсяг — і як дістати цифри назад

Наклад у сотні належить до CSV-завдання або публічного API з ключем обмеженої області, а не до вечора клікання. Вебхуки штовхають події в те, звідки агенція вже звітує, а дані сканувань експортуються у CSV по кожному коду.

Одне правило вирішує, чи вартий той звіт бодай чогось: аналітика розділяє те, що розділили ви. Дайте кожній точці друку, кожній версії й кожному місту власний код — інакше звіт клієнта згорнеться в одну цифру, яка не відповідає на жодне з його питань.

06

Домовтеся до друку, чий акаунт володіє редиректом

Динамічний код резолвиться через простір, якому належить. Якщо клієнт іде, а простір лишається у вас, його друкований матеріал тепер залежить від вашого акаунта; якщо простір іде з ним, ваша звітність закінчується того ж дня, що й стосунки. Жоден із варіантів не є хибним. Хибно не розуміти, який саме ви обрали.

Дві речі знижують ставки. Підтверджений власний домен означає, що надрукована адреса належить клієнту, тож коди можуть пережити будь-який окремий інструмент. І умови виходу варто знати заздалегідь: простір, поставлений на видалення, віддає на своїх живих посиланнях контрольовану сторінку «недоступно», а не кидає сканування в нікуди — і це наслідок, який планують, а не виявляють.