Хватит пересобирать магазин каждого клиента: повторяемая система онбординга

Краткое содержание

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

Ваш клиент присылает запрос из одной строки в пятницу в 16:53: «Можно просто добавить кнопку покупки в мой Instagram?» Вы уже пересобирали его магазин один раз на этой неделе. Остановитесь. Дело не в клиенте — дело в вашем процессе. Эта статья даёт вам повторяемую систему онбординга: стандартизированный вводный бриф, матрицу выбора платформы, стандартные настройки платёжного стека, проверку соответствия требованиям, стандарты данных о товарах, скрипт тестирования на стейджинге и этап запуска. Создайте её один раз — и каждый будущий магазин поедет по тем же рельсам. Вы перестанете заново решать одну и ту же проблему и начнёте запускать магазины.

1. Превратите приёмку в этап, а не в чат

Один клиент продаёт 12 ароматических свечей и должен запуститься до новогодней ярмарки. Другой хочет заниматься дропшиппингом 300 SKU от трёх разных поставщиков. Клиенту со свечами важна скорость; клиенту-дропшипперу — синхронизация остатков и маршрутизация заказов. Если вы спросите обоих: «Какой у вас бюджет и какую платформу вы хотите?» — вы получите два бесполезных ответа, а затем в течение месяца пересоберёте один из этих магазинов.

Отправьте одностраничный бриф, прежде чем трогать какие-либо инструменты. Сделайте эти вопросы обязательными:

• Сколько SKU вы планируете продать за первые 90 дней?
• Физические товары, цифровые или смешанные?
• Кто обрабатывает заказы — вы, поставщик или третья сторона?
• Какова средняя стоимость заказа?
• Продаёте ли вы за пределами штата или страны? Где у вас есть налоговое присутствие?
• Будете ли вы предлагать подписки, предзаказы или мультитоварные наборы?
• Какая одна функция должна быть у этого магазина в первый месяц?

Пусть клиент введёт ответы в текст, а не продиктует их по телефону. Напечатанные ответы становятся документом. Устные ответы превращаются в «я этого не говорил» на шестой неделе.

Затем напишите резюме ограничений из трёх строк: бюджет, скорость и обязательная функция. Поместите его в начало файла проекта. Когда клиент позже попросит добавить функцию, меняющую архитектуру, укажите на бриф и скажите: «Это меняет платформу. Вот сколько это стоит».

Почему это важно: выбор платформы — результат этого брифа. Если вы его пропустите, вы выберете то, что использовали в прошлый раз. Исследования платформ электронной коммерции сходятся в одном: разным бизнес-моделям нужна разная архитектура. Магазин свечей на 12 SKU и дропшиппер на 300 SKU — это разные бизнесы, поэтому относитесь к ним по-разному. Мы уже писали о том, почему одна платформа не подойдёт каждому клиенту; этот бриф — способ воплотить это в жизнь.

2. Стройте матрицу платформ по профилю клиента, а не по привычке

Вот паттерн, который постоянно ломается: вы открываете один и тот же хостинговый конструктор с перетаскиванием для каждого нового магазина, потому что это быстро. Затем клиенту с физическим магазином нужно синхронизировать остатки с кассовым аппаратом. Ваш любимый конструктор не может этого сделать без трёх платных приложений. Вы меняете платформу на третьей неделе, и все теряют время.

Матрица решений решает эту проблему. Она сопоставляет ограничения клиента с категориями платформ, а не с брендами. Храните её в общем документе и обновляйте ежеквартально. Начните с этой рабочей версии:

Профиль клиента	Категория платформы	Когда она выигрывает
Мало SKU, быстрый запуск, владелец без технических навыков	Хостинговый конструктор с перетаскиванием	Скорость, экосистема приложений, встроенный хостинг
Существующий контентный сайт, важнее контроль дизайна	Плагин магазина с открытым исходным кодом для текущей CMS	Сохранить сайт, добавить коммерцию
Много SKU, сложный каталог, планы роста	Масштабируемая хостинговая платформа с мощным API	Пользовательские интеграции, многоканальность
Физический магазин плюс онлайн-магазин	Конструктор с интеграцией POS	Синхронизация остатков между каналами
Ограниченный бюджет, мало товаров	Лёгкая встроенная витрина	Низкая ежемесячная стоимость, простое оформление заказа

Это карта категорий, а не рейтинг. Клиент, которому нужны мультивалюта и подписки, принадлежит строке «масштабируемые платформы», нравится вам эта строка или нет. Клиент с пятью товарами не должен покупать корпоративную инфраструктуру.

Используйте бесплатные пробные периоды осознанно. Исследования подтверждают: многие платформы предлагают бесплатные пробные версии. Большинство людей тратят эти пробные периоды на переключение шаблонов. Вместо этого проведите один тест на основе брифа клиента. Импортируйте 300 реальных SKU. Если импорт не удастся — вычеркните эту платформу. Протестируйте оформление заказа на реальном тестовом заказе. Проверьте, покрывают ли настройки налога штат клиента. Пробный период, моделирующий ваши реальные ограничения, — это решение; пробный период, который этого не делает, — развлечение.

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

