Въвеждам ред в Bitrix24, CRM и работните процеси на компанията

• REST вече претоварва портала
• Стандартната настройка на роботи не стига
• Нужни са кастъм обработчици на събития
• Тежки операции забавят CRM
• Нужни са собствени табове и действия в картата
• Логиката е „разпиляна“ и се чупи при промени

• Стабилна логика вътре в портала
• Ясни логове и диагностика
• По-малко натоварване на REST
• Документация на входните точки
• Поддържаема структура на кода

• Не замествам пълноценен DevOps/SRE
• За production промени първо преглеждам логове и правя резервно копие
• Точната цена казвам след достъп до портала

• Нужен е външен продукт върху CRM
• Нужен е API или интеграционен хъб
• Логиката не се побира в кутията
• Нужни са опашки и фонови задачи
• Нужен е админ панел с роли

• Грешките се виждат в логовете
• Тежките операции отиват в опашка
• Проектът се поддържа по-лесно
• Нови функции без хаос
• Тестваем код

• Подготвям инфраструктура в рамките на собственото си решение, не като DevOps аутсорс
• Пълна преработка на стар проект — с отделна оценка

• Синхронизацията работи „понякога“
• Появяват се дубликати
• Данните се разминават между системите
• Няма история на обмена
• Грешката не се вижда от потребителя
• Нужно е CRM да се свърже с външна услуга

• Данните не се губят
• Не се създават дубликати
• Обменът не пада тихо
• Ясни логове на входящи/изходящи заявки
• Възможност да се повтори неуспешна операция

• Не отговарям за сривове от страна на външни услуги и доставчици
• Маскирам тайни, не логвам токени
• Първо тестова среда, после production

• Данните се прехвърлят ръчно
• Сверяват таблици между системите
• Заявки се губят
• Одобренията вървят „на думи“
• Няма контрол на сроковете
• Отчетите се събират ръчно

• По-малко ръчна работа
• Заявки и одобрения не се губят
• Прозрачни срокове и статуси
• Отчетите се събират сами

• Първо фиксирам текущия процес, после автоматизирам
• Сложни сценарии — на етапи
• Зависи от достъпите и данните на системите

• Разработчикът си тръгна, кодът остана
• Няма документация
• Няма логове
• Процесите се чупят
• Страшно е да се пипа production
• Нужна е причина, а не „поправка на симптома“

• Ясна карта на проблемите
• Приоритети и план
• Оценка на сроковете
• Препоръки за логове и архитектура
• Разбиране какво може да не се пренаписва

• Не пипам production сляпо
• Правя резервно копие при риск от загуба на данни
• Пълна преработка на архитектурата — с отделна оценка

• Интеграциите падат тихо
• Няма история на обмена
• Неуспешна операция не може да се повтори
• Данните се дублират

• Интеграции
• Логове на обмена
• Retry / backoff
• Encrypted secrets
• Health-check
• Опашки
• Админ панел

• Не замества ESB/iPaaS от enterprise клас
• Всяка система се свързва като отделна задача

• Дубликати на лийдове и сделки
• Роботи и бизнес процеси се задействат неправилно
• Тежки REST заявки
• Няма логове и история

• Преглед на структурата
• Проверка на логовете
• Търсене на рискове
• Карта на проблемите
• Таблица на рисковете
• План за поправки

• Поправките са отделен етап
• Без достъп до логове/код точността е по-ниска

• Неясно е дали събитието е дошло
• Няма payload за анализ
• Грешката не се вижда
• Не може да се изпрати отново

• Приемане на webhooks
• Съхранение на payload
• Проверка на подпис
• Статус на обработка
• Грешки
• Ръчно повторение

• Изгражда се върху Integration Hub
• Обработката за всеки източник е отделна

• Клиентите не виждат статуси и данни сами
• Поддръжката е претоварена с еднотипни въпроси
• Заявки и съобщения се губят в имейл/месинджъри

• Автентикация и роли
• Заявки и статуси
• Съобщения
• Документи и фактури
• Известия
• Интеграция с CRM
• Админ панел

• Не е лицензиран SaaS — това е адаптируема основа
• Сложни кастъм модули се оценяват отделно

• Клиентите нямат къде да виждат статуси от CRM
• Мениджърите препращат данни ръчно

• Статуси на заявки
• Запитвания
• Фактури
• Съобщения
• Връзка с данните на CRM

