- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Поделитесь, у кого как построена система статусов заказов.
Сколько у вас их и какова их структура?
Как автоматизируете переключение статусов или все вручную?
Как спроектированы интерфейсы в панели управления?
Ручное переключение с помощью чекбоксов/селектов/радиобатонов или какими-то сложными селекторами?
Используете ли цветовое кодирование?
Как оповещаете покупателей об изменении статусов (письмами, или даете возможность следить самостоятельно)? Насколько востребован этот функционал?
Есть вообще фишки в этой теме новые или все давным-давно изобретено и стандартно везде?
Ну раз никто не ответил, возьмусь я, к тому же вопрос для меня тоже актуальный.
Но, сначала хотелось бы узнать, вы как программист интересуетесь, как поставщик какого-то сервиса/скрипта, как начинающий бизнесмен?
На сколько я понял, сейчас в CMS'ках очень все стандартно и как следствие в реальных условиях функционала не хватает.
Первый момент. Конечно админка должна содержать ссылки на разделы, где лежат товары с заранее определенным статусом. Чтобы не использовать постоянно фильтр, а одним кликом просматривать такие заказы.
Второй момент. Очень хорошо, когда движок позволяет удобно вставлять в php код функций или скрипты, которые отрабатываются при изменении статуса заказа с одного на другой. Это позволит отправлять нужные письма клиенту, оповещать менеджера магазина, снимать товар со склада и т.д.
Очень хорошо, когда админка самостоятельно (каждый день) смотреть статус заказа через интерфейс почта-россии.рф и переводить заказы в новый статус, согласно полученным данным.
Очень хорошо, когда админка позволяет управлять пользователями (работниками магазина) и для каждого пользователя можно разрешить/запретить возможность перевода заказа в тот или иной статус.
И очень не плохо, когда админка может выводить на главной странице или другой, заказы, которые лежат в определенном статусе больше какого-то кол-ва дней.
Очень хорошо, когда статусы заказов можно менять через ajax по нажатию на ссылку на страницах поиска заказов, т.е. не перезагружая станицу.
Конечно очень нужен функционал, который выделяет заказы разными цветами в зависимости от их статуса.
Так же очень хорошо, когда у заказа можно поставить флаг "Важно" или еще какой-нибудь. Ну т.е. какой-то особый или геморойный заказик. И конечно отдельную страницу под такие заказы. Можно на главную список.
Хорошо, когда движок позволяет создавать для заказов дополнительные флаги. Например: "отдан в кур. службу", "получен расчет с почты РФ", "возврат" и прочее...
Но, сначала хотелось бы узнать, вы как программист интересуетесь, как поставщик какого-то сервиса/скрипта, как начинающий бизнесмен?
Интересуюсь как поставщик сервиса www.chopochom.com
Сейчас самый горячий вопрос - схема организации работы со статусами в интерфейсе.
Например, есть статусы: "Новый", "Обрабатывается", "Аннулирован", "Ожидает отправку", "Ожидает оплату", "Ожидает выставление счета", "Подтвержден" и тд. В интерфейсе можно реализовать их переключение обычным селектом или радиобатонами. Это самое очевидное и самое неудобное решение. Во-первых, оно не позволяет контролировать, чтобы из статуса "Выполнен" заказ не мог быть переведен в статус "Новый". Во-вторых, визуально не очевидно на какой стадии сейчас заказ, какие стадии еще нужно пройти, а каких стадий вообще не будет у данного конкретного заказа.
Поэтому и возник вопрос, вдруг кто-то сталкивался с более удобными и понятными решениями, чтобы не изобретать велосипед. Но, видимо, никто так сильно как мы над этим не заморочился :)
Вообще не думаю, что это самое главное. Я себе в админку тоже немного буду исправлять. Сделаю так. У меня будет надпись возле номера заказа, типо его статуса, а где-то в другом месте кнопочка, по нажатию на который выпадает jquery менюшка, в которой можно выбрать новый статус заказа:
-Новый
-В обработке
-Отдан в кур. сл
--Доставлен кур. сл.
--Возврат кур. сл.
-Отдан на Почту Р.
--Доставлен Почтой Р.
--Оплачен Почтой Р.
-Выполнен
-Удален
ПС. Рекомендую сделать в админке возможность быстро создавать/редактировать/удалять/сортировать статусы заказов, а так же группы статусов заказов. Например, группа статусов которые указывают на прохождение заказа по Почте России.
У меня в компании статусы заказов при доставке по Москве:
• Новый – заказ поступил в обработку, попыток подтверждения заказа ещё не предпринималось.
• Не согласован – клиенту пытались дозвониться, но не дозвонились. Соответственно этому клиенту нужно перезвонить через час. Т.к. заказов много, нужно обязательно подобные заказы отслеживать, чтобы у менеджера через час заказ снова всплывал, что по нему нужно перезвонить. После 3 недозвонов попытки прекращаются, заказ переходит в статус «нет контакта». Связано это с тем, что если за 3 часа с клиентом не смогли связаться, то подобные проблемы могут быть и при доставке, а там никто человек по 10 раз звонить не будет.
• Нет контакта – до клиента не смогли дозвониться, он неправильно заполнил форму с телефоном, нет возможности дозвониться.
• Согласован – до клиента дозвонились, дата и время получения получены менеджером. Адрес и сумма подтверждены покупателем.
• Уточнить - для данного статуса есть возможность отметить время уточнения и комментарий. Бывает так, что клиенту перезванивают, а он потом просит перезвонить через n кол-во минут, часов и т.д. и уточнить. Конечно же при большом потоке это просто напросто забывается и забивается.
• Отказ по телефону – клиент по какой-то причине отказался от заказа. Вполне возможно, что он не посмотрел на условия доставки или доставка в его город невозможна. Этот статус обязательно подразумевает комментарий менеджера о причине отказа.
• На сборке – заказ предан на склад для сборки.
• Ошибка на сборке – всегда бывают ошибки, связанные с остатками на складе. Бывает так, что товар пришёл повреждённый, а его не успели списать и т.п. В результате мы в такой ситуации стараемся индивидуально разбираться. Это сигнал к урегулированию ситуации, связанной с отсутствием товара или его повреждением. Если повреждена коробка, то мы предлагаем скидку покупателю, обязательно предупредив его перед этим по телефону, готов ли он взять товар с браком. Это одна из возможностей сливать неликвид.
• Собран – заказ уже собран и готов к отгрузке курьерам или в курьерскую службу. Заказ находится на нашем складе.
• Передан на доставку – заказ передан в логистическую компанию для дальнейшей доставки.
• На доставке – заказ отправлен на доставку курьерской службой или его принял собственный курьер.
• Доставлен – заказ был доставлен, однако деньги за заказ ещё не были получены от курьера или логистической компании.
• Получен расчёт – за заказ получены наличные средства от курьера или от логистической компании. После этого заказ можно уже не вести. Отмечу, что все заказы, оплаченные по безналу, сразу после вручения получают статус «получен расчет» и фактически не имеют статуса «доставлен».
• Перенесён – если клиент переносит заказ, соответственно он возвращается к нам на склад или на склад логистической компании, мы должны так же его вести и следить за подобными заказами.
• Отказ при вручении – клиент отказался от заказа, однако заказ ещё не возвращён к нам на склад. Таким образом, мы отслеживаем товарные остатки, которые болтаются в логистике, чтобы по возможности более оперативно возвращать отказы на собственный склад. Если мы видим такой заказ, это сигнал для менеджера позвонить такому клиенту и выяснить, по какой причине произошёл отказ при вручении. Этот статус обязательно подразумевает комментарий менеджера после прозвона клиента.
• Возвращён – клиент отказался от заказа, и заказ вернулся на наш склад, мы его приняли и выложили товар обратно на полки.
• Аннулирован – этот статус означает, что заказ был отменён до того, как он успел покинуть наш склад. Соответственно перед отправкой заказов кладовщик проверяет, нет ли в статусах аннулированные заказы, чтобы сразу их извлечь и не отправлять.
По регионам у нас система ещё сложнее, т.к. мы постоянно держим клиента в курсе того, что с заказом, используя sms оповещения, обзвон логистической компании и клиента. Ну и +куча всякой служебной инфы к заказу тянется, типа повторный он или нет и т.п.
Также отмечу, что у каждого задействованного в цепочке доступны только его статусы. Т.е. склад не видит статусы менеджеров и наоборот.
При этом у менеджера разные панельки, связанные с текущими заказами и я могу довольно точно сказать, где именно у меня находится заказ №5010298, отправленный в г. Сочи на пункт выдачи 12.06.2012.
Также невозможны противоречения. Т.е. если заказ перешёл в статус "на доставке" для него потом возможны только статусы:
- доставлен
- отказ при вручении
А уже для доставленного можно сменить статус на "получен расчет" и всё.
Соответственно в каждый отдельный момент времени менеджер оперирует всего 2-3 статусами, что довольно просто.
Да, логика есть...
Хотя я при программинге не хотел ограничивать менеджера в том, в какой статус из текущего статуса можно переводить заказ. Потому что часто бывают различного рода исключения и невозможность программно что-то сделать бывает совсем не кстати.
Да, логика есть...
Хотя я при программинге не хотел ограничивать менеджера в том, в какой статус из текущего статуса можно переводить заказ. Потому что часто бывают различного рода исключения и невозможность программно что-то сделать бывает совсем не кстати.
"Часто" исключения возникать не могут, поэтому они и называются исключениями ☝
Чтобы решать нештатные ситуации есть человек, который может перевести заказ из любого статуса в любой. Но на нашей памяти подобных случаев не было.