From Lead to Client: RFI, RFC, RFQ and Proposal

Що в цьому розділі

Попередній розділ завершився моментом, коли після конференції, виставки, публікації або іншого контакту компанія отримала лід і домовилася про наступну розмову. У цьому розділі розглядається те, що відбувається далі: як лід перевіряє постачальника, як сервісна компанія уточнює реальну проблему, які документи з’являються у pre-sale engineering і як із цього формується технічний Proposal.

Лекція проходить шлях від initial meeting до технічних follow-up зустрічей, RFI, RFQ та RFC, а потім розбирає Proposal як інтегруючий документ: його версіонування, структуру, архітектурний опис, план реалізації й V&V, команду, матеріальні ресурси, timeline та ризики.

Ключова теза: лід стає клієнтом не після красивої презентації, а після послідовності перевірок, у якій постачальник показує релевантний досвід, правильно виявляє pain point і формує рішення, яке можна обговорювати, оцінювати та змінювати по версіях.

4.1. Конференція як перехід від видимості до реального ліда

Лекція починається з продовження теми конференцій. Велика індустріальна подія має два різні ефекти:

visibility — компанію й технічних представників починають впізнавати;
lead generation — команда знаходить конкретну компанію з конкретною проблемою і домовляється про follow-up.

Сам по собі booth, доповідь або присутність на конференції не створює бізнесу. Команда повинна активно шукати потрібних людей, збирати тренди, слухати проблеми продуктових компаній і швидко показувати релевантні інженерні артефакти: фотографії прототипів, стендів, плат, випробувань або інші докази реальної роботи.

Speaker підсилює цю механіку. Його функція — створити публічну довіру і впізнаваність, після чого команда використовує цей кредит довіри для контакту з аудиторією. Тема доповіді при цьому обирається не лише за експертністю конкретної людини, а як бізнес-рішення: за трендами, запитами ринку, цільовими компаніями й потенційною віддачею від поїздки.

У лекції підкреслюється, що такі поїздки можуть коштувати десятки тисяч євро, тому їхній сенс оцінюється не кількістю контактів, а тим, чи з’явилися якісні follow-up розмови.

4.2. Лід — це право на наступну зустріч

Після першого контакту головний результат — не «продаж», а домовленість про follow-up meeting у ширшому складі.

У курсі використовується практичне правило: значна частина лідів відпаде, і лише частина перетвориться на реальних клієнтів. Тому перша формальна зустріч має дуже високу вагу. Її мета — відповісти на питання потенційного клієнта:

Чи це люди, з якими я готовий продовжувати технічну й бізнес-розмову?

До зустрічі команда проводить research по компанії та учасниках. Вивчаються ролі, професійний досвід, напрямки діяльності й можливі технічні інтереси. Ця інформація використовується для того, щоб правильно підібрати людей зі свого боку і не приводити на зустріч випадкову команду.

4.3. Initial meeting: компанія, довіра і релевантні кейси

Типова перша зустріч містить коротке представлення обох компаній. Зі сторони постачальника презентація має три основні частини:

Хто ми. Локації, масштаб, роки роботи, напрямки, відомі клієнти — тільки те, що дозволено розкривати.
Чому нам можна довіряти. Сертифікації компанії, стандарти, сертифікації ключових спеціалістів, процеси й інші trust signals.
Що ми вже робили. Кілька релевантних кейсів, які показують проблему, підхід, результат і практичний досвід.

Кейсів не повинно бути занадто багато. У лекції рекомендується орієнтуватися приблизно на 6–7 релевантних прикладів, а всю презентацію тримати компактною — порядку 10–15 слайдів. Надлишок кейсів розмиває увагу і зменшує шанс, що клієнт упізнає власну проблему.

Саме тому research перед зустріччю критичний: він дозволяє вибрати не «найкрасивіші» кейси компанії, а ті, які найближчі до контексту конкретного ліда.

4.4. Краще, коли клієнт говорить першим

