Повторный заказ не должен начинаться с переписки заново
Постоянный покупатель пересылает менеджеру прошлую накладную и пишет: «Нужно то же самое». Менеджер ищет позиции, проверяет упаковки, уточняет адрес, пересчитывает цены и объясняет отсутствие части товара. Клиент считает действие простым повтором, а поставщик фактически собирает заказ с нуля.
Мини-приложение может сделать этот процесс понятнее. Telegram Mini App — веб-интерфейс, открываемый внутри мессенджера. В нём можно спроектировать каталог и корзину, но само размещение интерфейса не решает вопросы актуальности данных и подтверждения заказа.
Проект оправдан, если постоянные покупатели регулярно используют мессенджер и им действительно удобно выбирать товары на таком экране. Наличие аудитории в канале компании само по себе ещё не означает готовность закупать через мини-приложение.
Найдите действие, которое стоит упростить
Не начинайте с полного каталога. Выберите повторяющуюся операцию: заказать расходные материалы по прошлой поставке, пополнить согласованный ассортимент или собрать набор по шаблону покупателя.
Для выбранной операции восстановите путь последнего заказа:
- где клиент нашёл перечень товаров;
- какие позиции пришлось уточнять;
- какие условия изменились;
- сколько раз менеджер возвращал черновик;
- в какой момент заказ был подтверждён.
Цель первой версии сформулируйте наблюдаемым действием. Например: покупатель сам собирает корректный черновик из своего шаблона, видит изменения условий и отправляет его менеджеру на подтверждение. Это конкретнее обещания «автоматизировать продажи».
Процесс подтверждения остаётся отдельным. Если компания проверяет отсрочку, наличие или маршрут доставки вручную, интерфейс должен честно показывать этот этап.
Условный пример: расходные материалы для сети мастерских
Вымышленный поставщик продаёт расходники небольшим мастерским. Покупатель обычно повторяет заказ из трёх позиций: перчатки, очиститель и салфетки. У одной организации несколько точек доставки и два сотрудника, имеющих право создавать заявки.
Прошлый заказ содержал четыре упаковки перчаток по 900 условных рублей, две упаковки очистителя по 1 500 и три упаковки салфеток по 400. Его сумма составляла 3 600 + 3 000 + 1 200 = 7 800.
При повторе очиститель стоит 1 600, а доступно только две упаковки салфеток. Черновик без отсутствующей упаковки составляет 3 600 + 3 200 + 800 = 7 600. Это не экономия на прежнем составе: количество изменилось. Интерфейс должен отдельно показать повышение цены очистителя и нехватку салфеток.
Покупатель выбирает: отправить доступную часть, запросить срок недостающей позиции или изменить заказ. Система не заменяет товар молча и не подменяет сравнение одной итоговой суммой.
Разделите историю, шаблон и новый заказ
История хранит то, что произошло раньше. Шаблон содержит желаемый повторяемый набор. Новый заказ фиксирует текущий запрос покупателя и проходит действующие проверки.
Изменение каталога не должно переписывать историю. Если артикул переименовали, старый заказ остаётся понятным, а при повторе система объясняет связь с актуальной позицией. Если товар снят с продажи, черновик получает предупреждение и доступный путь решения.
Шаблон тоже может устареть. Для него нужны владелец и дата последней проверки. Особенно это важно, когда ассортимент утверждает руководитель клиента, а заказывают сотрудники отдельных точек.
При копировании старого заказа сохраняйте ссылку на источник для удобства, но создавайте новый идентификатор. Повторное нажатие отправки одного черновика, наоборот, не должно создавать несколько независимых заказов.
Определите, чьи условия видит человек
Пользователь мессенджера и организация-покупатель — разные сущности. Одному человеку могут быть доступны несколько организаций, у каждой — свои адреса и коммерческие условия.
В начале сессии или перед отправкой заказа покажите, от чьего имени действует пользователь. При переключении организации пересчитайте условия и очистите несовместимые настройки. Нельзя оставить цену одного покупателя и адрес другого только потому, что экран уже был открыт.
Согласуйте роли: кто просматривает каталог, кто создаёт черновик, кто подтверждает отправку. Для первой версии можно оставить простую модель, но она должна отражать реальную ответственность клиента.
При прекращении сотрудничества или уходе сотрудника доступ должен пересматриваться определённым ответственным. Разработка реализует механизм, а компания определяет порядок его применения.
Что показать при изменении условий
Главный экран повторного заказа — список различий. Покупатель должен заметить не только итоговую сумму, но и то, что требует решения.
Практический шаблон строки:
- Позиция: очиститель, действующий артикул.
- Было: две упаковки по 1 500.
- Сейчас: две упаковки по 1 600.
- Изменение: новая цена, количество доступно по последней проверке.
- Действие: принять, изменить количество или удалить.
- Подтверждение: окончательные условия определяются согласованным этапом обработки заказа.
Если цена зависит от объёма, показывайте результат пересчёта после редактирования корзины. Если есть минимальная партия, проверяйте её до отправки. Изменение единицы продажи особенно опасно: одна упаковка и одна штука не взаимозаменяемы без явного пересчёта.
Первая версия без лишнего каталога
Для запуска достаточно ограниченного ассортимента постоянного покупателя, истории или шаблонов, корзины, выбора адреса и отправки заказа. Поиск по всему каталогу, рекомендации и сложная программа скидок могут подождать.
Обязательны состояния обработки: черновик, отправлен, требует уточнения, подтверждён либо отклонён. Названия можно адаптировать, сохранив смысл. Клиент должен понимать, требуется ли от него действие.
Добавьте рабочий путь для недоступной позиции и понятное восстановление после ошибки. Если связь прервалась в момент отправки, сначала проверьте наличие созданного заказа. Не предлагайте безусловно нажать ещё раз и надеяться, что дубль заметит менеджер.
Когда выбрать бот, кабинет или готовую платформу
Обычного бота может хватить для короткого структурированного запроса: выбрать сохранённый набор, указать количество и отправить заявку. Когда нужно сравнивать несколько позиций и редактировать корзину, отдельный экран становится полезнее.
Полноценный веб-кабинет стоит рассмотреть для больших заказов, загрузки файлов, работы с множеством документов и сложного распределения ролей. Мини-приложение может быть дополнительным входом в тот же процесс, а не второй независимой системой.
Готовую платформу оцените по вашим условиям покупателей и доступным интеграциям. Заказная разработка оправдана, когда существенный сценарий нельзя выразить настройками либо готовый интерфейс требует неудобных обходных действий. Критерии сравнения подробнее разобраны в статье о готовом и заказном ПО.
Не создавайте второй каталог внутри компании
Назначьте источник карточек товара и условий покупателя. Если менеджеры меняют ассортимент в одной системе, а мини-приложение ведёт собственный список вручную, расхождения появятся ещё до первого повторного заказа.
Отдельно определите, как показывать возраст данных. При недоступности обмена интерфейс может сохранить черновик, но не должен выдавать старое количество за только что подтверждённое наличие. Ответственный за обработку видит, какие проверки завершились, а какие остались открытыми.
Для прекращённых позиций полезен управляемый переход к замене: система предлагает вариант, а покупатель явно его принимает. Совпадение похожих названий не является достаточным основанием для автоматической подстановки другого товара.
Как проверить результат до расширения
Дайте двум ролям клиента пройти один обычный заказ и один заказ с изменениями. Проверяйте выполнение действий, а не впечатление от дизайна.
Минимальный чеклист:
- пользователь видит правильную организацию и адрес;
- старые цены не принимаются за актуальные;
- недоступные позиции не исчезают незаметно;
- единицы и кратность заказа проверяются;
- повтор отправки не создаёт дубль;
- менеджер получает состав и решения клиента;
- подтверждение заказа отделено от регистрации заявки.
Для разговора с ExtentLab подготовьте прошлый заказ и список изменений при его повторе. На этом примере можно обсудить удобный интерфейс, необходимую интеграцию и границы первой версии, прежде чем расширять проект до полноценного каталога.