Розбір must / should / nice
Кожна вимога, витягнута з усього пакета документів і відсортована за вагою: спершу жорсткі критерії допуску, далі оцінювані критерії, наприкінці — побажання.
Будуємо AI-системи аналізу тендерів, які читають увесь пакет документів — оголошення, технічне завдання, цінові таблиці, кожен додаток — і дають вашій команді структурований аудит вимог та чітке рішення go/no-go. Ви вирішуєте, чи вартий тендер зусиль, ще до того, як витратите на це тиждень.
Виклик
Один публічний тендер або корпоративний RFP зазвичай приходить як три десятки файлів: оголошення, технічне завдання, додатки, шаблони відповідей, цінові таблиці, роз'яснення, опубліковані вже посеред процедури. Обов'язкова вимога може ховатися в дрібному шрифті будь-якого з них. Пропустили одну — заявка невідповідна, хоч би якою сильною була пропозиція.
Тож хтось із досвідчених людей читає це все вручну й під дедлайн. А потім те саме для наступного тендера, і для ще одного. Здебільшого цей час іде на заявки, які компанія однаково не мала шансів виграти.
Чому універсальні інструменти не закривають розрив. Команди, які беруться зробити це власними силами, зазвичай доходять до інструмента, який працює «загалом правильно», і там застрягають — бо в тендерній роботі «загалом правильно» не рахується. Пропущена або хибно прочитана вимога — це дискваліфікована заявка, тож практична планка — 95–100% покриття, і саме на цьому останньому відрізку внутрішні розробки найчастіше зупиняються.
Що ви отримуєте
На виході — не короткий переказ, а робочий документ, який зводить кожне зобов'язання з тендера до рішення, яке має ухвалити ваша команда.
Кожна вимога, витягнута з усього пакета документів і відсортована за вагою: спершу жорсткі критерії допуску, далі оцінювані критерії, наприкінці — побажання.
Вимоги звіряються між оголошенням, технічним завданням, додатками та роз'ясненнями, тож суперечності й дублювання спливають, а не залишаються непоміченими.
Кожна вимога посилається на місце, звідки її взято, тож рецензент перевіряє рядок за секунди, а не перечитує весь пакет.
Що ви точно виконуєте, що частково, а що — ні. Саме цей короткий список і визначає розмову «беремося чи ні».
Один зрозумілий звіт з обґрунтуванням рекомендації — готовий покласти на стіл тому, хто ухвалює рішення про участь.
Віддаємо там, де команда вже працює: внутрішній інструмент, експорт або інтеграція із системою, в якій ви ведете заявки сьогодні.
Рішення про участь усе одно ухвалює людина. Система прибирає читання, а не судження.
Надішліть нам один тендерний пакет. Покажемо, як на ньому виглядає аудит.
Почати розмовуЗ нашої роботи
Аналіз тендерів і RFP · Ірландія
Це робота для клієнта, тож назва продукту, компанія та внутрішня механіка аналізу залишаються конфіденційними. Час — це чесні робочі діапазони, а не одне заміряне «було/стало».
Ми готуємо публічне демо, де ви зможете самі прогнати тестовий тендер через аналіз. Поки його немає, покажемо все на дзвінку — на ваших документах, а не на заготовленому прикладі.
Як працюємо разом
Ми не продаємо один-єдиний формат проєкту. Тендерна робота значно частіше починається з малого, ніж з великого.
Для чітко визначеної роботи — аудит одного тендерного пакета, прототип на ваших власних заявках. Домовляємося про результат наперед, оцінюємо кожну функцію й намагаємось утриматись у межах 20% від оцінки.
Для більших чи менш визначених задач: платний Discovery (3–5 днів, $1,500–3,000, ціна фіксується наперед) → матеріали, план і оцінена пропозиція. Матеріали лишаються вам у будь-якому разі.
Для платформи заявок, що розвивається постійно: місячний ретейнер зарезервованих днів на функції та підтримку — так ми ведемо наш найдовший проєкт зараз.
FAQ
Структурований аудит вимог — розбір must/should/nice, перехресні перевірки по всьому пакету документів, картину відповідності та прогалин — і звіт go/no-go з обґрунтуванням. Там, де це має сенс, віддаємо це як інструмент, яким команда користується сама, а не як разовий документ.
Хвилини, а не дні. На платформі, яку ми супроводжуємо сьогодні, повний аудит займає близько 15 хвилин, зазвичай 5–20 — залежно від обсягу пакета документів.
Саме це обмеження й визначає дизайн. Вимоги звіряються між документами, кожна посилається на джерело, тож команда перевіряє, а не перечитує, і рішення про участь завжди ухвалює людина. Планку точності узгоджуємо з вами наперед і перевіряємо на ваших минулих тендерах — ми не обіцяємо цифр, яких не заміряли на ваших документах.
Це звичайна ситуація, і саме тому цю роботу варто автоматизувати. Великі різнорідні пакети — оголошення, технічне завдання, додатки, шаблони відповідей, цінові таблиці, пізніші роз'яснення — це те, заради чого такі системи й будують.
Так. Віддаємо результат туди, де команда вже працює: внутрішній інструмент, експорт у ваші шаблони або інтеграція із системою, в якій ви ведете заявки сьогодні.
Так, і ми можемо піти далі за стандартну угоду: якщо ваші документи не можуть залишати вашу мережу, розгортаємо аналіз на вашій власній інфраструктурі, і нічого не йде до зовнішнього сервісу.
Оцінюємо кожну функцію наперед і намагаємось утриматись у межах 20% від оцінки. Для більших чи менш визначених задач спершу проводимо платну фазу аналізу, а тоді оцінюємо розробку, коли обсяг стає зрозумілим.
Наступний крок
Скажіть, скільки заявок ваша команда переглядає на місяць і скільки часу йде на кожну. Ми повернемося з тим, як виглядав би аудит на ваших документах.