Кейс · Аналіз тендерів і RFP · Ірландія
Тендерна команда витрачала дні найдорожчих людей на заявки, які однаково не мали шансів. Ми побудували продукт, що читає документи замість них, — і досі його розвиваємо, реліз за релізом, на постійному ретейнері.
Контекст
Публічні тендери й корпоративні RFP приходять не документом, а набором документів: оголошення, технічне завдання, додатки, шаблони відповідей, цінові таблиці й роз'яснення, які публікують уже посеред процедури. Вимоги, що вирішують долю заявки, розкидані по всьому набору.
Перш ніж команда напише бодай рядок, хтось має прочитати весь цей набір і відповісти на одне питання: чи варте це нашого часу? Відповісти добре — дорого, відповісти повільно — ще гірше: кваліфікація йде за тим самим годинником, що й дедлайн.
Клієнт прийшов до нас із цією задачею в масштабі й з баченням ринку: це не незручність однієї компанії, а те, як влаштований увесь тендерний процес. Саме тому відповіддю став продукт, а не внутрішній скрипт.
Виклик
Кожен тендер доводилося кваліфікувати вручну. Хтось із досвідчених людей проходив десятки вкладень у пошуках обов'язкових критеріїв, оцінюваних критеріїв, підстав для дискваліфікації та дрібного шрифту, який тихо виводить компанію з гри. Таке читання займало дні на один тендер.
Ціна цієї роботи — не лише години. Це ще й тендери, які пропустили, бо не було кому їх подивитися, і ті, які вели надто довго, поки хтось не помітив вимогу, що компанія не може виконати. У тендерній роботі пропущена вимога — це не дрібна шорсткість, а невідповідна заявка, хоч би якою сильною була пропозиція за нею.
Клієнту треба було стиснути читання настільки, щоб кваліфікація тендера перестала бути окремим рішенням, а команда витрачала експертизу на заявки, які справді варто писати.
Рішення
Ми побудували платформу AI-аналізу тендерів і RFP: користувач завантажує повний тендерний пакет, система його опрацьовує, а на виході — структурований аудит того, чого тендер насправді вимагає: вимоги, відсортовані за вагою, звірені між документами, і чітка картина того, чи підходить цей тендер.
Обмеженням, яке визначило все інше, була перевірюваність. Тендерна команда не може діяти на віру, тож результат зроблено так, щоб його перевіряли: рецензент підтверджує знайдене, а не перечитує весь пакет, і рішення про участь однаково ухвалює людина. Система прибирає читання, а не судження.
Це від початку будувалося як справжній продукт — акаунти, підписки й операційні частини, потрібні SaaS, щоб працювати без нас поруч, — і ми продовжуємо його розвивати після запуску, а не здали й пішли.
Клієнт конфіденційний на його прохання, і це стосується також механіки: як аналіз працює всередині — його справа, а не наша тема для публікації. Усе на цій сторінці — це те, що ми можемо сказати, не зачіпаючи його інтересів. Технології як допоміжна деталь: Claude, FastAPI, Next.js, pgvector на GCP і Stripe для оплат.
Читаєте тендерні пакети вручну? Скажіть, скільки їх і скільки часу йде на кожен.
Почати розмовуРезультат
Саме цю зміну дає продукт: кваліфікація тендера більше не є багатоденним читанням. На платформі в тому вигляді, як вона працює сьогодні, повний аудит завершується приблизно за 15 хвилин — зазвичай від 5 до 20, залежно від обсягу пакета документів.
Це два окремі чесні твердження, і ми свідомо тримаємо їх окремо. «Дні» — це ціна ручного перегляду, і вона залежить від пакета. «Близько 15 хвилин» — це те, скільки триває аналіз зараз. Ми не збираємося подавати це як одне заміряне порівняння «було/стало», бо ним воно ніколи не було.
Найтриваліший результат — той, який найважче вигадати: продукт у продакшені з активними користувачами, і клієнт продовжує платити нам місячний ретейнер за його розвиток. Софт, що витримав зустріч зі справжніми користувачами, і клієнт, який продовжує співпрацю, — це два докази, яким ми довіряємо найбільше.
Що змінилося
Тендер можна оцінити того ж дня, коли він надійшов, а не ставити в чергу до того, у кого знайдеться кілька вільних днів на читання. Пайплайн формує те, що варто вигравати, а не пропускна здатність перегляду.
Зобов'язання, від яких залежить відповідність, виходять із пакета на початку процесу, поки ще є час на дії, а не наприкінці, коли заявку вже пишуть.
Результат зроблено так, щоб його перевіряли: рецензія — це перевірка, а не друге повне читання. Саме це й робить команду готовою на нього спиратися.
Акаунти, підписки й підтримка на місці, тож система щодня обслуговує реальних користувачів, а не залежить від нашої доступності.
Запуск був початком роботи, а не її кінцем. Ми випускаємо функції й підтримуємо платформу на постійному місячному ретейнері.
Цифри на цій сторінці — чесні робочі діапазони з продукту, що працює. Там, де в нас немає заміру, ми так і кажемо, а не округлюємо на свою користь.
Наступний крок
Якщо ваша команда кваліфікує тендери вручну — або переглядає будь-який набір документів, де один пропущений рядок дорого коштує, — розкажіть, як цей процес виглядає сьогодні. Ми повернемося з тим, що аналіз реально дав би на ваших власних документах.