Якщо є можливість, корисно дати потенційному клієнту представити себе першим. Тоді команда постачальника отримує кілька додаткових хвилин, щоб адаптувати свою презентацію і підсилити ті кейси, які виявилися релевантними прямо під час розмови.

На практиці це не завжди можливо: обидві сторони розуміють цю перевагу. Тому важливо бути готовим до обох порядків.

Навіть після презентації клієнт часто не скаже прямо: «нам болить ось це». Тому головна технічна робота починається в дискусії після формальних слайдів.

4.5. Глибоке технічне питання як інструмент виявлення pain point

Після презентацій не можна залишатися на рівні загальних питань. Технічний представник постачальника повинен поставити достатньо конкретне питання, яке показує розуміння домену, але не виглядає як спроба принизити або перевірити компетентність клієнта.

Правильне питання має:

стосуватися реальної технічної проблеми в домені;
бути достатньо глибоким, щоб продемонструвати експертність;
бути сформульованим так, щоб клієнт міг безпечно розповісти про складність;
створювати місток до наступної технічної зустрічі.

Якщо клієнт відповідає: «так, ми з цим стикалися» або описує тимчасове рішення, команда знайшла pain point. Саме навколо нього можна будувати наступний follow-up.

4.6. Мета першого follow-up — знайти тему другого

На першому formal meeting не потрібно намагатися одразу «закрити угоду». Нормальний результат зустрічі:

команди познайомилися
      ↓
постачальник показав релевантний досвід
      ↓
клієнт розкрив область інтересу / pain point
      ↓
узгоджено тему наступної технічної зустрічі

Другий meeting уже не повторює корпоративні слайди. На нього приводять профільних експертів, здатних говорити безпосередньо про проблему.

При цьому core-люди першого контакту мають залишатися в комунікації. Це може бути engager, людина з конференції, автор публікації або інший представник, з якого почалася довіра. Нові експерти додаються, але знайомі обличчя не зникають без потреби.

4.7. Другий follow-up: не вирішити проблему, а довести спроможність

Мета другої технічної зустрічі — не безкоштовно спроєктувати клієнту продукт. Її мета — переконати, що у постачальника є:

потрібний профіль експертів;
реальний досвід;
здатність розкласти проблему на інженерні задачі;
культура взаємодії, з якою можна працювати далі.

Після успішної технічної розмови починається стадія формалізації: клієнт просить інформацію, оцінку або уточнення. Тут з’являються RFI, RFQ і RFC.

4.8. RFI — Request for Information

RFI (Request for Information) — запит на інформацію про постачальника, його технології, процеси, інструменти та спроможності.

Для embedded-компанії RFI може містити десятки або сотні запитань, наприклад:

які CAD/CAE/EDA інструменти використовуються для механіки й hardware;
які мови, middleware, RTOS або embedded Linux стек використовуються;
які стандарти, guidelines і процесні frameworks застосовуються;
як організовано functional safety та cybersecurity;
з якими MCU/SoC і платформами є досвід;
як виготовляються PCB, корпуси та кабельні джгути;
що робиться in-house, а що через vendor network;
як організовано логістику, assembly, delivery та quality assurance.

RFI перевіряє не одну технологію. Він перевіряє, чи є у компанії відтворювана інженерна система, здатна стабільно доставляти фізичний embedded-виріб.

4.9. RFQ — Request for Quotation

RFQ (Request for Quotation) — запит на комерційну оцінку: скільки часу й грошей потрібно для виконання роботи.

В embedded-проєкті RFQ складніший, ніж у суто software development. Крім engineering time, оцінюються:

закупівля електронних компонентів;
виробництво PCB;
assembly / soldering;
виготовлення механічних частин;
кабельні джгути;
тестове обладнання;
доставка між країнами й vendor locations;
митні процедури;
повторні hardware iterations;
зовнішні лабораторії та сертифікація.

Найкраще, коли RFQ приходить після достатнього технічного уточнення. Але іноді клієнт надсилає RFI і RFQ майже одночасно. У лекції це трактується як ознака того, що opportunity вже може проходити через procurement / tender process і постачальників порівнюють між собою.

