Корпоративный портал не обязан быть коробкой: свой собирают от трёх дел сотрудников

Внутренний портал компании, или интранет, даёт сотруднику доступ к рабочей информации и действиям. Лента новостей может быть частью портала, но не отвечает на вопрос «как получить доступ к программе и кто решает мою заявку». Для этого нужен законченный путь от вопроса до результата.

В руководстве по планированию SharePoint Microsoft предлагает сначала определить главные задачи аудитории и признаки успеха сайта. Мы предлагаем ограничить первую версию тремя делами: найти инструкцию, подать заявку, увидеть результат. Это рамка пилота, а не универсальный список: у производственной смены и офисной команды он будет разным.

Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.

Соберите повторяющиеся вопросы из почты и чатов, посмотрите, как люди решают их сейчас. Выбирайте действия, которые компания обрабатывает каждый день; отдельному сотруднику справка может понадобиться редко. Если новому сотруднику всё равно приходится писать кадровику, чтобы узнать судьбу заявки, одной формы на портале мало.

Коробка тоже умеет меняться. Битрикс24 описывает роли, базу знаний и маршруты процессов по структуре компании; у коробочной версии есть исходный код. Если ваши действия укладываются в эти возможности, начинать собственную разработку ради другого вида главной страницы нет оснований.

Доработка становится предметом разговора там, где расходятся правила. Например, заявление должно попасть в уже работающую кадровую систему, а заявка на оборудование — в существующую очередь ИТ-службы. Сначала проверьте, можно ли настроить нужную связь в платформе: переносить все данные в новый портал необязательно.

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

У заявки должен быть один источник истины. Если портал показывает «согласовано», а кадровая система хранит «на рассмотрении», сотрудник получает два ответа на один вопрос. На старте договоритесь, где принимается решение, а где его только показывают.

ИИ-агенту можно поручить форму, поиск или отображение статуса. Но он не решает, какая запись главная, кто вправе одобрить заявку и кто исправляет ошибку обмена. Эти решения входят в постановку задачи агенту до написания кода, иначе он заполнит пробелы собственными предположениями.

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

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

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

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

На vibecoding.ru инженер ведёт машину агентов и работает с её внутренней админкой. «Контакты» помогают разобрать входящие обращения, «Ручейки» — увидеть путь от входа до заявки, экраны конвейера — найти этап обработки. Это рабочий инструмент нашего проекта, а не демонстрационный портал сотрудников.

4 октября 2026 мы связали тест для руководителя с «Контактами» и «Ручейками». Ответы и контакт относятся к заявке, источник входа помогает понять, откуда она пришла. Здесь полезен сам принцип: действие снаружи должно оставлять запись для того, кто продолжает работу внутри.

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

На живой странице /open 7 октября 2026 было 7 032 коммита за 98 дней: это счёт основной ветки с 1 июля. Он показывает объём изменений машины. Из него нельзя вывести число внедрённых порталов, скорость работы сотрудников или качество отдельной заявки.

Клиентского портала в этом опыте нет, как нет замера нагрузки от сотен сотрудников. Наш материал помогает составить задачу и приёмку, а соответствие вашей компании проверяет отдельный пилот. Подменять его числом коммитов было бы ошибкой.

Для пилота нужен владелец процесса, который может проверить результат действия. Если HR заказывает форму, а ИТ-служба принимает только внешний вид, заявка может остаться без исполнителя. Принимать её должен тот, кто знает, где и как она действительно обрабатывается.

Рабочее действие может сломаться за пределами красивого экрана. В нашей админке полная ссылка однажды попала в поле короткого имени, а соседняя запись была удалена случайным нажатием. Эти ошибки важнее обсуждения вида формы: они меняют реальные данные.

Проверять надо и продолжение операции. Заявка может сохраниться, но не попасть исполнителю; уведомление может не уйти; повторное нажатие может создать дубль. Для каждого отказа назовите того, кто его заметит, и безопасный способ повторить действие.

Ниже три случая из нашей машины. Два произошли в один день, но относятся к разным операциям: проверке ввода и удалению. Третий — из конвейера публикации; он показывает, как статус создаёт ложное впечатление законченной работы.

Для портала тот же подход превращается в проверяемые условия. «Сотрудник видит свою заявку» недостаточно: попробуйте открыть чужую. «Заявка отправляется» недостаточно: отправьте её повторно и отключите связь с очередью исполнителя.

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

Нужен и план эксплуатации: кто следит за ошибками, обновляет инструкции, отзывает доступ и принимает обращения сотрудников. ИИ-агенты могут менять код, но не становятся дежурной службой компании. Пока эти обязанности никому не назначены, портал не готов к общему запуску.

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

Смотрите на результат: нашёл ли человек актуальный ответ, дошла ли заявка исполнителю, понятен ли статус без сообщения в чат. Записывайте неудачи и обращения за помощью. Нужное сокращение времени и допустимое число ошибок определите до пилота; универсального процента успеха здесь нет.

Если сотрудник всё равно пишет прежнему адресату, выясните причину. Возможно, инструкция устарела или решение не возвращается из кадровой системы. Добавление новостей и опросов это не исправит; следующей задачей должна стать обнаруженная причина, а не новый раздел.

Перед заказом соберите эти действия и вопросы в короткий бриф. Тест для руководителя поможет оценить готовность разработки к ИИ-агентам; он не заменяет исследование сотрудников. Для оценки сроков сначала нужны реальные связи систем и условия приёмки.

Когда после пилота остаётся очередь доработок, можно рассматривать подписку. На странице разработки по подписке тариф «Все проекты» стоит 500 000 ₽ в месяц и включает три потока работы, по одной задаче в работе на поток; проверено 7 октября 2026. Это цена месяца работы, а не цена корпоративного портала целиком.

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

1. Назовите три повторяющихся дела и результат каждого до выбора платформы.

2. Проверьте готовую платформу и её доработку на этих делах; свой интерфейс выбирайте под найденное ограничение.

3. Назначьте каждому виду данных источник, владельца и правило доступа.

4. Принимайте полный путь действия, включая чужие права, повторную отправку и отказ связи.

5. По результатам пилота исправьте незавершённое дело, затем выбирайте следующее.