# Подводные камни

## Камень: путать корреляцию с причинно-следственной связью

Данные о продажах показывают, что товар пиковал в марте. Это не значит, что мартовский маркетинг это вызвал — может быть сезонный спрос.

**Почему важно:** если активно продвигать медленный товар только потому, что он один раз хорошо продался, вы тратите креативную энергию на то, что на самом деле не цепляет.

### ✗ Плохо
«Виджеты продались 10 штук в марте. Продвигаем виджеты активно в мае, раз март сработал.»

### ✓ Хорошо
«Виджеты хорошо продаются в марте. Проверь: это сезонный спрос (подарки к 8 Марта?) или разовый всплеск. Если сезонный — позиционируй под март в следующем году. Если разовый — не перегибай.»

---

## Камень: игнорировать низкооборотные, но высокомаржинальные позиции

Выручка соблазнительна. Малооборотная услуга с высокой маржой (например, консалтинг) может давать меньше общей выручки, чем дешёвый ходовой товар, но прибыли — куда больше.

**Почему важно:** если зациклиться на лидерах по объёму и игнорировать лидеров по марже, вы ставите суету выше прибыли.

### ✗ Плохо
«Пакеты услуг продались на 50 000 ₽, а комплекты товаров — на 200 000 ₽. Продвигаем товары.»

### ✓ Хорошо
«Спроси: что приносит больше прибыли на единицу? Пакеты услуг — это 70% маржа × 50 000 ₽ = 35 000 ₽ прибыли. Комплекты товаров — 20% маржа × 200 000 ₽ = 40 000 ₽ прибыли. Картина уже другая.»

---

## Камень: сезонные бенчмарки, которые не подходят вашей нише

«Розница пикует в ноябре» — верно для многих, но не для всех. Бухгалтерские услуги пикуют в марте; компания по бассейнам — в мае.

**Почему важно:** обобщённые бенчмарки уводят не туда. Всегда спрашивайте владельца: «Эта сезонность совпадает с вашей реальностью?»

### ✗ Плохо
«Отраслевые бенчмарки говорят, что 4 кв. — пик розницы. Вы делаете бассейны. Всё равно жмём в 4 кв.»

### ✓ Хорошо
«Компании по бассейнам пикуют в мае–августе. Бенчмарки 4 кв. не применимы. Подтверди у владельца: «Ваши продажи совпадают с пиком май–август?»»

---

## Камень: упустить составную картину

«Что продаётся» можно понимать по выручке, по марже, по скорости, по пожизненной ценности клиента (LTV) или по удержанию. Разные метрики рассказывают разные истории.

**Почему важно:** выберешь не ту метрику — приоритизируешь товары, которые один раз выглядят хорошо, но не дают повторных клиентов.

### ✗ Плохо
Считать «топ-продавец» = максимальная выручка. Ранжировать только по выручке.

### ✓ Хорошо
«Как вы измеряете успех? Выручка? Прибыль? Пожизненная ценность клиента? Повторные покупки?» Затем ранжируй по выбранной метрике — или комбинируй несколько для баланса.

---

## Камень: не учесть ограничения по остаткам

Товар может улетать с полок, но если остатки на нуле, активное продвижение создаст дефицит и раздражение.

**Почему важно:** вам нужны продажи, а не сорванный клиентский опыт.

### ✗ Плохо
«Виджеты хорошо продаются. Жмём виджеты сильнее.»

### ✓ Хорошо
«Виджеты хорошо продаются, но остаток упал до 5 штук. Флаг: «До продвижения подтверди остатки. Рассмотри похожую альтернативу или паузу до поставки.»»

---

## Камень: профиль учётной системы не настроен перед первым использованием

Новые пользователи учётной системы часто пропускают настройку профиля бизнеса (отрасль, название). Когда вы пытаетесь подтянуть данные по продажам, коннектор может вернуть ошибку «требуется профиль».

**Почему важно:** тупиковая ошибка раздражает владельца. Предполётная проверка экономит время.

### ✗ Плохо
Владелец: «Что мне постить?»
Скилл: [запрашивает отчёт по реализации] → Ошибка: «Требуется профиль»
Владелец: [в недоумении, не знает, что делать дальше]

