Ошибки в оптимизации расходов бизнеса

Расшифровка выпуска

Всем привет. С вами Роман Рыбальченко, основатель агентства Roman.ua. И сегодня я хочу поговорить о такой вещи, с которой часто сталкиваюсь на консалтинге или где-то в социальных сетях, в сообществах, посвященных интернет-маркетингу, работой с e-commerce проектами. Это оптимизация не по размеру.
Что я называю оптимизация не по размеру? Читаю пост в социальных сетях: «Интернет-магазин из России имеет оборот порядка 300 тысяч рублей по карточкам…», т.е. люди по карточкам платят приблизительно на вот такую сумму в месяц, «…и начинает рассматривать смену процессинга», т.е. смену того подрядчика, который обеспечивает прием этих карточных платежей, потому что, дескать, у него, например, 3.5% тариф за платежи, а на рынке говорят, что это много и надо платить 2.5%, и что вы переплачиваете. И вот он начинает спрашивать, где, у кого, какой процессинг взять лучше, у кого можно выбить дешевле и так далее.

Давайте просто посчитаем. Обычная простая арифметика. 300 тысяч рублей в месяц приходят по карточкам. Сейчас мы платим 3.5%, можем платить на 1% меньше. 1% от 300 тысяч рублей — это делим на 100 — это соответственно будет 3000 рублей. Делим это еще на 60. Это будет порядка $50 в месяц потенциальной экономии. Это при прочих равных.

А теперь, что обычно еще забывают, что не закладывают, какие риски, и почему думают, что все остальное будет ровно таким же, а оно таким не бывает в жизни.
Первое — это время менеджера. Время менеджера, который начинает заниматься этим вопросом. То есть $50 в месяц, на годе это экономия порядка $600. Сколько времени он потратит на утверждение договоров, на поиск другого подрядчика, на его проверку, на устаканивание условий, своего личного? А если это владелец магазина, то считайте еще дороже его, чем наемного менеджера.

Дальше. Время программистов. Программист должен будет внедрить это всё, протестировать, обкатать и проверить, что всё корректно работает. И это тоже стоит денег и поддерживать это всё в течение какого-то времени тоже будет стоить.

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

И это мы берем только время, да, т.е. сколько времени нужно будет потратить компании для того, чтобы поменять одно решение, которое работает, к которому привыкли, которое как-то там выплачивает на расчетный счет, на другое решение, которое будет просто выгодней.

Теперь следующий вопрос. Хорошо, предположим, что у нас там небольшие зарплаты или мы предполагаем, что сейчас меняем процессинг и он проработает несколько лет и на эти несколько лет эта экономия отобьется. Следующая вещь — это риски. Меняя процессинг на тот, который дешевле, могут повыситься риски. Как риски того, что в какой-то момент он вам не выплатит. Обычно в бизнесе чудес не бывает. Если что-то стоит какое-то денег, а кто-то предлагает это дешевле, иногда это может быть за счет рисковости их моделей. И вторые риски — это, собственно, риски ухудшить конверсию своих платежей. Потому что обычно сравнивают по одному параметру, т.е. вот сколько процентов, какая комиссия, да, и как быстро выплачивает, и так далее, но мало кто сравнивает это проходимость платежей. Это второй параметр, который очень сильно влияет на вашу прибыль в e-commerce. Не просто, какой процент забирает собой процессинг, а насколько этот процессинг знают, насколько ему доверяют пользователи, насколько он влияет на конверсию и насколько он проходимый, т.е. на 100 попыток оплат сколько оплачивается успешно. И разработки такие, чтобы больший процент оплат заканчивался успешно, они тоже, не секрет, стоят денег, и обычно это выливается в повышение процента за процессинг, да, т.е. мы сталкивались на Запад, что процессинг может забирать и 7%, и 10%, но зато он разработал решение, которое для каждого географического рынка, для каждой особенности работает по-своему и большая часть платежей проходит без проблем и проходит с первого раза.

При этом, если говорить про проходимость, да, то есть, если у вас действительно большой бизнес, где есть необходимость оптимизировать и отдавать комиссию за оплату карточками, то тогда да, тогда вплоть до того, что вы частично на своей стороне придумываете решение, которое будет, например, роутить платежи. Что я имею в виду? Если у вас, например, платеж идет с карточки самого популярного банка в стране, который имеет долю рынка 30-50%, вы этот платеж можете отправлять напрямую на этот банк, и таким образом вам не нужно платить Visa и MasterCard и банк вам предложит 1-1.5% за процессинг такого платежа чаще всего, особенно, если у вас есть еще объемы. В случае же, если платеж уходит на сторону, на не самый популярный банк, то он уходит на какого-то агрегатора, который работает с большей частью банков, и там вы уже платите 2.5%, 2.2%, 2.7%, до 3% в большинстве случаев. Хотя, иногда бывает и больше. И это оправдано на больших размерах.
Второй пример, который очень похожий, это, когда меня набирает молодой предприниматель и говорит: «Слушай, Рома. Я сейчас стартую свой бизнес. Вот я хочу торговать вот этим товаром, вот здесь закупать. Подскажи мне, пожалуйста, что мне выбрать, 1С, не 1С, потому что я вот уже сразу хочу заинтегрировать его с «Новой Почтой», с системой логистики». Я говорю: «Супер. А сколько платежей или заказов в месяц ты планируешь?» «Ну, порядка 60». Я говорю: «На 60 заказах в месяц менеджер без проблем сгенерирует товарно-транспортные накладные руками, или же в отделении, или онлайн на сайте, и не надо для этого думать по поводу привлечения программиста, выбора системы, которая будет работать с этой интеграцией, и так далее, если ее нет у тебя из коробки». То есть если ты выбрал какое-нибудь решение, на Западе это, например, Shopify или Magento, где уже из коробки есть много плагинов, дополнений и интеграций, да, можно их использовать. В СНГ это Prom.ua, Tiu.ru, может быть, частично InSales, я немного с ними работал, но предполагаю, что у них много интеграций.

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

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