Бизнес-автоматизация
ITD Partner Portal — система фиксации клиентов для партнёрской сети
Разработал специализированную систему для партнёрской сети — от ввода данных до проверки накладок, решения менеджера и интеграционных заданий. «Миндаль» — реальный пример внедрения публичной части Partner Portal.
Есть похожая задача? Напишите в Telegram, что уже работает и что нужно изменить.
Контекст
Контекст и задача
Связать обращение партнёра, проверку возможного совпадения и решение менеджера в один понятный процесс.
Когда несколько партнёров работают с одним объектом, важно сохранять контекст обращения — кто представил клиента, какие данные передал и какое решение принято. Partner Portal закрывает этот конкретный процесс внутри WordPress. Ниже разделены механизмы, подтверждённые исходным кодом продукта, и публичный интерфейс внедрения «Миндаль».
Работа
Что сделано
- 01
Спроектировал процесс фиксации и реализовал собственный WordPress-плагин.
- 02
Связал проверку данных, признаки возможной накладки, статусы и комментарии менеджера.
- 03
Разработал журнал действий, очередь заданий и модули Telegram и Google Sheets.
Логика продукта
Формы недостаточно — нужен процесс
Форма решает задачу ввода. Для партнёрской программы нужны ещё правила проверки, единый реестр, признаки возможного совпадения и решение ответственного сотрудника. Поэтому интерфейс стал входом в собственную бизнес-логику, а не просто способом отправить сообщение.
В кодовой базе Partner Portal эти обязанности разделены. Запись, её статус и задания внешним сервисам имеют разные роли — результат обращения не сводится к одному уведомлению.
-
Партнёр
Открывает объект и знакомится с условиями.
-
Фиксация
Передаёт данные через форму обращения.
-
Проверка
Проверяются формат данных и возможные накладки.
-
Запись
Обращение получает номер в основном реестре.
-
Статус
Решение и комментарий менеджера сохраняют контекст.
-
Интеграции
Отдельные задания связывают реестр с внешними каналами.
Реализовано в коде
От введённых данных к фиксации
Серверный обработчик проверяет обязательные поля, согласие, объект и формат данных. Телефон представителя приводится к единому виду; для телефона клиента используется маска, а имя подготавливается к сравнению.
После проверки создаётся запись с публичным номером и исходным статусом. Основной реестр находится в базе WordPress. Маска сокращает объём телефонных данных, но не превращает все сведения в анонимные.
Реализовано в коде
Подсказать накладку, а не решить спор за человека
Система сопоставляет обращения по одному объекту — нормализованное имя и доступные части маски телефона. Возможное совпадение получает признак риска и статус для проверки менеджером.
Это помощь в разборе спорной ситуации, а не безошибочная идентификация клиента. Похожие данные могут относиться к разным людям; окончательное решение остаётся за сотрудником. Проверка накладок не заявляется как гарантия отсутствия повторных записей при любых условиях отправки.
Реализовано в коде
Запись живёт дольше одной отправки
В административной части реализованы список фиксаций, фильтры и карточка записи. Менеджер может изменить статус и оставить отдельный комментарий к решению.
Предусмотрены новая запись, проверка накладки, подтверждение, дубль, отклонение, истечение и отмена. Эти состояния дают сотруднику общий язык для работы с обращениями; наличие статуса истечения само по себе не означает автоматического закрытия по таймеру.
В доступных доработках есть отдельная роль менеджера с правами на рабочие разделы. Повседневная обработка обращений отделена от служебных административных настроек.
Реализовано в коде
Восстановить последовательность решений
Изменения статуса и комментария сопровождаются записями в журнале. Он хранит действие, время, пользователя и данные изменения; отдельные операции с очередью также журналируются.
Это история работы приложения, которая помогает разбирать, что происходило с записью. Она не представляется как неизменяемый или юридически удостоверенный протокол.
Реализовано в коде
Реестр — отдельно, внешние каналы — отдельно
Кодовая база содержит модули Telegram и Google Sheets. Первый связывает события с каналом уведомлений, второй создаёт табличное представление внутреннего реестра. Поддерживаются варианты через webhook и прямые API; назначения могут определяться для конкретного объекта.
Для Google Sheets предусмотрен поиск строки по публичному номеру фиксации — существующая строка обновляется, новая добавляется. Таблица остаётся зеркалом, а не основным хранилищем.
У интеграционного задания есть состояние, счётчик попыток и отметка об ошибке. Реализованы ручной повтор и обработка выбранных свежих заданий после сохранения. Автономный планировщик и автоматические повторы по расписанию не подтверждены.
Здесь описана реализация продукта. Текущая доставка в Telegram и Google Sheets именно во внедрении «Миндаль» в рамках подготовки кейса не проверялась.
Техническая основа
Собственная логика внутри WordPress
Плагин объединяет описание объекта, публичные шаблоны, серверную проверку, хранение фиксаций, административные действия, журнал и интеграционные модули. PHP, WordPress API и MySQL/MariaDB отвечают за предметную логику; JavaScript и CSS — за интерфейс.
Для управляемых действий предусмотрены проверки прав, для ввода — валидация и дополнительные защитные проверки. Это конкретные механизмы приложения, не заявление о прохождении полного аудита безопасности.
Масштаб решения соответствует задаче — специализированная бизнес-система для партнёрского процесса, без претензии на универсальную CRM или большую SaaS-платформу.
Публичное внедрение
Партнёрская программа «Миндаль»
Публичная часть Partner Portal используется в проекте «Миндаль». На странице объекта есть материалы, условия партнёрства и переход к фиксации клиента. Форма доступна без предварительного входа в аккаунт.
Интерфейс предусматривает сведения о представителе и агентстве, имя клиента, маску его номера, интересы и подтверждение согласия. Правила вынесены в отдельный блок, название агентства вводится свободным текстом.
Для этого внедрения проверен публичный пользовательский сценарий. Сохранение заявки не тестировалось, а точная серверная сборка не подтверждена — поэтому описанные выше возможности кода не выдаются за проверенный backend «Миндаль».
Публичный интерфейс
Условия видны до заполнения
Блок правил находится непосредственно перед полями формы. Партнёр видит условия фиксации до начала ввода, а не узнаёт о них после обращения.
Публичный интерфейс
Пустая форма — без реальной заявки
На фрагменте формы видны маска телефона, поле интересов клиента и подтверждение согласия. Поля не заполнялись, отправка не выполнялась. Даже демонстрационные имена из подсказок других полей исключены из кадра.
Роль
Ответственность IT Dream
Егор / IT Dream — проектирование процесса фиксации и разработка собственной WordPress-логики Partner Portal, включая обработку данных, проверку накладок, статусы, комментарии менеджера, журнал и интеграционные механизмы. «Миндаль» показан как реальный пример публичного frontend-внедрения.
Стек
Технологическая основа
- WordPress plugin
- PHP
- MySQL / MariaDB
- JavaScript / CSS
- WordPress API
- Telegram API · модуль продукта
- Google Sheets API · модуль продукта
Итог
Результат
Разработана предметная система для партнёрского процесса — реестр обращений, проверка возможных накладок, административная работа, история действий и отдельные интеграционные задания. Для «Миндаль» подтверждён публичный интерфейс. Экономический эффект, эксплуатационные объёмы и текущие результаты внешней доставки не заявляются.
Нужно упорядочить конкретный бизнес-процесс?
Разберу, какие данные важно фиксировать, где возникают спорные ситуации и какие инструменты должны получать результат. Начнём с правил работы и границ задачи.
