Програма для сканування документів у медичній дистрибуції потрібна не заради охайних PDF. Вона потрібна, щоб у момент відвантаження компанія точно знала: на цю серію є сертифікат якості, у покупця чинна ліцензія, договір не закінчився, а борг у межах ліміту. Якщо скан лежить у папці «Сертифікати_нове» і ніхто не пам’ятає, до якої партії він належить, це архів, а не контроль.
Ця стаття для власника або операційного директора компанії, яка постачає ліки, медичні вироби чи витратні матеріали аптекам, клінікам і лікарням. Типова картина така: склад, кілька менеджерів, облік у BAS або 1С, заявки у Viber, Telegram і пошті, а сертифікати на серії — у коробках, на диску й у телефоні комірника.
Розберемо три потоки, на яких такі компанії втрачають найбільше часу й найбільше ризикують: документи на партії, заявки клієнтів і строки (ліцензії, договори, оплати). Покажемо, які програми для сканування існують і що кожна з них реально закриває, як побудувати ланцюжок «скан — розпізнавання — реєстр — дозвіл на відвантаження» і де штучний інтелект справді допомагає, а де має працювати формула або людина.
Коротко
- Скан без прив’язки до серії нічого не контролює. Цінність дає не файл, а зв’язок: сертифікат — серія — залишок — відвантаження конкретному клієнту.
- Порядок контролю якості вимагає копії сертифіката на кожну серію і реєстр реалізації. Вести його в Excel можна, але перевіряти вручну при кожному відвантаженні — ні.
- ШІ добре читає скани, фото й повідомлення у вільній формі. Серію, номер сертифіката, строк придатності він заносить у чернетку, а підтверджує уповноважена особа.
- Строки контролюють правила, а не пам’ять однієї людини. Система нагадує заздалегідь і попереджає просто в момент оформлення відвантаження.
- Почати можна з одного потоку. Перша робоча версія системи — за кілька днів, уся система — за 2–4 тижні, і два тижні вона працює паралельно зі старою схемою.
Чому медичному дистриб’ютору замало просто сканувати документи
Які документи проходять через компанію щотижня
Звичайний тиждень медичного дистриб’ютора — це не лише видаткові накладні. На вході від постачальника приходять накладні, копії сертифікатів якості серій, для ввезених препаратів — висновки про якість, для медичних виробів — декларації про відповідність. На виході до клієнта йдуть рахунки, видаткові накладні, копії тих самих сертифікатів, акти звірки. Збоку — договори з аптеками й клініками, копії їхніх ліцензій, довіреності, листи про зміну реквізитів.
Частина документів приходить в електронному вигляді через сервіси електронного документообігу. Частина — сканом на пошту. Частина — фотографією у Viber, бо водій постачальника сфотографував сертифікат просто біля машини. І ще частина — папером у коробці з товаром. Кожен із цих каналів має свого «власника» в компанії, і жоден не бачить картину повністю.
Що вимагає Порядок контролю якості лікарських засобів
Для ліків правила записані в Порядку контролю якості лікарських засобів під час оптової та роздрібної торгівлі, затвердженому наказом МОЗ № 677 від 29.09.2014 (текст наказу). Пункти, які прямо стосуються документів:
- торгівля лікарськими засобами без сертифіката якості серії заборонена;
- кожна серія має супроводжуватися копіями сертифіката якості серії, завіреними печаткою останнього постачальника;
- протягом трьох років компанія зберігає документи про закупівлю, зберігання, транспортування й торгівлю і надає їх для перевірок;
- оптовик веде реєстр лікарських засобів, які реалізує: покупець і номер його ліцензії, номер і дата накладної, назва й форма препарату, виробник, серія, номер і дата сертифіката якості, кількість упаковок, строк придатності, результат контролю уповноваженої особи;
- реєстри можна вести в електронному та/або паперовому вигляді, але так, щоб їх можна було терміново сформувати.
Останній пункт важливий для вибору програми. Реєстр, який бухгалтер збирає два дні з різних таблиць, формально існує, але «терміново сформувати» його не вийде. А реєстр, де кожен рядок створюється в момент відвантаження з уже перевірених даних, формується за хвилину.
Нормативні акти змінюються, тому перед налаштуванням правил звірте чинну редакцію з вашою уповноваженою особою. Для медичних виробів діє окрема логіка — Технічний регламент щодо медичних виробів (постанова КМУ № 753). Його вимоги до супровідних документів варто винести в окремий чекліст, а не змішувати з правилами для ліків.
Де ламається схема «скан у папку»
Більшість компаній починає з найпростішого: сканер або телефон, папка на диску, таблиця з датами. Це працює, поки партій мало і всі документи приймає одна людина. Далі починаються типові збої:
- Файл є, зв’язку немає. Скан сертифіката називається «IMG_4471.pdf». Щоб знайти його на запит аптеки чи під час перевірки, людина відкриває десятки файлів.
- Таблицю заповнює одна людина. Коли вона у відпустці, нові серії потрапляють на склад без запису в реєстрі, і ніхто цього не помічає до першого запиту.
- Перевірка відбувається не там, де ухвалюють рішення. Менеджер оформлює відвантаження в обліковій системі, а сертифікат і ліцензію клієнта перевіряють в іншому місці — або не перевіряють зовсім.
- Строки ніхто не бачить заздалегідь. Про договір, який закінчився, дізнаються, коли товар уже поїхав, а оплата зависла.
Програма для сканування закриває лише перший крок — отримати чіткий файл. Решту ланцюжка має закривати система, у якій документ прив’язаний до серії, клієнта й відвантаження.
Програма для сканування документів: які бувають і що з них підходить дистриб’ютору
П’ять класів рішень
| Тип рішення | Приклади | Що робить добре | Чого не робить |
|---|---|---|---|
| Сканер у телефоні | сканер у застосунку OneDrive, Adobe Scan, Dropbox | швидкий скан на складі, обрізання країв, PDF | не знає, до якої серії й накладної належить документ |
| Програма для сканера на комп’ютері | NAPS2, утиліта виробника сканера | пакетне сканування, PDF з текстовим шаром | файли лишаються в папці, за строками ніхто не стежить |
| Сервіс електронного документообігу | Вчасно, M.E.Doc | обмін і підписання накладних та актів | паперові сертифікати й фото з Viber туди самі не потрапляють |
| Облікова система | BAS, 1С | залишки, серії, накладні, вкладені файли | розпізнавання сканів і нагадування клієнтам зазвичай потребують доробок |
| Система управління з ШІ-розпізнаванням | будується під ваш процес | читає скан, заповнює реєстр, перевіряє строки перед відвантаженням | потребує опису процесу і людини, яка підтверджує дані |
Перші два класи — це саме те, що людина зазвичай має на увазі, коли шукає програму для сканування. Наприклад, NAPS2 — безкоштовна програма з відкритим кодом для Windows, Mac і Linux: вона зберігає скани в PDF, TIFF, JPEG і PNG і робить текст у PDF доступним для пошуку завдяки розпізнаванню понад 100 мов (сайт NAPS2). Для архіву цього достатньо. Для контролю — ні, бо програма не знає, що таке серія чи ліцензія покупця.
Якщо на вашому складі досі сканують через Microsoft Lens, час переходити: застосунок прибрали з магазинів 9 лютого 2026 року, а сканування в ньому припинилося 9 березня 2026 року. Microsoft радить сканер у застосунку OneDrive, але скани там зберігаються в хмарі, а не на пристрої (Microsoft Support). Для медичних документів це питання доступу: чий обліковий запис, хто ще бачить папку, що буде, коли працівник звільниться.
Чекліст вибору для медичного дистриб’ютора
Перевірте будь-яке рішення за цими пунктами. Якщо більшість відповідей «ні», програма підійде для архіву, але не для контролю.
- Скан читабельний: видно серію, дату, печатку постачальника, а не лише текст.
- Розпізнавання працює з українською мовою і з латиницею в назвах виробників.
- Документ можна прив’язати до серії, накладної постачальника й клієнта, а не лише покласти в папку.
- Є реєстр реалізації з полями з Порядку № 677, і він формується за період одним запитом.
- Строки сертифікатів, договорів і ліцензій видно заздалегідь, а не в день відвантаження.
- Видно, хто і коли підтвердив кожен документ.
- Дані зберігаються щонайменше три роки, є щоденні резервні копії.
- Комірник може сканувати з телефона на складі, без окремого комп’ютера біля сканера.
Типові помилки при виборі
- Купити потоковий сканер раніше, ніж описати процес. Швидкість сканування рідко буває вузьким місцем. Вузьке місце — хто і куди записує дані зі скану і хто їх перевіряє.
- Обрати сервіс ЕДО і вважати, що питання закрите. ЕДО добре обмінюється електронними накладними й актами. Але сертифікати від частини постачальників однаково прийдуть папером чи фото, і їх теж треба кудись прив’язати.
- Зберігати скани в особистому телефоні складського працівника. Коли людина звільняється, частина архіву йде разом із нею.
- Розпізнавати все підряд. Для реєстру потрібні кілька полів, а не повний текст кожної сторінки. Що менше полів, то менше помилок і швидша перевірка.
Ширше про те, як ШІ розбирає первинку, — у статті як ШІ читає накладні, рахунки й акти.
Як має працювати потік: від скану сертифіката до дозволу на відвантаження
Покроковий ланцюжок
- Приймання партії. Комірник або уповноважена особа відкриває в системі накладну постачальника. Позиції й серії підтягуються з накладної: з ЕДО, з файлу або зі скану.
- Скан документів. Сертифікати якості серій фотографують телефоном прямо в картку приймання — через Telegram-бота або веб-форму. Одне фото — одна сторінка, система сама збирає їх в один PDF.
- Розпізнавання. ШІ читає скан і заповнює чернетку: назва препарату, серія, номер і дата сертифіката, виробник, строк придатності.
- Звірка. Система порівнює серію і строк придатності зі скану з даними накладної. Розбіжність отримує позначку, а не мовчазне виправлення.
- Підтвердження людиною. Уповноважена особа бачить чернетку поруч зі сканом і натискає «підтвердити» або виправляє поле. Система фіксує, хто і коли це зробив.
- Запис у реєстр. Серія отримує статус «документи в порядку» і стає доступною до продажу. Без цього статусу менеджер її не бачить або бачить із попередженням.
- Відвантаження. Під час оформлення замовлення система перевіряє серію, ліцензію покупця, договір і борг. Якщо чогось бракує — попередження або заборона, як вирішить власник разом з уповноваженою особою.
- Комплект для клієнта. Система готує копії сертифікатів на відвантажені серії. Паперовий примірник із печаткою друкують із того самого файлу, електронний надсилають клієнту після перевірки менеджером.
- Реєстр на вимогу. На перевірку чи запит аптеки реєстр за період формується з тих самих даних, без ручного зведення таблиць.
Ключова відмінність від схеми «скан у папку» — крок 7. Перевірка документів відбувається там, де ухвалюють рішення про відвантаження, а не окремо від нього.
Які поля витягати і як їх перевіряти
| Поле | Звідки береться | Як перевірити |
|---|---|---|
| Серія | сертифікат, накладна | має збігатися в обох документах |
| Номер і дата сертифіката | сертифікат | дата не пізніша за дату накладної |
| Строк придатності | сертифікат, накладна | збігається; не минув на дату приймання |
| Виробник | сертифікат | збігається з карткою товару |
| Печатка постачальника на копії | скан | перевіряє людина; ШІ лише позначає, чи видно відбиток |
| Номер ліцензії покупця | копія ліцензії від клієнта | записаний у картці клієнта, перевірений при укладанні договору |
Не намагайтеся з першого дня розпізнавати всі документи. Почніть із сертифікатів якості серій: це найчастіший документ, від нього залежить дозвіл на продаж, і в нього стабільна структура.
Що робить ШІ, а що — людина
Робить ШІ:
- читає скан або фото, навіть зроблене під кутом;
- заносить потрібні поля в чернетку;
- позначає розбіжності з накладною;
- підказує, що бракує сторінки або сертифіката на якусь серію з накладної;
- групує сторінки одного документа.
Не робить ШІ:
- не вирішує, чи можна продавати серію, — це рішення уповноваженої особи;
- не «домальовує» нечитабельну цифру: поле лишається порожнім і йде людині;
- не підтверджує справжність печатки чи підпису;
- нічого не надсилає клієнту без людини, якщо інше окремо не погоджено.
Ліцензії клієнтів, договори й строки: реєстр замість пам’яті однієї людини