• Зависи от изданието и достъпите на Bitrix24
• Тежката логика се изнася на D7 отделно

• Служителите работят в разпръснати таблици
• Няма единна точка за задачи и заявки

• Автентикация и роли
• Задачи / заявки
• Достъп до данните на процесите

• Проектира се за задачата — изисква уточняване на обхвата

• Партньорите не виждат статуси на заявки
• Документите и разплащанията вървят ръчно

• Автентикация на партньори
• Заявки и статуси
• Документи
• Разплащания

• Проектира се за партньорския модел

Обменът минава през финансов брокер, чийто реален формат на callback-ите се разминаваше със заданието; банката има собствен справочник със статуси, а кредитните продукти — лимити по сума и срок. След одобряване на договора заявка вече не може да се подава.

• Смарт процес „Кредитни заявки“ с 21 полета за резултат и права по роли: мениджърът вижда своите заявки, ръководителят — своя отдел, администраторът — всички
• Изпращане към брокера от картата на сделката: чернова, проверка на задължителните полета и лимитите на продукта, забрана за подаване след одобряване на договора, защита от двойно натискане
• Приемане на callback-и: автентикация с ключ, идемпотентност по eventId, толерантно парсене на тялото — 5 дни callback-ите тихо не се записваха заради разминаване със заданието, открито и поправено
• Справочник със статуси на банката — 28 бизнес и 16 технически; окончателното решение създава „дейност“ за мениджъра и се записва в таймлайна на сделката
• SMS до клиента с линк към анкетата на банката по правилото „една заявка — едно SMS“, с приемане на отчета за доставка
• Дневник на обмена по 6 направления, робот на бизнес процес „Изпрати заявка“ и сутрешен наблюдател за заявки без събития повече от 3 дни

Модулът работи в продукция от 10.08.2026, от 08.09 — на продукционната среда на брокера, SMS до клиентите се изпращат от 31.08. Логиката без мрежа се покрива от 192 CLI проверки, а всяко събитие от обмена се вижда в дневника и в таймлайна на сделката.

Реален облачен портал с роботи и масови съобщения на етапите — всяко масово преместване веднага изпраща съобщения на живи хора. REST тихо игнорира част от филтрите и ограничава времето за работа, а сървърът и порталът са в различни часови зони.

• Приемане на отчетите за присъствие от Bizon365: по дни на ефира сделката се движи само напред според тежестта на етапите и никога не се връща назад
• Отделен път за уебинарите с казуси — задача за отговорника вместо нова сделка, идемпотентност по sha256 ключ на събитието и режим dry_run без нито един запис
• Преместване на неявилите се в „Не дойдоха“ на пакети: запис само с --execute, защита от повторно и паралелно стартиране, защита на присъствалите на ефира
• Покана 10 минути преди ефира чрез етап тригер с връщане на сделката в изходния етап; купувачите на курса се изключват от изпращането
• Присъединяването към WhatsApp чат през ChatApp премества сделката в нужния етап — чрез файлова опашка с flock вместо създаване на нови сделки
• Обвивка над REST, която не представя грешките като успех и сама изчаква порталът отново да разреши заявки

Поканите за ефира стигнаха до 628 от 628 участници без грешки, в „Не дойдоха“ са преместени 451 от 451 сделки, наваксано е натрупаното изоставане от 396 сделки; защитата на присъствалите отсея 65 от 78 сделки. Ревизията на контактите откри 564 карти с телефон в полето „Име“ — източник на неизтриваеми дубликати.

Нищо не може да се изтрива: това са работни документи по съдебни дела. Част от линковете минаваха през външна услуга за съкращаване на линкове или водеха към стария портал, част от делата имаха собствени контейнери за папки, а спорните съвпадения могат да се решават само заедно с юристите.

• Анализ само с четене: пул от папки, класификация на всеки линк от картите (работещ, през съкращаване, стар портал, празен, боклук), папки сираци
• Сливане на дублиращи се папки с приоритет на основното дело: съдържанието се премества в каноничната папка, източниците не се изтриват, съмнителните групи — за ръчен преглед
• Синхронизация на файловете от файловите полета на картата в папката на делото без дубликати по име и размер, поправка на линковете и попълване на служебното поле с id на папката
• Повторно създаване на липсващите папки за дела, които изобщо нямаха работна папка на диска
• Краен pipeline с една команда: по подразбиране три dry-run прогона, реален прогон — само с потвърждение, спиране при първата грешка; нощна синхронизация по cron

