Когда сайт перерастает конструктор: как решить, пора ли переезжать

Начните с ошибок и повторной работы

Возьмём учебный пример мастерской. На сайте можно купить готовый набор, записаться на занятие и отправить запрос на индивидуальную работу. Когда наборов было мало, владелец менял наличие вручную. Теперь товар продают ещё и в самой мастерской. Сотрудник снова сверяет остатки, а посетитель иногда заказывает то, что уже забрали с полки.

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

Посмотрите на последние рабочие случаи. Что сотрудники переписывают повторно? Какую ошибку приходится исправлять перед клиентом? Какое изменение откладывают, потому что никто не знает, как его сделать? Запишите действие и последствие: «повторно вводим состав заказа», «принимаем две заявки на одно время», «редактор видит сведения, которые ему не нужны».

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

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

Опишите, что должен делать сайт

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

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

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

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

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

Сначала проверьте, разрешает ли сервис работать вашему бизнесу. Wix, конструктор сайтов, официально сообщает о прекращении услуг для резидентов России с 12 сентября 2024 года. Похожее ограничение доступа может сделать замену необходимой даже для маленького сайта. Не рассчитывайте на обход условий сервиса.

Менять можно одну функцию, а не весь сайт

Допустим, проверка показала: тексты и каталог удобно обновлять, права сотрудников настроены, но общая форма не управляет временем занятий. У владельца есть несколько путей. Настроить подходящую встроенную запись. Оставить страницы и подключить отдельный сервис расписания. Перенести работу в систему, где запись станет основной функцией.

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

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

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

Проверьте и ежедневное управление. Редактору блога нужно менять текст, администратору занятий – работать с расписанием, владельцу – управлять оплатой и доступами. У каждого сотрудника должен быть отдельный доступ к сайту – своя учётная запись. Пусть он зайдёт под ней и проверит, что может выполнять свою работу и не может делать то, что ему не поручили. Иногда платформа позволяет разделить права, но их ещё не настроили. С общим паролем всей команды вы это не проверите.

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

Считайте расходы за месяц и стоимость переезда

Сравнивая только подписки, вы пропустите другие расходы. В текущем варианте учтите дополнения, обслуживание, комиссии при оплате и часы повторного ввода. В новом варианте добавьте перенос текстов и товаров, подключение учёта, обучение сотрудников, время работы двух версий сайта и поддержку после запуска. Разовые и ежемесячные расходы держите отдельно.

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

Вот условный расчёт, без рыночных цен и обещания продаж. Компания обрабатывает 100 обращений в месяц. Повторный ввод занимает шесть минут на обращение; в пробной версии нового сайта рассчитывают тратить на него две минуты. Разница составляет 400 минут, или 6 часов 40 минут в месяц. При условной оценке рабочего часа в 900 ₽ это 6 000 ₽ времени.

Допустим, новая система требует ещё 3 000 ₽ ежемесячных расходов, а переход оценивается в 120 000 ₽. Разница между стоимостью освобождённого времени и новыми расходами: 3 000 ₽ в месяц. За 40 месяцев при неизменных условиях эта разница составит столько же, сколько стоит переход. Если зарплатные расходы сохранятся, свободное время не превратится в эти деньги на счёте; оно лишь освободится для другой работы.

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

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

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

Сравните варианты на одном листе до заказа переезда

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

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

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

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

Проверка показывает только то, что вы попробовали. Она не доказывает, что сайт выдержит наплыв клиентов, что все доступы безопасны и что настоящие данные разрешено передавать новому сервису. Не переносите клиентскую базу ради демонстрации. Удалённые имена в старой таблице не дают автоматически права отправлять оставшиеся сведения новому сервису.

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

Переезд нужен, когда важную задачу иначе не решить

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

Начните с листа для самой важной задачи. Если помогает настройка, измените её; если отдельный сервис – подключите его. Полный переезд сравнивайте с доработкой, когда иначе не получается работать с заказами, оплатой и другими важными задачами. Если поставщик прекращает доступ или запрещает нужный способ работы, ищите замену без ожидания экономии от роста.