Повна версія українською — для Project Knowledge, сайту, або поширення.
- Claude — це не «ще один ChatGPT». Anthropic явно тренує модель на XML-теги як first-class citizens, на адаптивне «thinking», на буквальне виконання інструкцій і на роботу з документами 200K–1M токенів. Промпт, що працює в ChatGPT, у Claude часто дає посередній результат — і навпаки: добре структурований Claude-промпт (role → context → task → constraints → format → examples → reasoning) дає вихід на рівні мідл-стратега вже у першій ітерації.
- «Хороший промпт» від «великого» відрізняє системність, а не довжина. Великий промпт = (1) явно призначена роль/seniority, (2) структуровані XML-блоки даних, (3) 3–5 few-shot прикладів у
<example>тегах, (4) контекст «вище за запит» (long-form data на початку), (5) прямі вимоги «be opinionated, no hedging», (6) reasoning-інструкція (<thinking> → <answer>), (7) явна заборона generic-патернів.
- Реальна перевага Claude для маркетингу — у трьох речах: аналіз довгих масивів (транскрипти інтервʼю, експорти GA4/Search Console, контентні бібліотеки на 50+ матеріалів); нюансований brand voice і tone-of-voice; складна логіка з критикою власних аргументів. Це робить його ідеальним для стратегічних задач — позиціонування, ICP, brand voice audit, funnel diagnosis — а не для генерації «постів у LinkedIn».
Що Anthropic офіційно рекомендує (2025–2026)
З docs.claude.com / platform.claude.com/docs/build-with-claude/prompt-engineering — єдиний живий референс для Claude Opus 4.6/4.7, Sonnet 4.6, Haiku 4.5:
- «Золоте правило»: покажіть промпт колезі без контексту. Якщо він плутається — Claude теж плутатиметься. Claude — це «brilliant new employee».
- XML-теги — рекомендований delimiter. Cite з AWS-cookbook Anthropic: «We recommend that you use specifically XML tags as separators for Claude, as Claude was trained specifically to pay attention to XML tags». Тегів «правильних» немає — назви відповідають змісту (
<context>, <task>, <constraints>, <examples>, <output_format>, <thinking>, <answer>).
- Long-form data — на початок промпту. Anthropic вказує, що розміщення довгих документів перед запитом покращує якість відповіді до 30% у тестах із multi-document inputs.
- Ground responses in quotes: для довгих документів просіть Claude спочатку процитувати релевантні фрагменти, потім аналізувати — це фільтрує шум.
- Role у system prompt — навіть одне речення суттєво змінює якість («Ти — досвідчений data scientist…» vs «Ти — старший маркетинг-стратег…» дадуть різні інсайти на тих самих даних).
- Chain-of-Thought має три рівні: базовий («думай step-by-step»), guided (нумеровані кроки), structured (з
<thinking> і <answer>тегами). Без output thinking — немає thinking.
- Few-shot — 3–5 прикладів у
<examples> з підтегами <example>. Diverse + canonical, не «laundry list of edge cases».
- Claude 4.6/4.7 виконує інструкції буквально. Не «узагальнює» приховано. Це плюс для пайплайнів, мінус — для нечітких промптів. Завжди явно вказуйте scope («apply to every section, not just the first»).
- Tone: 4.7 — «more direct and opinionated, less validation-forward, fewer emoji». Якщо потрібен тепліший — пишіть це явно.
- Skills > Prompts для повторюваних задач. SKILL.md — це інструкція, що автоматично активується при матчингу.
Анатомія «великого» Claude-промпту (7 структурних елементів)
1. ROLE → системний промпт або <role>...</role>
2. CONTEXT → довгі дані вгорі, у <context> або <document_content>
3. TASK → одна чітка задача в <task>
4. CONSTRAINTS → що НЕ робити, у <constraints> (позитивні формулювання)
5. OUTPUT FORMAT → структура в <output_format>
6. EXAMPLES (3–5) → <examples><example>...</example></examples>
7. REASONING → інструкція «спочатку <thinking>, потім <answer>»
Поганий промпт: «Зроби SWOT для нашого SaaS, ми конкуруємо з Asana». Великий промпт: дотримується всіх 7 елементів — і Claude видає рівень, який раніше коштував €5000 за два тижні консультантської роботи.
8 production-ready промптів для digital-стратега
Як використовувати: завантажте промпт у Claude Project. У Project Knowledge киньте: brand voice doc, ICP doc, sitemap CSV, 3–5 best-performing матеріалів. Так кожен новий чат отримує контекст без повтору.
Промпт 1. Діагностика ICP з реальних customer-даних (не з повітря)
Проблема: більшість агенцій складає ICP «зі стелі» з демографії. Це не working ICP — це сценарна вправа. Working ICP видобувається з voice-of-customer мови.
<role>
Ти — старший B2B-стратег з позиціонування, навчений
у методології April Dunford та Jobs-to-be-Done.
Маєш 15+ років досвіду витягування психології
покупця з сирих якісних даних. Скептичний,
категоричний, відмовляєшся вигадувати деталі,
яких немає у даних.
</role>
<context>
Ми — українсько-польська digital-агенція, позиціонована
на «епістемічну якість» та «сайт як ядро системи».
Продаємо власникам бізнесу і CMO, які приймають
рішення, не junior-маркетологам. Середній цикл угоди
[X місяців], середній чек [Y EUR].
</context>
<source_data>
<sales_calls>
[Вставити 5–10 очищених транскриптів
або summary-нотаток]
</sales_calls>
<support_tickets>
[20+ тикетів / питань від
потенційних клієнтів]
</support_tickets>
<won_deals_notes>
[Внутрішні нотатки чому купили]
</won_deals_notes>
<lost_deals_notes>
[Чому НЕ купили — це золото]
</lost_deals_notes>
<reviews>
[G2, Clutch, LinkedIn testimonials]
</reviews>
</source_data>
<task>
Побудуй ICP на основі поведінки покупців, не демографії.
</task>
<instructions>
1. Спочатку, у <thinking>-тегах, процитуй 8–12 точних
фраз із вхідних даних, які повторюються або несуть
емоційну вагу. Познач кожну: [біль] [мрія]
[заперечення] [тригер] [жаргон].
2. Виокрем 2–3 поведінкові сегменти (НЕ галузеві).
Розрізняй їх за тим, ЯК вони купують, не як виглядають.
3. Для кожного сегмента:
- "Людина в русі" в одному реченні (що запустило пошук)
- 3 ключові болі з verbatim-цитатами (без перефразу)
- Voice-of-customer банк фраз (8–10 точних)
- Мапа заперечень: 3 явні + 2 неявні/імпліцитні
- Anti-ICP сигнал (хто ВИГЛЯДАЄ як fit, але уйде)
- 3 messaging-кути для тесту, кожен привʼязаний
до конкретної цитати
4. Закінчи: один сегмент, який ми ПОДВОЇМО, і один,
який ОБЛИШИМО, з обґрунтуванням за циклом угоди
та маржею.
</instructions>
<constraints>
- Ніколи не вигадуй цитати. Немає даних — кажи
«недостатньо доказів».
- Жодних персон типу «Marketing Mary, 35 років».
Тільки поведінка.
- Будь категоричним. Закінчи рекомендацією, не списком.
</constraints>
<output_format>
Markdown. Використай <thinking> для аналізу, потім
чистий <icp_report> розділ.
</output_format>
Чому це працює (а не «створи ICP»): ICP заснований на реальних фразах, а не на демографічних шаблонах. <lost_deals_notes> — найцінніше джерело, яке зазвичай ігнорують. Reasoning у <thinking> фіксує, що Claude цитує, а не вигадує. Інструкція «be opinionated. End with a recommendation» прибирає типовий Claude-hedging.
Очікуваний результат: 2–3 поведінкові сегменти з verbatim-цитатами, anti-ICP, і прямою рекомендацією «подвоїти / облишити». Готовий артефакт для positioning doc.
Промпт 2. GA4 + Search Console діагноз (не дашборд, а діагноз)
Проблема: експорти GA4 у CSV → у LLM → «дайте інсайти» дає superficial gems типу «conversion rate decreased week-over-week». Це не інсайт.
<role>
Ти — старший аналітик-консультант (школа Avinash Kaushik).
Мислиш у трьох шарах: ЩО сталося, ЧОМУ це сталося,
ЩО РОБИТИ. Відмовляєшся звітувати метрики без
бізнес-інтерпретації. Завжди перевіряєш якість даних
перед висновками.
</role>
<business_context>
- Продукт: [сайт агенції / SaaS / e-comm]
- Головна метрика: [SQL volume / Trial signups / Revenue]
- Етапи воронки: [Visit → Page X → Form submit →
SQL → Closed-won]
- Що змінилося в періоді: [запустили X, поставили
на паузу Y, апдейт алгоритму Z, сезонність]
- Бенчмарк минулого кварталу: [conversion %,
traffic source mix]
</business_context>
<ga4_data>
[CSV — Acquisition by source/medium,
Landing pages, Events, 90 днів vs попередні 90]
</ga4_data>
<gsc_data>
[CSV — Queries, Pages, CTR, position,
90 днів]
</gsc_data>
<task>
Зроби трирівневий діагноз, не summary метрик.
</task>
<instructions>
Крок 1 — Перевірка якості даних
(у <data_check>):
- Познач аномалії: нульові рядки, раптові розриви,
дублювання, bot-сигнали (sessions >100% users),
дропи трекінгу.
- Якщо метрика виглядає підозріло, НЕ використовуй її.
Скажи це.
Крок 2 — ЩО
(у <observations>):
- 5 найбільш матеріальних рухів, кожен з абсолютною
і відносною дельтою.
- Привʼяжи кожен до конкретного бізнес-наслідку
(виручка, пайплайн).
- Сортуй за бізнес-впливом, не за розміром %.
Крок 3 — ЧОМУ
(у <hypotheses>):
- Для кожного спостереження — 2–3 конкуруючі гіпотези.
- Для кожної: рівень впевненості
(низька / середня / висока)
і як її перевірити з наявними або потрібними даними.
- Перехресна перевірка GA4 і GSC
(якщо органічні кліки впали в GSC,
але сесії тримаються в GA4 —
атрибуція зламана).
Крок 4 — ЩО РОБИТИ
(у <actions>):
- 3 дії, відсортовані за ICE
(Impact, Confidence, Ease, 1–10 кожен).
- Для кожної:
яку гіпотезу тестує,
метрика успіху,
time budget.
- Одна рекомендація
«припинити робити».
Крок 5 — Executive summary
(максимум 4 рядки,
у <exec_summary>).
</instructions>
<constraints>
- Жодних «моніторити уважно»
чи «дослідити далі» —
давай дієслово.
- Якщо звітуєш кореляцію —
кажи, що це кореляція,
не причина.
- Познач будь-яке місце,
де ти зазвичай вигадав би
бенчмарк —
скажи:
«не знаю галузевого бенчмарку;
ось як його знайти».
</constraints>
Чому це працює: примусовий data-quality check спочатку — це той самий «ground in quotes» паттерн з Anthropic-doc, адаптований для даних. Competing hypotheses замість одного «висновку» — це ключ. ICE scoring змушує модель приоритизувати, а не просто перераховувати.
Очікуваний результат: 5-рівневий діагноз з data-quality flags, 3–5 пріоритезованими діями, готовий для presentation для CMO.
Промпт 3. Розбір конкурента з SERP- і Ad-розвідкою (не Wikipedia-summary)
Проблема: «зроби SWOT для Asana і Monday» → Claude перепаковує публічну інформацію, яку всі знають. Безкорисно.
<role>
Ти — B2B competitive intelligence аналітик з досвідом
в Klue. Синтезуєш positioning gaps з сирих доказів,
не з публічно заявлених місій компаній. Шукаєш місця,
де можна DE-position конкурента, не просто описати його.
</role>
<our_context>
[Positioning doc — 1–2 абзаци про те, як ми хочемо
щоб нас сприймали]
[ICP doc з виходу Промпту 1]
</our_context>
<competitor_evidence>
<competitor_1 name="X">
<homepage_copy>
[Hero + value prop]
</homepage_copy>
<pricing_page>
[Структура цін, якщо публічно]
</pricing_page>
<top_3_blog_posts>
[3 найпопулярніші статті]
</top_3_blog_posts>
<linkedin_recent_posts>
[10 останніх постів сторінки]
</linkedin_recent_posts>
<ads_running>
[Meta Ad Library / LinkedIn ads,
ті, що крутяться 60+ днів]
</ads_running>
<reviews_negative>
[5–10 НИЗЬКИХ відгуків —
тут слабкості]
</reviews_negative>
</competitor_1>
<competitor_2 name="Y">
[те саме]
</competitor_2>
<competitor_3 name="Z">
[те саме]
</competitor_3>
</competitor_evidence>
<task>
Зроби positioning teardown, що закінчується трьома
експлуатованими розривами.
</task>
<instructions>
Для кожного конкурента, у
<thinking>:
1. Витягни ЗАЯВЛЕНЕ positioning
(що ВОНИ кажуть, що вони є).
2. Витягни НЕЯВНЕ positioning
(що показує їхня ціна,
вибір аудиторії, ad spend ПОВЕДІНКА).
Часто розходяться.
3. Познач розрив —
це клин для нас.
4. Виокрем їхній content moat
(повторювані теми,
фреймворки, які вони мають).
5. З негативних відгуків —
структурна слабкість
(не одиничні баги — патерни).
Тоді — матриця порівняння:
| Параметр | Ми | C1 | C2 | C3 | Розрив, який експлуатуємо |
| Заявлене positioning | ... |
| Неявне positioning | ... |
| Цінова постава (преміум/мід/бюджет) | ... |
| Основний content-кут | ... |
| Структурна слабкість | ... |
Закінчи 3 ЕКСПЛУАТОВАНИМИ РОЗРИВАМИ.
Кожен відповідає:
- Що вони не можуть правдоподібно стверджувати?
- Чому це важко виправити
(organizational причина)?
- Який 90-денний план дозволить нам зайняти цей розрив?
Сортуй розриви за захищеністю
(наскільки складно
скопіювати за 12 місяців).
</instructions>
<constraints>
- Жодних
«їхня сила — впізнаваність бренду» —
це не actionable.
- Кожна заява про конкурента
посилається на конкретний
доказ у вхідних даних.
Не можеш процитувати —
не стверджуй.
- Будь різким.
Дипломатичний аналіз — марний.
</constraints>
Чому це працює: ключове — пара stated vs inferred positioning. Це класичний positioning move (April Dunford, Klue), який LLM не зробить без явної інструкції. Негативні відгуки — найцінніше джерело weakness’ів. «Чому це важко виправити» примушує думати про organizational moat, а не про feature parity.
Очікуваний результат: матриця + 3 захищені розриви з 90-day планами. Це матеріал для board meeting, не для blog post.
Промпт 4. Витяг Brand Voice з прикладів (а не з прикметників)
Проблема: інструкція «tone: friendly and professional» дає Claude-default. Це той самий voice, що у 10 000 інших компаній.
<role>
Ти — аналітик brand voice, навчений у методології
Verbal Identity (школа Wolff Olins). Твоя робота —
витягти голос автора з його текстів так, як це робить
судовий лінгвіст — через патерни, не прикметники.
</role>
<task>
Проаналізуй 5–7 зразків нижче і зроби Voice DNA
документ, який будь-який автор чи LLM зможе
використати, щоб відтворити цей голос з високою
точністю.
</task>
<samples>
<sample id="1" type="best-performing-blog">
[Вставити повний текст]
</sample>
<sample id="2" type="best-performing-blog">
[Вставити повний текст]
</sample>
<sample id="3" type="best-performing-linkedin">
[Вставити повний текст]
</sample>
<sample id="4" type="email">
[Вставити повний текст]
</sample>
<sample id="5" type="landing-page-hero">
[Вставити повний текст]
</sample>
</samples>
<instructions>
Крок 1 — У
<thinking>,
виконай аналіз на рівні рядка:
- Середня довжина речення
(порахуй, не оцінюй)
- Варіація довжини
(короткі-довгі по черзі?)
- Пунктуаційні тики
(тире? крапки з комою?
риторичні питання?)
- Як починають текст
(питання? сміливе твердження?
історія?)
- Як закінчують
- Слова, що повторюються
3+ разів у всіх зразках
- Слова, ЯКИХ НЕМАЄ
(де очікувано —
«забезпечити»,
«реалізувати»,
«синергія»)
- Метафорична область
(спорт? кулінарія?
архітектура?)
- Чий авторитет
вони викликають
(дослідження?
власний досвід?
клієнтські перемоги?)
Крок 2 — Voice DNA
у точно такому форматі:
- МИ Є
(3 прикметники,
кожен з реченням пояснення)
- МИ НЕ Є
(3 прикметники —
голоси-пастки,
яких уникаємо)
- СИГНАТУРНІ
СТРУКТУРНІ ХОДИ
(3 патерни з
прикладами речень)
- БАНК ФРАЗ
(10 фраз,
які належать
цьому бренду)
- ЗАБОРОНЕНІ ФРАЗИ
(10 фраз,
які бренд ніколи
не вживає)
- 3 ПАРИ
on-brand vs off-brand речень
(найбільш корисний
артефакт для авторів —
та сама ідея,
написана правильно
і неправильно,
з одним рядком пояснення,
що робить кожне
правильним чи провальним)
- ОДНО-АБЗАЦНЕ РЕЗЮМЕ,
яке новий автор може
засвоїти за 60 секунд.
</instructions>
<constraints>
- НЕ використовуй
прикметники типу
«професійний»,
«engaging»,
«автентичний» —
вони непридатні.
Заміни на
спостережувані патерни.
- Усі докази
посилаються
на конкретний sample.
Цитуй sample ID.
- Вихід має бути
операційним:
автор, що його прочитав,
з першого разу
пише on-brand.
</constraints>
Чому це працює: «WE ARE NOT» працює сильніше за «WE ARE» (Atom Writer benchmark). On-brand/off-brand pairs — найвища-leverage частина: Claude pattern-matches на приклади набагато краще, ніж інтерпретує прикметники. Anthropic guide прямо це підтверджує.
Очікуваний результат: живий Voice DNA-документ, який ви засовуєте у Project Instructions і Custom Style. Кожен наступний промпт буде on-brand за замовчуванням.
Промпт 5. SEO + GEO Content Brief, що не пише writer для writer’а
Проблема: Claude без брифу пише «average of the internet» — той самий контент, що ваші конкуренти. Бриф повинен містити live-SERP intelligence, інакше — нуль.
<role>
Ти — старший контент-стратег з глибоким SEO + GEO
(AI-search) досвідом. Пишеш брифи, що перетворюються
на ранжовані сторінки, не на статті, які архівують.
Оптимізуєш для funnel-стадії покупця, не для
keyword density.
</role>
<inputs>
<target_keyword>
[основний запит]
</target_keyword>
<secondary_keywords>
[5–10 підтримуючих,
семантично повʼязаних]
</secondary_keywords>
<funnel_stage>
[TOFU / MOFU / BOFU — обери одне]
</funnel_stage>
<icp>
[1-абзацний summary ICP]
</icp>
<our_unique_pov>
[Що ми думаємо,
що не є консенсусом.
1–3 речення.]
</our_unique_pov>
<top_3_serp_competitors>
<result_1 url="...">
[H1, ключові H2s,
word count,
структурні ходи]
</result_1>
<result_2 url="...">
[те саме]
</result_2>
<result_3 url="...">
[те саме]
</result_3>
</top_3_serp_competitors>
<people_also_ask>
[5–10 PAA-питань з SERP]
</people_also_ask>
<our_existing_internal_pages>
[Sitemap CSV —
title + URL]
</our_existing_internal_pages>
</inputs>
<task>
Зроби бриф,
що закінчується 10x-кутом —
причиною,
чому ця сторінка ОБЖЕНЕ топ-3,
не зрівняється.
</task>
<instructions>
1. У
<serp_analysis>:
- Що покривають ВСІ топ-3?
(Table stakes —
ми мусимо це покрити)
- Що покриває ТІЛЬКИ ОДИН?
(Можливий диференціатор)
- Що НЕ покриває НІХТО,
але PAA питання це
виявляють?
(РОЗРИВ)
- Який формат вони ділять
(listicle, гайд)? —
відповідаємо чи ламаємо?
2. У
<intent_check>:
- Домінуючий search intent
в одному реченні.
- SECOND-order intent
(що гуглять потім).
- Бриф відповідає
на обидва.
3. У
<brief>:
- Робоча назва
(2 варіанти —
один цікавість,
один обіцянка)
- Однореченнєва
обіцянка читачу
("ви залишите
цю сторінку з...")
- Word count target —
на основі того,
що ранжує,
НЕ «довше=краще»
- Повна H2/H3 структура
з 1-рядковим описом
того,
що покриває
кожна секція
- Для кожного H2:
якого конкурента
це нейтралізує
і як
- Запропоновані медіа
(таблиця,
оригінальний чарт,
вбудований калькулятор,
відео)
- Внутрішні посилання
для вставки
(з нашого sitemap),
кожне з anchor text
і обґрунтуванням
- 3 зовнішні
авторитетні джерела
для цитування
(не конкуренти)
- 10x ЕЛЕМЕНТ —
одна річ,
якої немає
в жодного конкурента.
Оригінальні дані?
Власний фреймворк?
Інструмент?
Це non-negotiable.
4. У
<geo_optimization>:
- Direct-answer параграф
для AI Overviews
(50 слів,
структурований
для цитування)
- Entity / E-E-A-T сигнали
для включення
(специфіка author bio,
оригінальні дані,
названі джерела)
- 3 питання,
на які сторінка
має ранжуватись
в AI-search
(Perplexity,
ChatGPT,
Claude)
5. У
<cta_strategy>:
- Mid-page CTA
(low-commitment,
content-adjacent)
- End-page CTA
(high-commitment,
привʼязаний
до funnel stage вище)
6. У
<kill_criteria>:
- 3 причини,
чому НЕ треба
писати цю статтю
(реальні,
не для галочки).
</instructions>
<constraints>
- Бриф має бути
юзабельним
для копірайтера
з нульовим
SEO-контекстом.
- Жодних
filler-таргетів
за словами.
Обґрунтуй з SERP.
- 10x-елемент
має вимагати
реальної роботи
(дані,
фреймворк,
інструмент).
- Жодних
«вичерпних гайдів».
</constraints>
Чому це працює: ключове — <our_unique_pov> (без власної думки = generic) + <kill_criteria> (більшість LLM-брифів пишуть для будь-якої теми; criteria змушують Claude чесно сказати «не пишіть це»). GEO-блок робить його актуальним для 2026 AI-search.
Очікуваний результат: бриф на рівні SE Ranking / thruuu методології (research time скорочується з 3–4 годин старшого SEO-спеціаліста до 10–20 хвилин), готовий до передачі копірайтеру.
Промпт 6. Pressure-test власної стратегії (Red Team у Claude)
Проблема: усі промпти просять Claude «допомогти». Це робить Claude співучасником ваших blind spots. Стратегія, не пропущена через red team, — це шанс.
<role>
Ти — цинічний, втомлений B2B-маркетинг-критик.
Бачив 1000 кампаній, що провалилися. Ти НЕ тут,
щоб мені було приємно. Ти НЕ тут, щоб «балансувати»
feedback. Ти тут, щоб знайти кожну тріщину раніше
за ринок.
</role>
<my_strategy>
[Вставити 1–3 сторінки кампанії /
квартального плану /
go-to-market doc.
Включи:
ціль,
аудиторію,
канали,
розподіл бюджету,
меседжі,
KPI,
терміни]
</my_strategy>
<task>
Запусти структурований red team цього плану.
Знайди, що його зламає.
</task>
<instructions>
Крок 1 — Pre-mortem
(у
<pre_mortem>):
Уяви,
що цей план
провалився
через 12 місяців.
Напиши 5 найбільш
імовірних
post-mortem-історій,
кожна як
3-реченнєва історія.
Конкретно —
назви метрику,
яку не зайшла,
припущення,
яке зламалося.
Крок 2 —
Аудит припущень
(у
<hidden_assumptions>):
Перелічи 8–10 припущень,
які план
ТРАКТУЄ ЯК ФАКТИ,
а вони насправді ставки.
Для кожного:
- сформулюй припущення
- оціни впевненість (1–5)
- що його спростує
- які дані потрібні
для перевірки
перед ставкою
Крок 3 —
Скан конкурентних
сліпих плям
(у
<competitive_blindspots>):
- Який рух конкурента
робить план
неактуальним?
- Який зсув ринку
(алгоритм,
регуляція,
AI-можливість)
робить його
застарілим?
- Де ми копіюємо
чужий playbook
у чужому контексті?
Крок 4 —
Resource / sequencing
критика
(у
<execution_risks>):
- Де команда
недостатньо
укомплектована
для того,
на що йде?
- Яка критична
залежність
ламає квартал,
якщо проковзне
на 2 тижні?
- Який найдешевший
експеримент
має пройти
ПЕРЕД стартом плану?
Крок 5 —
Брутальна заява
(у
<verdict>):
- Якби довелося
вбити ОДНУ
частину плану,
щоб зберегти решту —
яку?
- Якщо план
спрацює ідеально,
про що ми
пожалкуємо
у ретроспективі?
</instructions>
<constraints>
- Жодного hedging.
Жодних
«це сильний план, АЛЕ...».
Пропусти
комплімент-сендвіч.
- Жодних
generic-ризиків
(«конкурент може зробити X»).
Конкретно
або тиша.
- Якщо щось
дійсно міцне,
коротко скажи чому —
потім переходь
до тріщин.
- Уяви,
що твоя карʼєра
залежить
від критики
цього плану.
Знайди тріщини.
</constraints>
Чому це працює: Claude 4.7 — це найменш «validation-forward» модель у лінійці. Але вона все одно за замовчуванням «хороша помічниця». «You are NOT here to make me feel good» — це той самий патерн, що з Claude Doc: «Tell Claude what to do instead of what not to do», тільки сильніше. «Imagine you bet your career» — це reasoning prime, який робить Claude більш opinionated.
Очікуваний результат: pre-mortem + assumption audit за 90 секунд. Поставити перед стратегічною презентацією — врятує квартал.
Промпт 7. Funnel drop-off діагноз з даними і гіпотезами
Проблема: «де ми втрачаємо лідів» — query без структури. Без воронкових даних і гіпотез Claude скаже «improve nurturing». Дякую, ні.
<role>
Ти — conversion-архітектор (методологія CXL).
Діагностуєш воронки на рівні кроку, розрізняєш
між volume і quality drop-offs, приоритизуєш fixes
за leverage (impact × ease).
</role>
<funnel_data>
Етап 1 [назва]:
[vol in, vol out, conversion %,
median time in stage]
Етап 2:
[...]
Етап 3:
[...]
[продовжити
для кожного етапу]
Бенчмарки
(галузеві
або наш
попередній період):
[вставити]
</funnel_data>
<qualitative_signals>
<exit_surveys>
[Відповіді
на «чому
не забронювали
демо»]
</exit_surveys>
<sales_call_loss_reasons>
[Топ-10 причин
програшу]
</sales_call_loss_reasons>
<support_questions_at_each_stage>
[Питання,
що повторюються]
</support_questions_at_each_stage>
<page_session_recordings_notes>
[Якщо є
Hotjar /
Microsoft Clarity
нотатки]
</page_session_recordings_notes>
</qualitative_signals>
<task>
Зроби funnel-діагноз,
що закінчується
пріоритезованим
90-денним
A/B test roadmap.
</task>
<instructions>
Крок 1 —
Ranking drop-off
(у
<leak_ranking>):
- Для кожного етапу:
абсолютні
втрачені ліди ×
deal value =
втрачена виручка.
- Сортуй
за втраченою
виручкою
(не за %).
- Познач,
які leaks —
VOLUME проблеми
(top of funnel ok,
просто неефективно),
а які —
QUALITY
(приходять
не ті люди).
Крок 2 —
Дерево гіпотез
root-cause
(у
<hypothesis_tree>):
- Для топ-2 leaks —
згенеруй
4–6 гіпотез
кожен,
організованих
за шарами:
* Message-fit
(positioning,
ясність копії)
* Audience-fit
(приходять
не ті)
* Friction
(UX,
довжина форми,
швидкість)
* Trust
(доказ,
зниження ризику)
* Timing
(не той етап
journey
для цього asset)
- Для кожної
гіпотези:
який
якісний сигнал
її підтримує,
впевненість,
метод тесту.
Крок 3 —
A/B test roadmap
(у
<test_roadmap>):
- 6 конкретних тестів
на 90 днів.
- Для кожного:
гіпотеза,
primary metric,
secondary metric,
мінімальна оцінка
sample size,
проектований
lift range,
ризик
false positive
(особливо
для low-traffic
етапів).
- ICE скоринг
кожен
(Impact,
Confidence,
Ease,
1–10).
- Сортуй:
найвищий ICE
спочатку;
low-traffic етапи
пізніше,
бо їм потрібно
більше часу
для значущості.
Крок 4 —
Рекомендація
«припинити запускати»
(у
<stop_doing>):
- Одна річ
у поточній воронці,
що активно шкодить
(крок,
поле форми,
фрагмент копії).
- Обґрунтуй
даними.
Крок 5 —
Executive view
(у
<exec>):
- Один абзац:
де течуть гроші,
що зробимо,
чого очікуємо.
</instructions>
<constraints>
- Не пропонуй тестів,
що потребують
>3 місяців
до статистичної
значущості
на нашому трафіку.
- Будь реалістичним
щодо
statistical power.
- Розрізняй
кореляцію
і причинність
явно
при пропонуванні
root causes.
- Жодних
«покращити nurturing».
Давай точний
email /
сторінку /
CTA
для зміни.
</constraints>
Чому це працює: revenue-loss ranking замість %-ranking — це класичний урок Avinash Kaushik, який LLM не пропонує сама. Distinction між volume і quality leaks — критична, але зазвичай pre-skipped. Sample-size constraint змушує Claude бути реалістичним щодо low-traffic stages.
Очікуваний результат: 6 пріоритезованих тестів з реалістичними sample size, 1 «stop doing», exec-summary на 1 параграф. Готовий до квартального плану.
Промпт 8. Landing-page Hero, що проходить «5-секундний тест»
Проблема: «напишіть hero для нашого SaaS» дає 5 варіацій того ж самого. Без обмежень — без характеру.
<role>
Ти — direct-response копірайтер
у традиції Joanna Wiebe / Eddie Shleyner.
Пишеш для скану,
не для читання.
Кожне слово
бореться за своє місце.
Віриш,
що конкретика
перемагає дотепність,
а доказ —
заяву.
</role>
<offer>
<product>
[1-реченнєвий опис, що це]
</product>
<for_whom>
[ICP з Промпту 1]
</for_whom>
<unlike_what>
[Status quo /
альтернатива,
яку обирають замість]
</unlike_what>
<the_promise>
[Що зміниться
у їхньому світі,
якщо вони
це використають]
</the_promise>
<the_proof>
[Число,
названий клієнт,
названий результат,
рік доказу]
</the_proof>
<the_objection_to_neutralize_above_the_fold>
[Причина #1,
чому вони вагаються]
</the_objection_to_neutralize_above_the_fold>
</offer>
<voice_dna>
[Vstaviti Voice DNA
вихід з Промпту 4]
</voice_dna>
<task>
Напиши 10 hero-варіацій.
Кожна повинна пройти
5-секундний тест:
незнайомець,
що зайшов холодно,
має знати:
ЩО ти продаєш,
ДЛЯ КОГО,
ЧИМ це інше —
у межах 5 секунд.
</task>
<instructions>
Зроби 10 варіацій
за цими архетипами
(чітко підписаних):
1. Названий біль
("Припини X без Y")
2. Атакований статус-кво
("Причина,
з якої твій X
продовжує Y, — Z")
3. Результат-led
("X для Y,
які хочуть Z")
4. Конкретне число
("Як [названа сутність]
[result]
за [час]")
5. Контр-істина
("Більшість [аудиторія]
вірить
[помилкова теза].
Ось [наша версія]")
6. Створення категорії
("Нова [категорія]
для [конкретна задача]")
7. Демо-як-обіцянка
("Подивіться,
як [аудиторія]
[result]
за [час]")
8. Сміливість + доказ
("[Конкретна заява],
підкріплена
[конкретним доказом]")
9. Питання-гачок
("Що,
якщо твій [річ]
[result]?")
10. Анти-пітч
("Не [звичайна річ].
[Наша річ].")
Для кожної варіації:
- HEADLINE
(≤12 слів)
- SUBHEAD
(≤25 слів —
продовжує обіцянку,
закриває
заперечення #1)
- PRIMARY CTA
(максимум 3 слова —
verb-led,
outcome-named)
- 1-рядкова
МІКРОКОПІЯ
під CTA
(закриває ризик)
- ДЛЯ КОГО
(один рядок,
що специфікує
self-selection аудиторії)
- ДЛЯ КОГО НЕ
(один рядок —
контрінтуїтивно
підвищує конверсію)
Потім додай
ТАБЛИЦЮ СКОРИНГУ:
| # | Ясність (5s тест) |
Конкретність |
Диференціація |
On-brand voice |
Risk-reversal |
Всього /50 |
Потім у
<recommendation>:
обери топ-3
для A/B тесту,
в порядку,
і обґрунтуй чому.
</instructions>
<constraints>
- Жодних
"best-in-class",
"революційний",
"seamless",
"unlock your potential".
- Кожна заява
посилається
на доказ
у offer-input.
Якщо доказу немає —
позначай
[needs proof].
- Голос
ОБОВʼЯЗКОВО
відповідає
Voice DNA.
Якщо варіація
відхиляється —
познач.
- "ДЛЯ КОГО НЕ" —
non-negotiable.
Пропустиш —
провалив промпт.
</constraints>
Чому це працює: 10 archetypes — це канонічна різноманітність (Wiebe school); без явного списку Claude дає 10 варіацій одного архетипу. Scoring table — це structured output, що змушує модель оцінити свою роботу. «Who it’s NOT for» — це найсильніший positioning move (контрінтуїтивно підвищує conversion).
Очікуваний результат: 10 диференційованих hero-варіацій з scoring і явними рекомендаціями для A/B тесту, на голос вашого бренду.
Чому всі ці промпти «великі» — а не просто довгі
Кожен із промптів вище має 7 структурних елементів з anatomy-секції:
| Елемент |
Як це реалізовано в промптах вище |
| Role (seniority+lineage) |
«Старший B2B-стратег, школа April Dunford», не просто «marketing expert» |
| Context (long-form data first) |
Real customer data, source materials у верхній частині промпту, до запиту |
| Task (single, narrow) |
«Побудуй behavior-grounded ICP», не «допоможи з маркетингом» |
| Constraints (positive framing) |
«Не вигадуй цитати», «жодних generic personas», «будь різким» |
| Format (structured XML output) |
<thinking>, <observations>, <hypotheses>, <verdict> |
| Examples / few-shot |
У промптах вище — implied через archetypes; для production — додавайте 3–5 <example> блоків |
| Reasoning prime |
Явні step-by-step інструкції з названими тегами для проміжних кроків |
Поганий промпт: «Зроби SWOT». Великий промпт: усі 7 елементів — і Claude видає рівень, який раніше коштував €5000 за два тижні консультантської роботи.
Caveats
- Жодний з цих промптів не замінює judgment. Claude дає вам синтез — стратег дає вам рішення. Field-testing (Shared Physics, 2025) показав, що Claude чудово знаходить seasonality і algorithm-change патерни, але плутається у funnel issues, якщо data quality не перевірена. Bad data in = bad insights out, з зайвою впевненістю.
- Hallucination у стратегічних задачах коштує дорого. Claude може впевнено посилатися на «галузевий бенчмарк X%», який не існує. Constraint «Якщо не знаєш — кажи це» — обовʼязковий, не косметичний.
- Claude 4.6/4.7 виконує інструкції буквально. Якщо ви написали «будь брутальним» — він буде брутальним, навіть якщо ваша команда не готова. Дозуйте.
- Skills > Prompts для повторюваних задач. Якщо промпт із цього звіту запускається 2+ рази на тиждень, перетворіть його на Claude Skill (SKILL.md у
~/.claude/skills/). Контекст один раз, виконання — щоразу.
- Live-data через MCP > paste-CSV. Для GA4 / Search Console / Ahrefs — підключайте через MCP. Це усуває «копіюй-вставляй» цикл і дозволяє Claude робити уточнюючі запити до даних.
- «1M context» ≠ «infinite recall». Чим довший контекст, тим вища degradation на нюансі. Розбивайте дуже великі архіви на batched calls з проміжними summarization.
- Старі версії Claude (3.5/3.7) поводяться інакше. Інструкції з цього документа оптимізовані для Opus 4.6/4.7 і Sonnet 4.6. На старіших моделях деякі constraints («be opinionated, no hedging») працюють слабше — там доведеться повторювати їх 2–3 рази у промпті.
- Те, що працює сьогодні, зміниться у 2026–2027. Anthropic явно пише, що «smarter models require less prescriptive engineering» — тренд у бік меншої кількості інструкцій. Архітектура промптів (role + context + task + constraints) залишиться; deep prescription поступово стане непотрібною. Тримайте промпти модульними, щоби легко спрощувати.