Анализът откри 334 папки, 16 групи дубликати и 298 поправими линка през услугата за съкращаване. Реалният прогон обработи 750 елемента: копирани са 2544 файла, поправени 302 линка, попълнени 250 id на папки — 0 грешки; повторната проверка потвърди 7182 файла на местата си в 780 елемента.

Продукцията не може да се спира, от текущото поведение зависят десетки интеграции; одитът трябва да се включва с флагове с безопасни стойности по подразбиране, а личните данни не бива да попадат нито в отговорите, нито в логовете.

• Затворени са 6 места, даващи администраторска сесия при анонимна заявка, и заобикалянето на автентикацията в 6 API endpoint-а; stack trace е премахнат от отговорите
• Анонимните endpoint-и получиха rate limit, ИИН се валидира преди платените външни извиквания; затворени са IDOR и CSRF в работните интерфейси
• Паролата във формата за вход се криптира в браузъра (RSA-OAEP, ключ 4096 бита); около 50 хардкоднати достъпа са изнесени в .env
• Одитна следа зад флагове: неуспешни входове, дневник на API обръщенията, копие в syslog; ежедневен наблюдател за ротацията на логовете и за регресия на задължителната 2FA
• Логерът маскира ИИН, телефони и карти; ротация 90 дни плюс архив 400 дни; фалшивото маскиране на хешове — от 5,1% до 0% върху 200 000 стойности
• Преглед на логове с графики и търсене по id на заявката; health API улавя скок на грешките спрямо медианата, тишина и спряла ротация

Натрупаните логове са архивирани: 6344 файла с обем 2041 МБ са компресирани в архив от 120 МБ с контролни суми, директорията local/ намаля от 2,6 ГБ на 578 МБ. Критичните пропуски в достъпа са затворени, а в логовете се вижда инцидентът, а не шумът.

Реалният поток е около 95 заявки на месец, затова каталогът беше изграден по фактическата честота на обръщенията, а не „както е прието“. Каталогът трябва да се редактира от администратор без разработчик, а срокът по SLA — да не може да се разтяга тихомълком.

• Анализиран е експортът от OSTicket: отделен е мониторингът, преброени са честотите по теми — от тях е съставен двустепенен каталог от 11 направления и 32 услуги, като най-честите са най-горе
• Уточняващите въпроси на услугата са описани с JSON схема със зависими полета; едни и същи правила за проверка на сървъра и в браузъра се сверяват с общи тестови фикстури
• Ефективен приоритет „услуга × спешност“, норми за реакция и решение в работни минути; изходният срок се фиксира при подаването и не се разтяга
• Автоматично назначаване на най-слабо натоварения изпълнител от групата на услугата и агент за контрол на SLA с известия
• Един механизъм за каталог и съветник обслужва 4 каталога: help desk, HR процеси, документооборот и заявки за разработка

Вместо пет категории и един срок за всичко — каталог по фактическото търсене, собствени норми за всяка услуга (от 15/60 минути за нулиране на парола до 480/4800 за промени в портала) и срок, който не може да бъде преместен незабелязано.

Уиджетът трябва да се вгражда във външни сайтове на обектите от мрежата (включително WordPress) без Bitrix автентикация, като статусът на заетост не бива да се разминава с реалните данни в CRM.

• Вграждаем конструктор на интерактивни планове на етажи — публичен iframe/JS уиджет без Bitrix автентикация (CSP/CORS настроени за вграждане от външни домейни)
• Вътрешен админ панел за качване и редактиране на плановете
• Автоматична синхронизация на статуса на заетост, наемателя и датата на изтичане на наема от CRM чрез cron — изображенията на плановете се качват ръчно, данните за заетост се обновяват сами
• Табла за заетост по обекти от мрежата: процент заетост по площ (кв.м), брой офиси, приход от заетите площи
• Уиджетът вече е вграден на външни сайтове на обекти от мрежата

В мрежата: 93 етажа, 1087 офиса и 152 качени плана — със заетост, която се обновява от CRM автоматично, а не се сверява ръчно за всеки обект.