3. Настраивайте платёжный стек по денежному потоку, а не по тому, что знакомо

Два клиента — две реальности денежного потока. Один продаёт свечи за 40 долларов и может ждать зачисления неделю. Другой продаёт мебель за 800 долларов, и деньги должны возвращаться на счёт в течение нескольких дней, чтобы закупить материалы для следующего заказа. Если вы настроите им один и тот же платёжный шлюз, вы обречёте одного из них на провал. Руководства по обработке платежей последовательно указывают на три операционных рычага: скорость зачисления, прозрачность ценообразования и качество поддержки. Начинайте с них.

Следуйте этому порядку:

1. Спросите, каков цикл денежного потока у клиента. Еженедельные или ежедневные выплаты? Некоторые процессинговые компании зачисляют быстрее, а некоторые дольше удерживают средства для определённых типов бизнеса.
2. Проверьте интеграцию шлюза с выбранной вами категорией платформы. Поддерживает ли он подписки, если они требуются в брифе? Поддерживает ли он страны, указанные в брифе?
3. Прежде чем создавать магазин, сверьте категорию товаров клиента со списком ограничений процессинговой компании. Для категорий высокого риска аккаунты замораживают, а не предупреждают по электронной почте.
4. Если у клиента уже есть способ оплаты, которому доверяют его покупатели, — например, широко известный кошелёк, — включите его, даже если это добавляет комиссию. Доверие конвертирует лучше, чем разница в комиссии.
5. Задокументируйте, какой шлюз, какой аккаунт и какой график выплат одобрил клиент. Положите это в файл проекта с датой.

Конкретный пример: клиенту с мебелью нужны быстрые зачисления и поддержка больших сумм заказов. Клиенту со свечами — простое оформление заказа и низкие накладные расходы. Вы можете в итоге выбрать процессинг с приоритетом API для первого и процессинг для новичков для второго. Решает матрица, а не ваша привычка.

Если вы это пропустите, проблема всплывёт на второй неделе после запуска, когда клиент позвонит и скажет, что его деньги зависли. Переделка платежей затрагивает оформление заказа, чеки, налоговые отчёты и доверие клиента. Это самое дорогое, что можно пересобрать.

4. Проводите проверку соответствия до начала проектирования

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

Комплаенс — это этап запуска, а не административная формальность. Прежде чем начинать дизайн, убедитесь:

• Регистрация бизнеса соответствует реальному юридическому лицу клиента.
• Регистрация налога с продаж существует в каждом штате, где у клиента есть налоговое присутствие.
• Категория товара разрешена платёжным процессором, который вы собираетесь подключить.
• У клиента есть лицензии или разрешения, которые требуются для данного типа товара.
• Условия использования, политика конфиденциальности, политика возврата и политика доставки написаны и соответствуют тому, что магазин делает на самом деле.

Выполняйте это как чек-лист с галочками, а не как разговор. Когда клиент говорит: «Мой юрист этим займётся», установите срок. Если срок проходит, дата запуска сдвигается. Это не вы проявляете упрямство — это вы защищаете запуск.

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

5. Стандартизируйте контракт на данные о товарах

Клиент присылает таблицу с 300 товарами. В каждой строке есть название и цена. Нет ни веса, ни габаритов, ни страны происхождения, ни кода поставщика. Вы просите недостающие поля. Клиент не понимает, почему это важно. Проект стоит неделю. Затем вы запускаете магазин с доставкой «бесплатно», потому что не смогли рассчитать тарифы, и клиент расплачивается за эту ошибку.

Перестаньте принимать данные о товарах в любом виде, в котором они приходят. Определите контракт на данные о товарах. Каждый товар должен включать как минимум:

• Внутренний SKU и штрихкод
• Название товара и описание, которое будет опубликовано на сайте
• Цена и цена до скидки
• Вес и габариты для доставки
• Страна происхождения и, если международная поставка, код ТН ВЭД
• Поставщик и срок поставки
• Профиль доставки (класс перевозчика и зоны)
• Имя файла фото товара и альтернативный текст
• Налоговая категория

Разберём тех же двух клиентов. Клиент со свечами даёт 12 SKU. Вы заполняете поля за час. Дропшиппер даёт 300 SKU. Вы требуете CSV-экспорт от каждого поставщика и сопоставляете столбцы с контрактом. Если поставщик не может предоставить поле — это проблема выбора источника, которую должен решить клиент, а не проблема с данными, которую вы должны угадывать.

Стандартизированные данные о товарах — это то, что делает перенос платформы дешёвым. Если каталог структурирован правильно, переезд клиента на другую платформу — это импорт, а не пересборка. Если нет — вы перепечатаете 300 строк и ошибётесь. Вы также можете использовать эти структурированные данные, чтобы создавать товарные описания, которые продают, потому что тексты и альтернативные описания уже есть в контракте.