У такій ситуації оцінка завжди містить більше невизначеності, тому assumptions і risks мають бути зроблені видимими, а не схованими всередині одного числа.

4.10. RFC — Request for Clarification

У термінології цього курсу RFC (Request for Clarification) — технічний запит, який описує, що саме потрібно клієнту, і просить постачальника сформувати бачення рішення.

RFC може бути двох типів.

Варіант A — короткий problem statement

Клієнт дає кілька речень: що має робити пристрій, у яких умовах, з якими основними характеристиками. Це залишає постачальнику великий простір для вибору архітектури, технологій і способу реалізації.

Варіант B — структурований набір вимог

Клієнт передає System / Hardware / Software / Mechanical requirements. Тоді простір рішень вже суттєво обмежений, і від постачальника очікується не стільки discovery, скільки якісна імплементація в заданих рамках.

Обидва формати можуть бути корисними. Короткий RFC дає більше свободи, а деталізований — більше визначеності й, зазвичай, означає наявність технічного owner на стороні клієнта.

4.11. Proposal — відповідь, що інтегрує попередню комунікацію

Відповіддю на технічне уточнення стає Proposal — документ, який описує запропонований спосіб вирішення проблеми.

Proposal не повинен жити окремо від попередніх кроків. Він інтегрує те, що вже було проговорено в RFI, RFQ, RFC і meetings:

RFI ─┐
RFQ ─┼──> Proposal
RFC ─┤
meetings ─┘

У Proposal входять:

бачення продукту й архітектури;
підходи й інструменти;
implementation strategy;
verification & validation;
команда й ролі;
матеріальні ресурси;
time / cost estimate;
assumptions;
risks і mitigations;
рекомендації та альтернативи.

Це ще pre-sale робота. Її вартість часто не виставляється клієнту окремо, тому важливо контролювати, скільки глибини компанія безкоштовно віддає до контракту.

4.12. Version control Proposal

Proposal — керований документ. У лекції пропонується просте правило версій:

0.x — внутрішні ітерації до першої передачі клієнту;
1.0 — перша релізна версія, передана клієнту;
1.x — внутрішні доопрацювання після feedback до наступного зовнішнього релізу;
2.0, 3.0, … — наступні версії, повторно передані клієнту.

Приклад:

0.1 → 0.2 → 0.3 → 1.0
                      ↓ client feedback
                    1.1 → 1.2 → 2.0

Поруч з version number мають бути автор, дата й change history. Клієнт повинен бачити, що змінилося між релізами і чому.

Окремо в лекції підкреслюється роль критичного внутрішнього reviewer. Його задача — не лише знайти помилки, а й не допустити ситуації, коли компанія без контракту віддала занадто багато готового engineering work.

4.13. Перші розділи Proposal: summary, introduction, revision history, references

Хоча формат Proposal може відрізнятися, лекція пропонує стабільний інформаційний каркас.

Summary

Приблизно одна сторінка, орієнтована на business reader:

що пропонується;
який очікуваний outcome;
орієнтовні time/cost рамки.

Introduction

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

Document identification and revision history

Version, author, date, communication owners і короткий список істотних змін від попереднього зовнішнього релізу.

Terminology and abbreviations

Proposal має бути достатньо автономним. Специфічні терміни й скорочення не повинні вимагати від читача здогадуватися, що мав на увазі автор.

References

Стандарти, guidelines, frameworks та інші зовнішні документи, на яких базується запропонований процес або design. Для safety-critical доменів traceability до нормативної бази особливо важлива.

4.14. Engineering core: architecture → implementation → V&V

Після преамбули починається технічне ядро Proposal.

Architecture

Спочатку показується high-level vision майбутнього продукту. Якщо це фізичний embedded-виріб, варто дати візуальну інтерпретацію того, що клієнт отримає в кінці, а потім — структурну схему і decomposition на компоненти.

Хороша architecture section відповідає на два питання:

Як виглядає кінцевий продукт на високому рівні?
З яких великих компонентів він складається і як вони взаємодіють?