Роботът работи с кампании — отделна за всяка стъпка на заявката; един клиент може да има няколко карти; повторното стартиране на cron не бива да води до второ обаждане, а обаждания са разрешени само в дневен прозорец.

• Cron на всеки 15 минути избира сделки без движение от 30+ минути по стандартната история на етапите: смяната на етапа нулира таймера
• Карта на етапите на фунията: всяка стъпка от заявката води към своя кампания на робота, крайните, отказните и служебните етапи не се изпращат; прозорец за обаждания 08:00–21:00
• „Един клиент — едно обаждане“: картите се обединяват по телефон, за обаждане се изпраща най-новата, а негативен изход сваля от обаждане всички карти с този номер
• Идемпотентност на три нива: flock срещу паралелни стартирания, полета на поръчката в сделката и стабилен import_id на страната на робота
• Уебхукът за резултата от обаждането намира сделката, записва изхода, без да изтрива полета с празни стойности, и стартира бизнес процес; има тестов режим с отделна кампания
• Логиката за подбор е изнесена в чисти функции без ядрото на Bitrix и е покрита с 66 smoke проверки

Заседналите заявки отиват към робота автоматично, без ръчно обаждане, и клиентът не получава две обаждания по различни карти. Всеки прогон записва в лога причината за пропускане на всяка карта.

Част от класическите метрики на кол центъра (SL/ASA/ATA) физически не могат да се изчислят без данни от телефонията; смесването на различни източници на дати (лийд/посещение) изкривява процентите, ако не се разделят изрично.

• 20 параметризирани SQL отчета върху live данни на CRM с безопасно заместване на филтрите
• Фуния „лийд → посещение → сделка → продажба“ с междинни метрики (Contact Rate, Occupancy и др.)
• Многослоен кеш с TTL, stale-fallback и заключвания — дашбордът не натоварва CRM с тежки заявки
• 33 whitelisted AJAX действия с проверка на права и sessid
• Честна документация на ограниченията на всяка спорна метрика — вместо разкрасяване на числата
• Дашборд за ръководителя продажби по автоцентър: метриките се изчисляват по автоцентъра на самата сделка, всяко число се разгръща с клик в списък със сделки
• Маркетингов дашборд по направления и източници на трафик; сравнение със същите дати от предходния месец на всички страници
• Общ кеш на отчетите с проверка на достъпа преди кеша: първото изграждане — 7,2 с, за следващия потребител — 0 мс
• Регистър на достъпите „кой вижда кой отчет“ с източника на всеки достъп, предоставяне без деплой и единна навигационна лента за отчетите

Ръководството, кол центърът, ръководителите продажби и маркетингът получиха набор от дашборди върху live данни на CRM вместо експорти в Excel: фуния, автоцентър, маркетинг — с общ кеш, разшифроване на числата с клик и ясно документирани ограничения на метриките. Достъпът до 6 отчета се управлява от един регистър без деплой.

• Дубликати на лийдове и сделки
• Мръсни телефони
• Изгубени връзки
• Разминаване между CRM и склад
• Неактуални наличности

• Броя дубликатите и разминаванията със заявки: още преди поправките се вижда колко записа са засегнати
• Нормализирам телефони, имейли и ключови полета към един формат
• Въвеждам търсене на съществуващ запис, преди да се създаде нов
• Затварям източника: формата, импорта или интеграцията, която е плодяла боклук
• Оставям сверка, която може да се пусне отново и да се види резултатът

• Роботите не се задействат
• Бизнес процеси засядат
• Одобренията вървят ръчно
• Няма контрол на срокове
• Мениджърите заобикалят CRM

• Гледам на коя стъпка засядат процесите и по кое условие
• Сверявам какво трябва да задейства робота и какво го задейства в действителност
• Премествам крехката логика от конструктора в код с логове
• Добавям контрол на сроковете и известия до отговорните
• Махам ръчните стъпки, заради които мениджърите заобикалят CRM

• Няма логове
• Няма retry
• API пада
• Данните идват частично
• Грешката не се вижда от потребителя

• Включвам логване на входящите и изходящите заявки, с маскирани токени
• Добавям повторни опити със забавяне при временни грешки на чуждото API
• Разделям „данните не дойдоха“ от „дойдоха частично“ — това са различни повреди
• Извеждам грешката там, където ще я види човек, а не само сървърът
• Оставям режим за проверка: обменът се пуска, без да пише в живата база