### ✓ Хорошо
Владелец: «Что мне постить?»
Скилл: [проверяет профиль] → Отрасль = «Не указано»
Скилл: «Мне нужна ваша отрасль, чтобы взять правильные бенчмарки. В какой сфере вы работаете?»
Владелец: [называет отрасль]
Скилл: [обновляет профиль] → Профиль обновлён
Скилл: [теперь успешно подтягивает данные по реализации]

---

## Камень: ограничение по частоте запросов при повторных вызовах `~~платежей`

Если вызывать выгрузку операций несколько раз подряд (например, в цикле по диапазонам дат), сервис платежей (ЮKassa, банковский API) может ограничить частоту и вернуть ошибку 429.

**Почему важно:** без логики повтора скилл падает посреди анализа, хотя должен мягко деградировать.

### ✗ Плохо
Запрос операций → ошибка 429 → скилл падает

### ✓ Хорошо
Запрос операций → ошибка 429 → ждём 30 секунд → повтор → если всё ещё блокирует, предлагаем запасной путь: «Сервис платежей временно ограничивает запросы. Переключиться на выгрузку из учётной системы, или продолжить с частичными данными?» Базовый путь по умолчанию для РФ — ручная CSV-выгрузка из банк-клиента или 1С.

# Интеграция с источником данных о продажах (будущее улучшение)

> Имя файла сохранено как `square-integration.md` для совместимости со структурой пака. Содержимое адаптировано под РФ: вместо Square (касса/эквайринг) речь о подключении данных о продажах из `~~платежей` (ЮKassa, Тинькофф Касса, СБП) и `~~бухгалтерии` (1С, МойСклад).

Источники данных о продажах перечислены как опциональные коннекторы для content-strategy, но полный путь интеграции для каждого ещё не реализован. Этот документ описывает, что нужно.

## Текущее состояние

- РФ-источники (ЮKassa, 1С, МойСклад) названы в коннекторах, но не до конца подключены к процессу
- Базовый, проверенный путь — **ручная выгрузка операций в CSV/Excel** из банк-клиента, ЮKassa или учётной системы

## Что нужно сделать

### 1. Выбор точки продаж / организации

У бизнеса может быть несколько точек продаж, юрлиц или касс. Перед выгрузкой операций нужно:

1. Запросить список доступных точек/организаций (через API учётной системы или ЮKassa)
2. Спросить владельца: «По какой точке/организации анализировать?» (или по умолчанию основную)
3. Получить идентификатор(ы) для последующих запросов

### 2. Выгрузка операций

Для каждой точки/организации:

```
Запросить операции за период:
- идентификатор точки/организации: <из шага 1>
- начало периода: <90 дней назад, ДД.ММ.ГГГГ>
- конец периода: <сегодня>
- сортировка: по убыванию даты
```

Извлечь:
- Дату операции
- Позиции (наименование товара, количество, цена в ₽)
- Общую выручку по операции

### 3. Категоризация

Операции в кассовых/платёжных системах могут не иметь явной таксономии «товар» / «услуга» — позиции живут в номенклатуре. Сопоставьте позиции операций с номенклатурой в учётной системе, чтобы извлечь названия товаров и категории.

## Почему пока заглушка

1. **Нет тестового аккаунта** — для сквозной проверки нужен реальный аккаунт ЮKassa / 1С / МойСклад
2. **Сложность номенклатуры** — модель номенклатуры в учётных системах гибче выписки по эквайрингу и добавляет поверхность для ошибок
3. **Множественность точек** — выписка из банк-клиента проще; многоточечный бизнес требует от владельца выбрать точку/организацию

## Как реализовать

1. Получить тестовый/демо-аккаунт ЮKassa, 1С или МойСклад
2. Прописать сценарии для одноточечного и многоточечного бизнеса
3. Добавить `reference/sales-data-example.md` с разобранным примером
4. Обновить процесс в SKILL.md, чтобы коннектор стал равноправным путём (не «тоже поддерживается»)
5. Прогнать сценарии с реальным пользователем перед выпуском

## Оценка времени

~4 часа на изучение + реализацию + тестирование при условии доступного тестового аккаунта.