Як створити клієнтський портал: файли, статуси, рахунки та права доступу

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

Навіщо бізнесу клієнтські портали

Портали зазвичай замінюють купу листів, спільних папок і повідомлень «який статус?». Агентства, бухгалтери, консультанти, будівельники, студії та сервісні компанії використовують їх усі. Хороший портал:

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

Якщо у вас один-два клієнти і немає нічого конфіденційного, можна обійтися спільним документом або папкою. Портал варто створювати, коли клієнтів багато, робота повторюється або клієнти не повинні бачити інформацію один про одного.

Що потрібно клієнтському порталу

Почніть із входу, огляду, файлів і запитів. Додавайте рахунки, погодження й повідомлення, коли клієнтам це справді потрібно.

Дані

Типовий портал має: клієнтів (компанії), користувачів клієнтів (люди, які входять і належать одному клієнту), членів вашої команди, проєкти (належать одному клієнту), етапи або оновлення статусу, файли (належать проєкту), запити і, за бажанням, рахунки. Ключове правило проєктування: кожен запис має відноситися рівно до одного клієнта. Тоді права доступу легко забезпечити й перевірити.

Права доступу

Запишіть їх і перевірте:

• Користувач клієнта бачить лише проєкти, файли, запити та рахунки свого клієнта.
• Внутрішні нотатки ніколи не показуються клієнтам.
• Члени команди бачать клієнтів, яких їм призначено, або всіх клієнтів, якщо ви невеликі.
• Посилання на файли приватні й обмежені в часі, а не публічні URL, якими можна було б поділитися або які можна вгадати.
• Видалення користувача клієнта одразу скасовує його доступ.

Перевірки мають відбуватися на сервері. Портал, який завантажує дані всіх клієнтів і фільтрує їх у браузері, не є приватним.

Рішення та компроміси

Спосіб входу

Клієнти рідко входять, тому часто забувають паролі. Магічні посилання (посилання для входу, надіслане електронною поштою) або єдиний вхід через обліковий запис, який у них уже є, часто працюють для порталів краще за паролі. Який би варіант ви не обрали, запрошуйте клієнтів з вашого боку, а не дозволяйте будь-кому реєструватися. Наш посібник як додати вхід до застосунку порівнює варіанти.

Один портал чи окремий для кожного клієнта

Один застосунок зі списком клієнтів легше підтримувати, ніж окремий сайт для кожного клієнта. Водночас ви можете дати кожному клієнту власний брендований вигляд — їхній логотип, назви їхніх проєктів — в межах того самого застосунку.

Файли

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

Рахунки та платежі

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

Інтеграції

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

Перший промпт для конструктора на базі ШІ

Створи клієнтський портал для Northlight, невеликого агентства веб-дизайну. Клієнти — це компанії; у кожного є один або більше користувачів, які входять. Користувачі клієнта бачать лише проєкти своєї компанії. Для кожного проєкту: поточний статус (Discovery, Design, Build, Review, Live), наступний етап із датою, область файлів, куди обидві сторони можуть завантажувати й звідки можна завантажувати (PDF, зображення, ZIP, максимум 50 МБ), форма запиту (назва, деталі, пріоритет) зі списком їхніх минулих запитів і статусом, а також хронологія оновлень. Співробітники агентства бачать адміністративну область зі всіма клієнтами, можуть змінювати статус проєкту, публікувати оновлення, додавати внутрішні нотатки, які клієнти ніколи не бачать, і відповідати на запити. Забезпечуй усі правила доступу на сервері. Зберігай дані в базі даних, а файли в приватному файловому сховищі з посиланнями на завантаження, обмеженими в часі. Поки що заглушка входу — справжню автентифікацію додамо далі. Чистий, професійний дизайн, який працює на телефонах.

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

Кроки побудови

1. Спершу складіть список того, що клієнт має бачити, і про що вони зараз вам пишуть листи.
2. Спроєктуйте дані так, щоб кожен запис належав одному клієнту.
3. Створіть адміністративний вигляд і внесіть дані одного справжнього клієнта.
4. Створіть вигляд для клієнта для цього клієнта.
5. Додайте справжній вхід із запрошеннями з вашого боку.
6. Додайте файли в приватному сховищі з перевіркою прав під час завантаження.
7. Перевірте права доступу: створіть двох тестових клієнтів і спробуйте всіма способами побачити дані іншого — змінюючи ID в URL, вгадуючи посилання на файли, використовуючи старе запрошення.
8. Додайте запити та сповіщення електронною поштою.
9. Проведіть пілот з одним-двома доброзичливими клієнтами і запитайте, про що вони досі вам пишуть.
10. Додайте рахунки, погодження або інтеграції на основі цього відгуку.

Типові помилки

• Фільтрація в браузері замість сервера. Найсерйозніша помилка порталу: дані всіх клієнтів завантажуються, просто приховані.
• Публічні URL файлів. Спільне посилання, яке може відкрити будь-хто, нівелює портал.
• Відкрита реєстрація. Клієнти мають запрошуватися, а не створювати власні облікові записи та самі обирати компанію.
• Забагато функцій на старті. Портал, який клієнти не розуміють, ігнорують на користь електронної пошти.
• Два джерела правди. Якщо статус живе в інструменті для проєктів і в порталі, один із них застаріє. Оберіть один або синхронізуйте їх.
• Забуте відключення. Коли співробітник клієнта звільняється, його доступ має припинитися.
• Зберігання регульованих даних без належного захисту. Медичні, юридичні чи фінансові записи можуть мати вимоги закону, яким потрібно відповідати.

Витрати й інструменти

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

Коли краще готовий продукт

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

Створення в Mythex

Mythex може створити портал за промптом вище: вигляд для клієнта, адміністративний вигляд, запити та хронологію з окремою базою даних Postgres і файловим сховищем, які додаються, коли застосунку це потрібно. Вхід для клієнтів — за вашим вибором: облікові записи Mythex призначені для людей, які створюють застосунок, а підхід до автентифікації для ваших клієнтів ви обираєте, а агент його підключає. У Mythex немає вбудованого електронного підпису чи продукту для виставлення рахунків, тож це інтеграції або функції, які ви створюєте самі. Для будь-яких ключів API використовуйте секрети проєкту, а перед публікацією пройдіться клієнтськими та адміністративними сценаріями за допомогою вбудованого тестувальника в чаті.

Документація містить сценарій клієнтського порталу, а також описує файлове сховище і додавання входу. Як стартовий запит спробуйте шаблон клієнтського порталу для агентства або перегляньте шаблони застосунків. Перш ніж запрошувати справжніх клієнтів, пройдіть наш контрольний список безпеки для застосунків, створених за допомогою ШІ.

Запитання