Критика PRD v1 (с позиции бизнеса)

Дата: 2026-05-16 Автор: AI assistant (играет роль скептичного бизнес-партнёра) Что критикуется: docs/affiliate-prd-v1.md

A. Критика бизнес-модели (top priority)

A1. ⚠ Profit-based ставка как default — плохо для партнёра

Проблема: в PRD v1 базовая модель = 30% от profit_usdt. Партнёр не видит и не понимает заранее, сколько получит, потому что profit_usdt = (indicative_rate − applied_rate) × ... — это наша внутренняя кухня. На одной и той же сделке $1000 → партнёр может получить $9 (markup 3%) или $1 (markup 0.3%). У партнёра ощущение «крутят циферки» под него.

Из research: индустрия делает revenue share от торговой комиссии — а у нас комиссия = наш markup, и для P2P/OTC лучше платить от объёма (как BestChange, ChangeNOW, SimpleSwap), потому что объём прозрачен. Бирже не страшно отдать % от fee, потому что fee известна заранее.

Решение для v2: - Default-модель = % от volume в USDT эквиваленте, ставка ~0.3% от оборота (примерно эквивалент 30% от типичного 1% markup'а) - Опция «profit-based 30%» — для VIP-партнёров с подписанным контрактом, где partner понимает риски - В UI кабинета партнёр видит «ваша ставка: 0.3% с каждого USDT оборота приведённых клиентов» — кристально понятно

A2. ⚠ Lifetime-привязка — обязательство навечно

Проблема: в PRD v1 — lifetime после первой сделки клиента. Это значит, что если партнёр привёл клиента в 2026, а клиент сам по себе торгует у нас 5 лет — мы платим партнёру все 5 лет. Партнёр давно не сделал ничего для нас, но получает комиссию.

Forex IB-индустрия (зрелее криптовалютной) активно ограничивает: Coinbase = 3 месяца активности, многие брокеры = downgrade при отсутствии новых рефералов.

Решение для v2: - Default attribution = 24 месяца с момента первой сделки клиента (после — клиент «отвязывается», т.е. новые сделки уже не дают комиссию) - Опция «lifetime» — для VIP-партнёров (с обоснованием, например, эксклюзивный канал) - При установлении ставки в программе ясно показывать: «24 месяца с первой сделки»

A3. ⚠ Cap 200 USDT на одну сделку — мешает крупным сделкам

Проблема: туристический бизнес — это иногда большие транзакции. Сделка $100k с маржой 1% = $1000 profit, партнёру 30% = $300. Cap 200 USDT режет $100 — партнёр демотивирован приводить «жирных» клиентов.

Решение для v2: - Убрать абсолютный cap - Добавить относительный: комиссия не больше 50% от profit на этой сделке (защита от случая когда мы продали себе в минус, а партнёру всё равно платим) - Для volume-based — дополнительный sanity check: комиссия ≤ 1% от volume (даже если ставка случайно выставлена 5%, не платим больше 1%)

A4. ⚠ Минимум $5 profit на сделку — отрезает мелких туристов

Проблема: турист меняет $50, profit $1–2. PRD v1 говорит «не начислять, если меньше $5» — но это именно те сделки, которые приводят локальные блогеры в Анталье. Если отрезаем — теряем мотивацию у блогеров вести трафик «средних людей».

Решение для v2: - Убрать минимум на сделку - Минимум только на payout (50 USDT = ~100 сделок × $1 комиссия) - Это не пишет copies-комиссий «по копейкам» — мы и так храним per-deal, БД не страдает

A5. ⚠ Self-referral блокировка слабая

Проблема: v1 проверяет совпадение tg_username и phone. Любой крипто-партнёр держит 3+ TG-аккаунта и Spare-симку. Лже-нулевой барьер.

Решение для v2: - У нас уже есть KYC клиента (passport_id для крипты ≥ $425 по MASAK). Использовать совпадение passport-id как primary check - Дополнительно: при регистрации партнёра — обязательно паспорт + селфи (для MVP можно отложить до первой выплаты) - Self-referral по passport-match → автоматический voided + alert админу

B. Юридический / compliance

B1. ⚠ CMB лицензия — недо-оценил риск

Проблема: в PRD v1 я написал «не для MVP, через 6–12 месяцев». Но публичная партнёрская программа с маркетингом на турецком языке — это прямое продвижение крипто-услуг в Турции. Binance именно из-за этого закрыл retail referral в Турции в октябре 2024. Уголовка 3–5 лет за нелицензированный CASP.

Решение для v2: - MVP запуск только с не-турецкими партнёрами (русско/англо/немецкоязычные TG-каналы) - Партнёрам из Турции — пока не предлагаем программу - Турецким клиентам пока приходят через прямой маркетинг (без партнёрских ссылок) - До получения CMB-статуса (или ясности с регулятором) не делать публичную страницу «Стать партнёром» на турецком - В PRD это должно быть выделено как блокирующее ограничение, не «нюанс»

B2. ⚠ Withholding tax 1% — нет процедуры

Проблема: с 2025 Турция требует удерживать 1% с платежей intermediary-провайдерам. Это означает: при выплате 100 USDT партнёру резиденту TR мы должны удержать 1 USDT и передать в налоговую. PRD v1 говорит «обозначить в договоре» — но нет реализации.

Решение для v2: - Поле affiliates.is_tr_tax_resident BOOLEAN - При выплате если TR-resident: фактически переводим (amount − 1%) - В UI партнёра: «к выплате 100 USDT, к вашей получке 99 USDT (1% удержание по TR-закону)» - Раз в месяц — отчёт для бухгалтерии: сумма удержанных таксов

B3. ⚠ Запрещённые юрисдикции для рефералов

Проблема: в v1 я задал вопрос «пускаем партнёров из РФ/Беларуси/Ирана?» но не ответил.

Решение для v2: - Партнёры — только из не-санкционных стран (стандарт FATF/OFAC) - Рефералы (клиенты) тоже — проверка страны KYC - RU/BY — пока не блокируем (это значительная часть нашего клиентского рынка в Анталье), но мониторим санкции - При выплате партнёру: страна payout-кошелька не должна быть в списке OFAC

C. Технические

C1. ⚠ Accrual в той же транзакции — риск каскадного падения

Проблема: PRD v1: «accrue в той же транзакции что и Deal → done». Если код accrue падает → откатывается сделка. Мы рискуем потерять реальные сделки из-за бага в новом модуле.

Решение для v2: - Accrue после commit сделки (post-commit hook или event) - Если accrue упал — пишется в audit_log ошибка, сделка остаётся как есть - Cron-job каждые 15 минут пытается переначислить не-обработанные сделки (Deal.commission_calculated_at IS NULL AND deal.status='done') - Это eventual consistency, для аффилиатных комиссий — приемлемо

C2. ⚠ Hold-cron каждый час — overkill

Проблема: 150 сделок/мес = 5 в день. Hold-cron каждый час делает SELECT по нескольким строкам и обновляет 0–1 запись. Это бесполезный шум в логах и небольшой DB load.

Решение для v2: - Hold-cron раз в сутки в 04:00 UTC (после bgblock-sync и backup) - Если партнёр запрашивает payout раньше hold-окна (например, через 6 дней вместо 7) — UI говорит «доступно через 18 часов»

C3. ⚠ payout_op_id — admin выбирает Operation, но где её взять?

Проблема: в нашей системе Operation создаётся только из Deal. Payout — это не Deal, это вывод нашим партнёрам. PRD v1 не описал, как admin создаёт эту Operation.

Решение для v2: - Новый op_type='payout' (или вернее — добавить kind, чтобы не конфликтовать с crypto_out от Deal) - При approve payout admin вводит TX-hash реальной USDT-TRC20 транзакции, система создаёт Operation с source='payout', привязывает к payout_request - reconcile.py потом найдёт эту on-chain tx и свяжет

C4. ⚠ TRC20 network fee — кто платит?

Проблема: транзакция USDT-TRC20 стоит ~1.5 USDT (TRX-fee + bandwidth). При выплате 50 USDT — это 3% нашей комиссии. PRD v1 умолчал.

Решение для v2: - Опция в программе: payout_fee_borne_by = affiliate | house - Default = affiliate (партнёр получает amount − network fee) - В UI кабинета: «50.00 USDT − 1.50 USDT (network fee) = 48.50 USDT» - Прозрачно, защищает нашу экономику

C5. ⚠ Маркетинговые материалы — не реализовано в скоупе

Проблема: PRD v1 в одном из разделов упомянул «баннеры на 3 языках» как фичу партнёрского кабинета. Кто их рисует? Bybit и BestChange предоставляют — но они большие. У нас нет дизайнера в скоупе.

Решение для v2: - На MVP — никаких материалов не предоставляем - Партнёрский кабинет показывает только: ref-ссылку, QR-код (auto-gen), краткий «pitch» текст в README на 3 языках - Партнёр сам делает свои креативы (это норма для small partner-программ)

D. Что упущено в v1

D1. Refund / reverse scenarios

Проблема: в PRD сказано «cancel deal → reverse entry». Но что если комиссия уже paid? Баланс уйдёт в минус.

Решение для v2 (политика): - Минусовой баланс списывается с будущих available-комиссий партнёра (как chargeback) - Если партнёр больше не активен → списываем убыток (но логируем для последующего возврата при возобновлении) - Минимизируем риск: hold 7 дней покрывает большинство возвратов (cancel в первый день не редкость, но через 7 дней — крайне редко)

D2. Tax-report для бухгалтерии

Проблема: не сделал export commission по партнёру за период для бухгалтерии (потребуется для турецкой налоговой отчётности).

Решение для v2: - Страница /payouts/tax-report?from=Y-M-D&to=Y-M-D → CSV: партнёр, tax-id, сумма выплат, удержанный withholding tax - Раз в месяц для бухгалтерии

D3. Performance review партнёров (downgrade)

Проблема: tier-bonuses (Bronze/Silver/Gold) описал, но не сказал как ПЕРЕСМАТРИВАТЬ.

Решение для v2: - В фазе 2 — cron-job ежемесячно (1-го числа) переоценивает партнёров по объёму прошлого месяца - Upgrade — мгновенно - Downgrade — с 2-месячным protection period (как Binance) для предотвращения шоков - Партнёр в кабинете видит «вы стали Silver! Ваша ставка 35%»

D4. Что если клиент хочет отвязаться от партнёра?

Проблема: PRD не учитывает opt-out. Клиент узнал что менеджер платит блогеру и хочет это прекратить (например, лично с блогером отношения испортились).

Решение для v2: - В карточке клиента (видна admin/manager) — кнопка «отвязать от партнёра» с reason - Старые комиссии остаются (snapshot), новые сделки — без партнёра - Логируется в audit - Не разглашаем партнёру причину

D5. KPI слишком оптимистичные

Проблема: «20% новых клиентов через 6 месяцев» — у нас сейчас ~150 сделок/мес от прямых, +30 от партнёров за 6 месяцев — это малореально для начала. Реалистично 5–15% в первый год.

Решение для v2: - KPI 3 мес: 5–8% сделок от партнёров - KPI 6 мес: 10–15% - KPI 12 мес: 20%

D6. Нет финансовой модели

Проблема: PRD не показывает «сколько мы потратим / сколько заработаем».

Решение для v2: - Простой расчёт через 6 месяцев: - Сценарий A (консервативный): 5 партнёров × 5 клиентов × 3 сделки × $30 profit = $2250 → партнёрам $675 (30%) → нам +$1575 - Сценарий B (целевой): 15 партнёров × 8 клиентов × 4 сделки × $40 profit = $19200 → партнёрам $5760 → нам +$13440 - Сценарий C (стресс): партнёры приводят клиентов которые мы и так бы получили → ROI близкий к 0, но партнёрский рост = долгосрочный канал

E. Стилистические / структурные

E1. PRD слишком длинный (16 разделов)

Для бизнеса полезно сократить до 8–10 разделов с executive summary и техническими деталями в приложении.

E2. Слишком много открытых вопросов (10 штук)

В v2 нужно явно дать дефолтные ответы на каждый вопрос — пусть пользователь корректирует, а не выбирает с нуля.

E3. Нет ROADMAP-таблицы со сроками

Нужна сводная: что-кто-когда. Без неё трудно планировать.

F. Итог: что критично исправить в v2

Следующий шаг: PRD v2 с применением этих исправлений.