Як підготувати комерційну пропозицію у безплатному сервісі, щоб вона не стала листом із ціною

Коли клієнт пише «скинь комерційну пропозицію», він найчастіше отримує файл, у якому є назва послуги й сума. Іноді туди ще додають логотип, абзац про компанію та підпис «з повагою». Формально це документ. Насправді це лист із ціною: він каже, скільки коштує щось, чого читач поки не бачить. Клієнт дивиться на цифру й змушений сам добудувати все інше — що саме він купує, де твоя робота починається, а де закінчується, і що станеться, якщо він відповість «добре».

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

Лист із ціною ще й непомітно перекладає ризик на тебе. Якщо в документі не написано, де межа твоєї роботи, клієнт цілком щиро вважатиме, що межі немає. Він попросить «ще трошки», потім «зовсім маленьку правку», і ти опинишся в ситуації, де формально пообіцяв суму, а фактично — нескінченний обсяг.

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

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

Результат — це те, що клієнт матиме на руках, коли ви закінчите. Не «розробка», не «супровід», а конкретний спостережуваний стан: працює інтеграція, налаштований звіт, запущений процес. Результат описується так, щоб його можна було впізнати, а не відчути.

Межі — це те, чого в роботі немає. Саме тут більшість пропозицій мовчить, і саме мовчання потім коштує найдорожче. Межа звучить прямо: «сюди входить одна форма, не три», «ми налаштовуємо, але не переносимо старі дані», «підтримка — до запуску, далі окремо». Межа не робить тебе жадібним. Вона робить тебе зрозумілим.

Залежності — це те, без чого ти не зможеш зробити свою частину. Доступи, відповіді, рішення на боці клієнта. Якщо цього немає в документі, будь-яка затримка виглядатиме як твоя провина, навіть коли ти тижнями чекав на пароль.

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

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

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

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

Друга річ ще важливіша для щоденної роботи. Якщо клієнт відповідає «згоден, але…» і щось міняє чи обмежує, це юридично не згода. Змінена або обмежена згода вважається відмовою в поєднанні з новою пропозицією. Тобто клієнт своїм «майже так» фактично зробив тобі власну зустрічну пропозицію, і тепер уже ти вирішуєш, приймати її чи ні. Це рятує від класичної плутанини, коли обидві сторони думають, що домовилися, а насправді кожна тримала в голові свою версію.

Для тебе це означає, що будь-яку правку клієнта треба ловити як окрему подію, а не як формальність. «Так, тільки без другого етапу» — це не прийняття твоєї пропозиції, це нова, і працювати за нею можна лише після твого явного «так» у відповідь.

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

Уяви — суто для наочності, це не реальний клієнт — що ти власник невеликого B2B-сервісу, який налаштовує автоматичні звіти для інтернет-магазинів. До тебе звертається керівник магазину: хоче «щоб дані самі збиралися в одну таблицю». Спокуса — відповісти листом: «Налаштування автозвітів — така-то сума». І все.

Тепер той самий запит, зібраний як пропозиція. Результат: щодня о восьмій ранку в спільній таблиці з’являється зведення продажів за попередній день. Це те, що клієнт упізнає без пояснень — він просто відкриє таблицю й побачить. Межі: ти підключаєш одне джерело даних, а не всі системи магазину; ти робиш один звіт, а не панель із десятьма графіками; історичні дані за минулі роки не переносиш. Залежності: клієнт дає доступ до свого облікового запису до старту робіт і призначає одну людину, яка відповідає на питання протягом дня.

Помічаєш, що в цьому прикладі немає жодної вигаданої цифри результату — ні «економія 40% часу», ні «зростання продажів». І це навмисно: обіцяти конкретний бізнес-ефект ти не можеш, бо він залежить від речей поза твоєю роботою. Ти обіцяєш робочий звіт у таблиці — рівно те, що справді контролюєш. Ціну ставиш після цього опису, і вона тепер читається як плата за окреслену роботу, а не як цифра з повітря.

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

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

Хороша новина: для цього не потрібен дорогий інструмент. Будь-який безплатний редактор документів, у якому можна створити файл, поділитися посиланням і зафіксувати версію, цілком годиться. Головне не в кнопках, а в тому, як ти організуєш документ.

Зроби структуру видимою. П’ять елементів — п’ять окремих блоків із заголовками: «Що ти отримаєш», «Що не входить», «Що потрібно з твого боку», «Вартість», «Як прийняти пропозицію». Коли розділ «що не входить» стоїть окремо і його видно, клієнт не зможе потім сказати, що не помітив межі. Ти не ховаєш обмеження в дрібний шрифт — ти ставиш їх поруч із результатом, як рівноправну частину домовленості.

Далі — версійність. Безплатні сервіси рідко мають розумне керування версіями, тому зроби його руками: назви файл із датою або номером, наприклад «Пропозиція v2, 27 липня». Це дрібниця, яка рятує, коли ви обмінялися трьома правками і вже не пам’ятаєте, яку саме суму й обсяг обговорювали в живій розмові тиждень тому. Точна версія — це не педантизм, це те, на що ви обоє потім посилаєтеся.

Уникай прийому «залишу поле для маневру». Спокуса написати обтічно, щоб потім домовитися, насправді працює проти тебе: розмите формулювання читач тлумачить на свою користь, а зв’язаний своєю пропозицією — ти. Тому краще вузько й чесно, ніж широко й на всяк випадок.

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

Остання частина — та, заради якої все й затівалося. Пропозиція перестає бути просто гарним описом, коли в ній є чітка подія прийняття: конкретна дія, яка означає «так, працюємо на цих умовах». Без неї ти залишаєшся в підвішеному стані, де клієнт начебто згоден, але ніхто не назвав момент, з якого домовленість діє.

Опиши цю подію прямо в документі. Наприклад: щоб прийняти пропозицію, клієнт відповідає в листуванні словами «приймаю версію v2» — і ви починаєте. Тепер прийняття — не туманне «ну давай», а впізнаваний факт. Ти знаєш, коли угода є, а клієнт знає, що саме він підтверджує. І, головне, ви обидва посилаєтеся на одну названу версію, а не на різні спогади про розмову.

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

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

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