Друга половина документального контуру — строки. У медичного дистриб’ютора їх більше, ніж у звичайного оптовика: строк придатності партій, строки договорів, ліцензії клієнтів, сертифікати на медичні вироби, акти звірки, оплати. Номер ліцензії покупця входить до реєстру реалізації за тим самим Порядком № 677, тому перевірка ліцензії клієнта — частина відвантаження, а не окрема бюрократія.
Як побудувати реєстр строків
Реєстр строків — це не окрема таблиця «для бухгалтера». Це довідник, з яким звіряється кожна операція. Мінімальний набір полів:
- Об’єкт — серія, клієнт, договір чи власний документ компанії.
- Тип документа — сертифікат якості, договір постачання, копія ліцензії, декларація про відповідність.
- Номер і дата документа.
- Дата закінчення або позначка «без строку».
- Відповідальний — конкретна людина, а не відділ.
- Статус — чинний, закінчується, на оновленні, прострочений.
- Скан — посилання на файл у картці.
- Що блокує — продаж серії, відвантаження клієнту або нічого.
Поле «що блокує» перетворює реєстр на контроль. Прострочений договір із клієнтом блокує нові відвантаження цьому клієнту. Відсутній сертифікат блокує продаж серії. Прострочений акт звірки нічого не блокує, але створює задачу бухгалтеру.
Для ліцензій клієнтів дата закінчення — не головне. Важливіше, чи ліцензія чинна зараз: її можуть зупинити або анулювати, клієнт може змінити адресу місця провадження діяльності. Тому в картці клієнта зберігайте дату останньої перевірки і правило, коли перевіряти знову: при укладанні договору, при зміні реквізитів, при першому відвантаженні на нову адресу.
Пороги сповіщень: приклад налаштування
Нижче — приклад, а не норма. Ваші пороги визначають договори з клієнтами, ритм закупівель і практика компанії.
| Подія | Коли сповіщати | Кому | Що робить система |
|---|---|---|---|
| Договір із клієнтом закінчується | за 30 і за 14 днів | менеджер клієнта | задача з чернеткою листа про продовження |
| Сертифікат на серію не завантажено після приймання | наступного ранку | уповноважена особа | серія недоступна до продажу |
| Серія наближається до межі залишкового строку, яку приймають ваші клієнти | за 60 днів до межі | закупівля, менеджери | список клієнтів, яким цю серію ще можна запропонувати |
| Копія ліцензії клієнта не перевірялася після зміни реквізитів | одразу після зміни | менеджер клієнта | попередження в картці клієнта |
| Рахунок не оплачено в строк | на 3-й і 7-й день | менеджер; клієнту — після погодження | чернетка ввічливого нагадування |
Правило для всіх сповіщень: кожне має конкретного адресата і конкретну дію. Повідомлення «сертифікат закінчується» в загальному чаті ніхто не відпрацює. Задача «запросити в постачальника новий сертифікат на серію, відповідальна Олена, до п’ятниці» — відпрацюють.
Типові помилки в реєстрі строків
- Одна дата на документ, хоча строків кілька. У договорі може бути строк дії і окремо строк для додаткової угоди з цінами.
- Сповіщення без статусу «на оновленні». Одне й те саме нагадування приходить щодня, і його починають ігнорувати разом з усіма іншими.
- Реєстр не пов’язаний з відвантаженням. Менеджер бачить попередження в Telegram, але облікова система пропускає накладну без жодних питань.
- Строки вводять вручну без скану. Через пів року ніхто не може підтвердити, звідки взялася дата в таблиці.
Як побудувати документообіг, коли документ проходить погодження кількох відділів, ми розбирали окремо — у статті про автоматизацію документообігу між відділами.
Заявки від аптек і клінік: фото списку, Excel і Viber в одному вході
Звідки приходять заявки і що з ними не так
Аптечна мережа надсилає Excel у своєму шаблоні. Приватна клініка пише в Telegram «як минулого разу, тільки рукавичок більше». Лікарня надсилає лист із PDF-специфікацією. Невелика аптека — фото рукописного списку. Кожен формат менеджер переносить вручну в облікову систему, паралельно перевіряючи залишки.
Помилки тут передбачувані: не та фасовка, не те дозування, пропущений рядок, серія з коротким строком для клієнта, який такі не приймає. Кожна з них — повернення, повторна доставка і незадоволений закупівельник.
Зверніть увагу: фото рукописного списку — це та сама задача, що й скан сертифіката. Якщо програма вміє надійно читати сертифікати, вона читатиме й заявки. Тому має сенс будувати один вхід для всіх документів, а не окремі інструменти для складу й для продажів.
Як ШІ розбирає заявку
- Повідомлення або файл потрапляє в одну чергу — з Telegram, пошти, форми на сайті.
- ШІ визначає клієнта й розбирає позиції: назва, форма, дозування, фасовка, кількість.
- Позиції зіставляються з вашим довідником товарів. Якщо одна назва має кілька фасовок, система не вгадує, а питає менеджера або уточнює в клієнта.
- На «як минулого разу» система підставляє попереднє замовлення клієнта і показує менеджеру різницю.
- Перевірки: залишок, серія з потрібним залишковим строком, ліцензія й договір клієнта, борг.
- Менеджер отримує чернетку замовлення і підтверджує її. Клієнт отримує підтвердження в той канал, звідки написав.
Ціну в такій схемі рахують формули й ваш прайс, а не ШІ. Він лише розуміє, що саме замовив клієнт, і готує чернетку. Детальніше про цей процес — на сторінці автоматизація заявок і замовлень і в статті про програму для обліку замовлень від заявки до оплати.
Коли автоматичному розбору не варто довіряти
Є ситуації, де заявка завжди йде людині, навіть якщо ШІ її впевнено прочитав:
- новий клієнт без картки, договору й перевіреної ліцензії;
- позиції немає в довіднику або вона збігається з кількома товарами;
- кількість помітно відрізняється від звичної для цього клієнта;
- препарати з окремим режимом обігу, наприклад наркотичні чи психотропні;
- термінове замовлення, де клієнт чекає дзвінка, а не повідомлення.
Ці правила записують під час опису процесу. Так система не намагається імпровізувати там, де помилка коштує дорожче за хвилину ручної роботи.
Зв’язок з BAS або 1С: не заміна, а надбудова
Облікову систему з багаторічною базою міняти не потрібно. Система управління бере на себе вхід — заявки, скани, перевірки, нагадування, — а в BAS чи 1С передає вже перевірене замовлення або отримує звідти залишки й серії. Як саме налаштувати обмін, залежить від конфігурації та її версії; це з’ясовують на етапі опису процесу, до початку робіт.
Так ми працюємо і в інших проєктах. Для виробника металоконструкцій ми не міняли систему, в якій уже працювали менеджери, а вбудувалися в неї: калькулятор передає заявки туди, де команда звикла працювати. Подібну логіку для оптових компаній загалом ми розбирали в статті ШІ для гуртової торгівлі, а про сусідню галузь — у статті про управління запасами дистриб’ютора FMCG.
Нагадування клієнтам: тиша, борг і закінчення договору
У B2B-дистрибуції пауза в замовленнях — сигнал, який легко пропустити. Аптека могла перейти до іншого постачальника, могла вичерпати бюджет, а могла просто забути. Менеджер, у якого кілька десятків клієнтів, тримати це в голові не може.
У нашій компанії з виробництва на верстатах з ЧПК система за перші тижні показала, куди йдуть замовлення. Одне з них ми програли саме тому, що вчасно не нагадали клієнту. Відтоді нагадування в нас — правило в системі, а не пам’ять менеджера.
Чотири тригери, які варто автоматизувати першими
- Клієнт замовк. Поріг залежить від ритму клієнта. Аптека, яка замовляє щотижня, і клініка, яка закуповує раз на квартал, не можуть мати однакового порогу. Система рахує звичний інтервал між замовленнями з історії і сигналізує, коли пауза помітно довша, наприклад удвічі.
- Договір закінчується. Нагадування менеджеру й клієнту заздалегідь, із чернеткою додаткової угоди.
- Новий товар або умови для категорії. Повідомлення лише тим клієнтам, які купували цю категорію, а не всім підряд.
- Рахунок не оплачено. Ввічливе нагадування знімає з менеджера незручний дзвінок. Як вибудувати це для оптової компанії — у статті про дебіторку в оптовій компанії.
Хто натискає «надіслати»
Найкраще працює режим чернетки. Система готує текст з ім’ям закупівельника, позиціями, які клієнт регулярно бере, і приводом для контакту. Менеджер переглядає й надсилає однією кнопкою. Повністю автоматичну відправку вмикають лише для простих випадків, які ви окремо погодили, наприклад для нагадування про оплату за шаблоном.
Так влаштовано і в системі управління Saloy: ШІ-асистент у призначений день пише клієнту в Telegram, розбирає відповідь і записує її в картку замовлення, а якщо відповідь неясна — перепитує. Менеджер бачить результат, а не веде листування вручну.
Канали і персональні дані
Закупівельники аптечних мереж частіше відповідають у Telegram чи Viber, державні заклади — email. Канал варто зберігати в картці кожного контакту, а не вгадувати. Листування з клієнтом про його замовлення, договір чи оплату — звичайна ділова комунікація. Масові рекламні розсилки — інша історія: тут обробка персональних даних контактних осіб має відповідати Закону «Про захист персональних даних», і краще заздалегідь узгодити це з юристом. Що врахувати, коли ШІ працює з даними клієнтів, — у статті про приватність і захист даних клієнтів.
Ці тригери — частина ширшої задачі: автоматизація відділу продажів без втрати живого контакту з клієнтом.
Як порахувати, чи потрібна вам автоматизація
Формула ручного часу
Порахуйте не «скільки коштує програма», а скільки годин на місяць команда витрачає на три потоки:
Години на місяць = (хвилини на заявку × заявок на день + хвилини на документи партії × партій на день + хвилини на нагадування і строки на день) × робочих днів ÷ 60.
Приклад для ілюстрації, не факт про конкретну компанію. Менеджери обробляють 40 заявок на день, по 6 хвилин на кожну, — це 240 хвилин. На складі приймають 8 партій на день, по 10 хвилин на документи, — ще 80 хвилин. На строки й нагадування йде пів години. Разом 350 хвилин, тобто майже 6 годин на день. За 21 робочий день — понад 120 годин на місяць.
Далі помножте години на вартість години праці: зарплата разом із податками, поділена на кількість робочих годин у місяці. Порівняйте результат із вартістю системи і підписки. Яку частину цих годин реально забере система, перевірте не за чужими відсотками, а на власних даних — під час двох тижнів паралельної роботи.
Що не видно у формулі
Години — лише частина картини. Ще дві статті втрат варто оцінити окремо:
- Ризик відвантаження без документів. Порахуйте, у що обійдеться один такий випадок: повернення партії, повторна доставка, час уповноваженої особи і юриста, можливі санкції. Навіть якщо таке трапляється рідко, один випадок може перекрити річну вартість контролю.
- Тихо втрачені клієнти. Візьміть клієнтів, які за минулий рік перестали замовляти, і помножте на середню річну маржу з такого клієнта. Якщо хоча б частину з них можна було повернути вчасним дзвінком, це прямі гроші.
Від чого залежать термін і обсяг робіт
- кількість типів документів, які треба розпізнавати;
- кількість каналів, звідки приходять заявки;
- чи потрібен обмін з BAS або 1С і яка у вас конфігурація;
- у якому стані реєстри: одна таблиця, кілька версій чи паперовий журнал;
- скільки ролей і правил блокування треба налаштувати.
Ціну ми називаємо після розмови й опису процесу, і вона фіксована. Опис процесу займає тиждень і зараховується у вартість запуску.
Коли вистачить готової програми, а коли потрібна система
Достатньо сканера і таблиці, якщо
- партій небагато, і документи приходять від двох-трьох постачальників;
- одна людина і приймає товар, і оформлює відвантаження;
- клієнтів мало, усі знайомі, а нових додається небагато.
Тут вистачить NAPS2 або сканера в телефоні, акуратної структури папок за серіями і таблиці строків з умовним форматуванням. Головне — домовитися про назви файлів і про те, хто вносить дату.
Достатньо ЕДО й облікової системи, якщо
- більшість постачальників і клієнтів уже обмінюються документами електронно;
- серії й строки придатності коректно ведуться в BAS або 1С;
- проблема лише в паперовому архіві, а не в заявках і нагадуваннях.
У такому разі розумніше доробити облікову систему: поле для скану сертифіката в картці серії і звіт про серії без документів.
Варто будувати систему, якщо
- документи й заявки приходять з кількох каналів одночасно;
- склад і менеджери працюють окремо, і перевірка документів випадає між ними;
- уже був випадок відвантаження без документа або втраченого через мовчання клієнта;
- реєстр строків існує в кількох версіях, і ніхто не впевнений, яка правильна.
Проміжні варіанти: no-code зв’язки і готова CRM
Зв’язки на make.com чи n8n швидко з’єднують пошту, таблицю й Telegram. Їхній мінус для регульованих документів — логіка розкидана по сценаріях, і немає одного місця, де менеджер бачить картку клієнта з усіма документами й історією. Порівняння цих інструментів — у статті Make, n8n чи Zapier.
Готова CRM добре веде воронку і клієнтів. Але реєстр серій із сертифікатами, перевірку ліцензії покупця при відвантаженні і реєстр реалізації за Порядком № 677 у ній доведеться будувати доробками. Якщо сумніваєтеся, пройдіть короткий тест готова CRM чи своя система.
Як ШІ-система управління бізнесом закриває весь ланцюжок
Що входить у систему для медичного дистриб’ютора
- Приймання партій: накладна постачальника, скани сертифікатів, чернетка з розпізнаними полями, підтвердження уповноваженою особою.
- Реєстр серій і документів: статус кожної серії, реєстр реалізації за період одним запитом.
- Клієнти: реквізити, контактні особи, договори, ліцензії, ліміти боргу, канал зв’язку.
- Заявки з усіх каналів: Telegram, пошта, форма на сайті — у чернетку замовлення.
- Документи: рахунок, видаткова накладна, акт, сума прописом, PDF; копії сертифікатів до відвантаження.
- Задачі й сповіщення в Telegram: строки, нагадування, ескалації конкретним людям.
- Ролі: склад, менеджер, уповноважена особа, власник. Кожен бачить своє.
- Звіти: заявки, відвантаження, серії без документів, клієнти, що замовкли.
Це не CRM і не ERP, а система управління під ваш процес. Основа — заявки, клієнти, замовлення з етапами, документи, вхід через Telegram, ролі, сповіщення, резервні копії — у нас уже готова й працює в наших проєктах. Під медичного дистриб’ютора додаються модулі приймання партій, реєстру серій і правил відвантаження.
Як ми її будуємо
Код пише штучний інтелект під контролем архітектора. Архітектор описує процес і критерії готовності, ШІ-агент пише код і тести, людина перевіряє все на реальних документах і замовленнях. Першу робочу версію ви бачите за кілька днів, уся система — за 2–4 тижні після опису процесу. Модулі підключаються по одному, і два тижні система працює паралельно зі старим способом.
Перенесення таблиць ми робимо зі звіркою на реальних прикладах. У проєкті калькулятора для виробника металоконструкцій розрахунок звірили з Excel-книгою на контрольних прикладах — збіглося до копійки. А в самій Excel-книзі знайшли помилки, які ми не виправляли мовчки, а передали інженеру. З реєстрами строків і сертифікатів працює те саме правило: розбіжності показуємо вам, а не ховаємо.
У системі управління Saloy є «ворота» перед цехом: якщо в замовленні лишилися відкриті питання до клієнта, система попереджає при спробі перевести його у виробництво. Там вона попереджає, а не блокує. Для медичного дистриб’ютора такі ворота перед відвантаженням логічно робити жорсткішими — це рішення ви ухвалюєте разом з уповноваженою особою. Як система Saloy будувалася тиждень за тижнем — у кейсі власної системи управління.
Система належить вам: код і дані ваші. Ставимо її на ваш сервер або на наш із передачею будь-коли, щодня робимо резервну копію. Контроль версій і бекапи — з першого дня: ми самі одного разу відновлювали модуль вручну після оновлення зі старої копії і відтоді цього не допускаємо.
Чесно про обмеження
- Ми не продаємо готовий фармацевтичний модуль. Ми будуємо систему під ваші правила, а тлумачення нормативних вимог лишається за вашою уповноваженою особою і юристом.
- ШІ помиляється на поганих сканах. Тому кожне розпізнане поле підтверджує людина, а нечитабельне не заповнюється навмання.
- Якщо партій мало і всі документи вже приходять через ЕДО, власна система може не окупитися. Тоді ми так і скажемо.
Якщо клієнти часто питають про доставку, оплату чи графік роботи, окремо можна підключити ШІ-бота для клієнтів. Пакет «Старт» — від 500 грн на місяць плюс разове підключення: Telegram-бот компанії, база знань, каталог із базовими цінами і передача складних питань менеджеру. Бот зі статусом замовлень і боргом конкретного клієнта налаштовуємо після розмови. Деталі — на сторінці ШІ-чатбот для сайту й месенджерів.
З чого почати: перші два тижні
- Зберіть реальні документи за місяць. Два-три десятки сертифікатів, накладних і заявок у різних форматах: фото, скани, Excel, повідомлення. Це матеріал для налаштування і для перевірки якості розпізнавання.
- Опишіть процес однієї партії. Хто приймає, хто перевіряє сертифікат, що має блокувати відвантаження, хто відповідає за ліцензії клієнтів. Допоможе шаблон опису процесу.
- Зведіть реєстр строків в одну версію. Перенесіть дати й скани з усіх таблиць і папок, позначте, де дати немає або вона не підтверджена документом.
- Запустіть один потік паралельно зі старим. Почніть із того, де найбільший ризик або найбільше ручної роботи: сертифікати на партії або заявки клієнтів.
- Через два тижні порівняйте. Скільки документів система розпізнала правильно, скільки виправляли, скільки часу пішло. На цих цифрах вирішуйте, що підключати далі.
Ширше про те, як обрати перший процес і не автоматизувати хаос, — у статті автоматизація бізнес-процесів: що автоматизувати першим. Якщо слабке місце — закупівлі й постачальники, подивіться матеріал про автоматизацію відділу постачання.
Часті питання
Чи можна зберігати сертифікати якості лише в електронному вигляді? Порядок № 677 дозволяє вести реєстри в електронному та/або паперовому вигляді, але копії сертифіката, які супроводжують серію, мають бути завірені печаткою останнього постачальника (текст наказу). Тож скан не скасовує паперовий документ, а робить його доступним для пошуку, перевірки і прив’язки до серії. Як саме зберігати оригінали й копії, узгодьте з уповноваженою особою.
Яку програму для сканування обрати, якщо поки потрібен лише архів? Для комп’ютера зі сканером підійде безкоштовна NAPS2 з розпізнаванням тексту, для складу — сканер у телефоні. Домовтеся про структуру папок за серіями й постачальниками і про правило назв файлів. Коли архівом почнуть користуватися менеджери для перевірки перед відвантаженням, переходьте до системи з реєстром.
Як система впишеться в нашу BAS або 1С? Вона не замінює облік, а працює поруч: приймає заявки й скани, перевіряє документи і строки, а в облікову систему передає перевірене замовлення або бере звідти залишки й серії. Спосіб обміну залежить від вашої конфігурації; ми з’ясовуємо це під час опису процесу, до початку робіт.
Що буде, якщо скан нечитабельний або заявка незрозуміла? Система не вгадує. Нечитабельне поле лишається порожнім, документ отримує позначку і потрапляє до відповідальної людини. Незрозумілу заявку ШІ може уточнити в клієнта в Telegram, а все, що виходить за межі описаних правил, передає менеджеру з контекстом.
Чи можна почати з одного процесу, а не з усього одразу? Так, і це рекомендований шлях. Кожен модуль — приймання партій, заявки, нагадування — працює окремо і підключається до наступного без переробки. Почніть із того, де вже був реальний збій.
Якщо ви постачаєте ліки, медичні вироби чи витратні матеріали і документи на партії досі живуть у папці зі сканами, опишіть, як у вас проходить одна партія — від приймання до відвантаження клієнту. Покажемо систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: сканер із таблицею, доробка облікової системи чи власна система. Детальніше — ШІ-система управління бізнесом.