Implementation

Кожний архітектурний компонент стає окремою інженерною задачею. Для нього описуються:

технології й інструменти;
спосіб реалізації;
залежності;
можливі alternatives;
за можливості — маленький feasibility experiment або PoC.

Залучення клієнта до вибору між обґрунтованими альтернативами підвищує ownership технічних рішень і зменшує ризик несподіваного reject наприкінці.

Verification & Validation

Proposal має показати не тільки «як ми зробимо», а й «як ми доведемо, що це працює». Для embedded це може включати:

static analysis;
unit tests;
integration tests;
regression / performance tests;
hardware-in-the-loop або bench testing;
testing on real hardware;
acceptance / validation activities.

4.15. Resources: команда, vendors і матеріали

Після технічної частини рішення переводиться у ресурси.

Людські ресурси

Ролі можуть включати:

project / delivery management;
system architect / system engineer;
mechanical engineer;
hardware engineer;
firmware/software engineer;
reviewers / cross-check roles;
зовнішніх domain experts.

Важливо вказувати не просто список людей, а відсоток їхньої залученості й періоди, коли вони потрібні. Не кожна роль має бути full-time протягом усього проєкту.

Vendors

Частина фізичної роботи може виконуватися зовнішніми партнерами: PCB fabrication, assembly, machining/3D printing, harness manufacturing, certification laboratories тощо. Proposal повинен показати, де проходить межа між in-house і external work.

Materials

Для embedded-проєкту materials — це не декоративний рядок у кошторисі. Це компоненти, PCB, корпуси, harnesses, test equipment, packaging, shipment, customs, certification samples і повторні ітерації прототипів.

У лекції особливо підкреслюється: не варто планувати hardware як одноразову закупівлю. Реалістичніше передбачити кілька ітерацій, бо перший фізичний виріб рідко одразу стає фінальним.

4.16. Timeline, dependencies, Gantt і risks

Embedded development майже завжди складається з кількох паралельних stream:

system engineering / requirements;
hardware;
mechanics;
firmware/software;
integration and verification;
procurement / manufacturing / logistics.

Частина робіт може йти паралельно, але між ними є dependencies. Наприклад, механік потребує board outline, firmware — prototype hardware, integration — і hardware, і software, а testing — готовий test setup.

Тому Proposal повинен містити timeline, який показує:

коли стартують і завершуються workstreams;
де є dependencies;
коли потрібні конкретні ролі;
до яких дат повинні прибути матеріали й обладнання;
де знаходиться critical path;
які ризики можуть зсунути графік.

Для цього природним інструментом є Gantt chart або еквівалентна timeline visualization.

Risk analysis має охоплювати не тільки engineering uncertainty, а й фізичний світ: availability компонентів, vendor lead time, shipping, customs, повторні fabrication cycles, certification, зовнішні лабораторії та інші фактори, здатні зупинити проєкт.

4.17. Повний pre-sale шлях

Лекцію можна звести до такого ланцюга:

contact / event / publication
          ↓
         LEAD
          ↓
initial meeting
          ↓
pain point discovery
          ↓
technical follow-up
          ↓
RFI / RFQ / RFC
          ↓
Proposal 0.x
          ↓
internal review
          ↓
Proposal 1.0
          ↓
client feedback + iterations
          ↓
commercial / technical decision
          ↓
CLIENT / PROJECT START

Цей шлях не завжди проходиться буквально в такому порядку. Документи можуть приходити паралельно, деякі етапи можуть бути об’єднані або пропущені. Але логіка залишається: від довіри → до уточнення → до доказу спроможності → до формалізованого рішення й оцінки.

4.18. Ключові терміни

