Оплату видит только бухгалтер, а сделка в amoCRM висит открытой: как автоматически подтянуть факт прихода денег

Собственник, маркетолог и руководитель отдела продаж смотрят на одни и те же цифры: сколько заявок принесла реклама, на какую сумму выставлены счета. По этим числам двигают бюджет. Но факт прихода денег в этот момент лежит в другом месте — в банковской выписке и в голове у бухгалтера. Сделка в amoCRM при этом висит открытой или помечена оплаченной вручную, хотя платёж за ней ещё не пришёл.

Где живёт факт оплаты и почему это ломает счёт окупаемости

Корень в том, что CRM, банк и бухгалтерия не делят общего определения слова «оплачено» (по разбору focuspointsap.com). В amoCRM «оплачено» — это статус, который поставил менеджер. В банке «оплачено» — деньги на расчётном счёте. Эти два события расходятся во времени и по сути, и никто их не сцепляет.

Пока статус в воронке проставляется руками, бюджет распределяется по числам, за которыми нет денег на счёте. Реклама, которая нагнала много заявок и выставленных счетов, выглядит окупаемой. Оплатили ли эти счета — из отчёта по воронке не видно.

«Выиграно» и «счёт выставлен» — это ещё обещание

Честная опора для решений по бюджету — уровень «деньги получены и не возвращены». Он стоит ниже статусов «выиграно» и «счёт выставлен» и показывает то единственное, что важно для расчёта: деньги дошли до счёта и остались там (по материалу ahmedayoutty.com).

Разрыв между обещанной и пришедшей выручкой измерим. В одном публичном разборе рекламные площадки отчитались о выручке примерно на 19% выше той, что фактически дошла до бизнеса (привожу как иллюстрацию). Оговорюсь честно: цифра из зарубежной розницы с оплатой при доставке и высоким процентом возвратов, для безналичных расчётов между юрлицами масштаб расхождения будет свой. Но направление ошибки одинаковое — счёт по выставленным счетам завышает окупаемость, и вы платите за рекламу больше, чем показывают деньги.

ROMI считается по фактической выручке: (доход с рекламы − затраты) ÷ затраты × 100%. Нормой считают 20% и выше, успешной кампанией — от 100% (по методике roistat.com). Подставьте в числитель сумму выставленных счетов — получите красивую цифру, под которой нет денег. Подставьте пришедшие рубли — получите цифру, по которой можно принимать решение. Прикинуть, сколько бюджета сейчас распределяется по необеспеченным числам, можно через калькулятор стоимости внедрения, заложив свой поток счетов и долю неоплат.

Как платёж технически привязывается к сделке

Механика простая. Эквайринг отправляет POST-callback (вебхук) на адрес amoCRM с секретным словом для верификации. Счёт выступает связующим объектом между сделкой и платежом: по нему система понимает, к какой именно сделке относится пришедший рубль. После подтверждения статус меняется на «оплачен» (по документации docs.paykeeper.ru).

Дальше подключается автоматика воронки. Готовые интеграции подтягивают факт оплаты из эквайринга прямо в карточку сделки: salesbot переводит сделку на следующий этап после подтверждения оплаты, а менеджеру ставится задача — и при успешной оплате, и при неудачной попытке. На стороне банков это уже закрыто: поддерживаются Т-Банк, Сбер, Альфа, ЮKassa, Модульбанк, Точка, PayKeeper — по данным вендора, 16 банков (radist.online).

Одну вещь закладываю в логику воронки заранее. Скорость подтверждения непостоянна: часть вендоров обещает мгновенное изменение статуса, документация PayKeeper предупреждает о задержке в несколько минут. Значит, автоматика не должна дёргать менеджера в ту же секунду — сценарий строится с допуском на эти минуты.

Есть и участок, который дособирается под конкретный бизнес. Онлайн-привязка по эквайринговой ссылке через счёт отработана. А вот сцепка обычного банковского перевода из выписки, где плательщик — юрлицо, а не контакт сделки, единого готового решения в открытых источниках не имеет. Это ключевой узел для расчёта до рубля, и его я собираю под конкретный поток платежей: по назначению платежа, ИНН плательщика и номеру счёта. Именно этим я и занимаюсь во внедрении и доработке amoCRM — довожу привязку платежей до состояния, когда в сделку падает факт прихода денег, а не намерение оплатить.

Что закрытая петля даёт выручке и потоку сделок

Первое — атрибуция опирается на деньги. Каждый рубль рекламного бюджета прослеживается до счёта, а расчёт окупаемости берёт уровень «деньги получены и не возвращены». Цена заявки и ROMI кампании считаются по пришедшим рублям.

Второе — снимается ручная сверка. В публичном кейсе автопривязки платежей Точка Банк → amoCRM контроль оплат отнимал до 30 минут в день на менеджера плюс около 2 часов в день на ручное внесение офлайн-клиентов. После автопривязки эта рутина заняла 0 минут вместо примерно 2,5 часов ежедневно, сам скрипт написали за 8 дней (cmdf5.ru). Эти 2,5 часа — не абстрактная экономия: столько времени менеджер каждый день не продавал, а сверял платёжки.

Третье — восстанавливается поток повторных продаж. При ручном внесении часть оплативших клиентов не попадала в базу, и продать им повторно было нельзя — данных для этого просто не было. После автоматической подгрузки платежа офлайн-клиент сам появляется в amoCRM по факту оплаты счёта, и с ним можно работать дальше. Это та же логика сверок без ручной работы, которую я разбирал на примере бэкофиса и документов.

Итог для собственника, маркетолога и руководителя продаж один: бюджет двигается по деньгам на счёте, менеджеры не сверяют оплаты руками, а решение «докидывать в рекламу или резать» опирается на пришедшие рубли.