6. Выполняйте один и тот же скрипт тестирования на стейджинге для каждого магазина

Клиент присылает скриншот в 9 утра: «С меня дважды списали доставку». Вы входите в систему и обнаруживаете ставку налога неправильной страны и конфликт промокода с логикой доставки. На исправление уходит двадцать минут. Но клиент уже потерял доверие, а доверие — это и есть весь бизнес.

Вам нужен скрипт тестирования. Один и тот же порядок, одни и те же шаги для каждого клиента:

1. Оформите реальный тестовый заказ тестовым платёжным методом.
2. Убедитесь, что письмо с подтверждением доходит до покупателя.
3. Проведите возврат и подтвердите, что клиент его видит.
4. Примените промокод и проверьте расчёт.
5. Проверьте отдельно оформление заказа гостем и зарегистрированным пользователем.
6. Добавьте товар в корзину с мобильного телефона, а не только в предпросмотре на десктопе.
7. Протестируйте международный адрес доставки, если клиент доставляет по всему миру.
8. Проверьте расчёт налога для родного штата клиента и для одного другого штата.
9. Вызовите отказ в оплате и проверьте сообщение об ошибке.
10. Подтвердите, что остатки уменьшаются при продаже.

Используйте дешёвый тестовый товар в режиме стейджинга или черновика. Многие платформы предлагают бесплатные пробные режимы; используйте их для этого, а не для просмотра шаблонов. Ограничьте тест получасом на магазин. Повторяемый скрипт тестирования быстрее подхода «наверное, всё в порядке», потому что вы никогда не гадаете, что забыли.

Пропустите этот шаг — и вы не нарочно запустите сломанный магазин. Вы запустите магазин с одним непротестированным путём, и первый реальный покупатель его найдёт.

7. Не позволяйте платформе быть первым решением

Клиент приходит на онбординг-звонок и говорит: «Мы хотим популярный хостинговый конструктор, потому что кто-то в маркетинге однажды им пользовался». Вы тратите два дня на перенос их требований в этот инструмент и обнаруживаете, что он не умеет мультивалютное оформление заказа, которое требует бриф. Теперь у вас два варианта: сообщить новость и разозлить клиента или построить неправильный продукт.

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

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

Предостережение реально: не переусложняйте проект ради будущих потребностей, которых вы не видите. Клиенту со свечами не нужна интеграция с несколькими поставщиками. Дропшипперу нужна. Соответствуйте брифу, а не воображаемому будущему. Если клиент говорит: «Мы планируем выйти на международный рынок через 18 месяцев», отметьте это и выберите категорию, которая этому не помешает. Если они говорят: «Мы просто хотим протестировать идею», выберите самый быстрый вариант и спланируйте перенос платформы позже. Стройте по брифу.

8. Ограничьте запуск минимально жизнеспособным каталогом

Клиенту нравится сайт. Просто у него нет фотографий товаров. «На следующей неделе», — говорит он. Через три недели магазин всё ещё висит на заглушке «Скоро открытие». Ваша команда начинает добавлять дополнительные функции, чтобы заполнить время, потому что никто не хочет говорить клиенту, что проект заблокирован по его вине. Затем объём работ ползёт, и вы сжигаете часы.

Установите этап запуска. Определите минимально жизнеспособный каталог до начала проекта. В нём должно быть достаточно товаров, чтобы магазин ощущался настоящим в своей нише — дюжины качественных позиций часто достаточно для бутика, а дропшипперу может понадобиться курируемый набор самых продаваемых товаров, а не все 300. Каждый товар в этом наборе должен иметь фото, цену, описание, вес и габариты и подтверждённого поставщика. Никаких страниц товаров «скоро». Никакого текста-заглушки.

Сделайте запуск зависимым от следующих условий, все они бинарные:

• Вводный бриф заполнен и подписан.
• Файл контракта на данные о товарах заполнен для каждого товара на запуск.
• Платёжный стек одобрен и тестовый заказ прошёл.
• Чек-лист комплаенса заполнен.
• Скрипт тестирования на стейджинге пройден.

Когда клиент спрашивает: «Можно ли запуститься с готовыми товарами?» — ответ да, если эти товары соответствуют полному контракту. Это не перфекционизм, это повторяемость. Этап существует, чтобы вы никогда не запускали магазин со скрытой зависимостью.

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

Заключение: ваш процесс — это продукт

Вы продаёте не сайты. Вы продаёте предсказуемый путь от «хочу магазин» до «магазин запущен и принимает заказы». Этот путь нуждается в стандартных настройках, а не в импровизации.

В следующий раз, когда клиент напишет в пятницу в 16:53, вам не нужно ничего решать заново. Вы заполняете бриф, проверяете матрицу, просматриваете платёжный стек, выполняете список комплаенса, подтверждаете данные о товарах и выполняете скрипт тестирования. Затем вы отвечаете на письмо планом, а не догадкой.

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