Код	Термін	Значення в цьому курсі
Т-4.1	Initial meeting	Перша формальна зустріч після того, як контакт став лідом
Т-4.2	Follow-up meeting	Наступна зустріч, присвячена вже конкретнішій темі або pain point
Т-4.3	RFI	Request for Information — запит про спроможності, технології, процеси та інструменти постачальника
Т-4.4	RFQ	Request for Quotation — запит на часову/вартісну оцінку робіт і матеріалів
Т-4.5	RFC	Request for Clarification — у термінології лекції запит, що формалізує задачу і потребує технічного бачення постачальника
Т-4.6	Proposal	Версійно керований документ із баченням рішення, архітектурою, реалізацією, V&V, ресурсами, estimate і risks
Т-4.7	Pain point	Конкретна проблема або ризик клієнта, навколо якого формується наступна технічна взаємодія
Т-4.8	Assumption	Явне припущення, на якому базується оцінка або архітектурне рішення
Т-4.9	V&V	Verification & Validation — перевірка правильності реалізації та відповідності потребі
Т-4.10	Gantt chart	Візуальне подання робіт, часу, залежностей і паралельних stream

4.19. Контрольні запитання

Чому контакт із конференції ще не є клієнтом і який результат переводить його в стадію реального ліда?
Які три блоки має покривати презентація сервісної компанії на initial meeting?
Чому 6–7 релевантних кейсів можуть бути сильнішими за десятки прикладів із корпоративного портфоліо?
Яку перевагу дає ситуація, коли потенційний клієнт представляє свою компанію першим?
Яким має бути технічне питання, щоб виявити pain point і не перетворити зустріч на екзамен клієнта?
Який правильний outcome першого follow-up meeting?
Чому core-учасники першого контакту мають залишатися в подальших зустрічах?
Чим RFI відрізняється від RFQ у контексті embedded engineering?
Які physical-development витрати потрібно врахувати в RFQ, крім часу інженерів?
Порівняйте короткий RFC/problem statement і структурований set of requirements.
Чому Proposal повинен бути узгоджений із попередніми RFI/RFQ/RFC та meetings?
Поясніть логіку 0.x → 1.0 → 1.x → 2.0 для version control Proposal.
Які дані мають бути в Summary і Introduction Proposal?
Навіщо показувати в Proposal візуальну та структурну architecture view?
Чому V&V потрібно описувати ще на pre-sale стадії?
Як відсоток залученості ролей впливає на cost model команди?
Чому procurement, manufacturing і logistics повинні бути частиною timeline embedded-проєкту?
Які ризики hardware development неможливо побачити, якщо оцінювати тільки engineering hours?

4.20. Примітки редактора

Організаційна частина вилучена. Із транскрипту не перенесені перевірка звуку, повідомлення щодо повітряної тривоги, номер кабінету, перерва та інші організаційні репліки, які не є змістом лекції.
Імена студентів знеособлено. Репліки аудиторії не прив’язані до конкретних студентів.
Лекція 04 частково продовжує тему конференцій із Р3. У конспекті цей вступ збережено лише настільки, наскільки він пояснює перехід від lead generation до pre-sale.
RFI / RFQ / RFC. Назви й порядок цих документів можуть відрізнятися між компаніями й procurement-процесами. Тут терміни відтворено саме в логіці лекції; зокрема RFC використано як Request for Clarification.
Proposal не має одного універсального industry template. Описана структура — практичний каркас автора для engineering-service pre-sale, а не нормативний стандарт.
Versioning 0.x / 1.0 / 2.0. Це рекомендована робоча схема з лекції, а не обов’язкова вимога систем контролю документів.
Стандарти й відповідальність. У лекції стандарти описані як важливий інструмент керування ризиками й доказу належного engineering process. Сам факт дотримання стандарту не слід трактувати як автоматичне звільнення від юридичної відповідальності; конкретні наслідки залежать від юрисдикції, продукту та контракту.
Вартість конференцій і conversion heuristics. Числові оцінки наведені як досвід автора, а не як універсальні market benchmarks.
Named-company examples. Назви компаній та інструментів із усної лекції не використано як незалежно перевірені ринкові твердження; у структурований конспект винесено лише навчальну логіку.
Наступний блок курсу. Фінальна частина лекції підводить до окремої теми planning: team setup, dependencies, timeline, Gantt і risk analysis.