Система управления заказами на сайте. Разработка системы заказов для клиентов
В статье рассмотрим зачем нужна система управления заказами, из чего состоит система заказов, как создать свою систему управления заказами и покажем наш базовый вариант подобной системы.
Введение
Рано или поздно любой успешно работающий бизнес увеличивает поток заказов. Обработка заказов становится более трудоемкой, и требуется совершенствование системы управления заказами.
Система обработки заказов позволяет решить множество различных вопросов, возникших в связи с ростом продаж.
В статье рассмотрим зачем нужна система управления заказами, из чего состоит система заказов, как создать свою систему управления заказами и покажем наш базовый вариант подобной системы — демо Falcon Service.
Также мы рассмотрим возможные расширения, т.к. как можно сделать подобную систему более эффективной и удобной для пользователей.
Если ваша задача — оптимизировать обработку заказов клиентов, то здесь вы, возможно, найдете решение своей задачи.
Что такое онлайн система заказов
Представим бизнес, который продает на потоке некую продукцию или оказывает услуги.
Система обработки заказов — это некая информационная система, позволяющая вести учет заказов и клиентов в системе, а также проходить весь цикл заказа от статуса Новый до Закрыто.
В простом случае заказы можно вести в тетради, где мы указываем что продали, кому, когда, по какой цене. Улучшенный вариант — это ведение той же тетради, но в Excel файле. Еще более продвинутый вариант, вести тот же Excel в облаке, например, на Google Disk. В этом случае с файлом одновременно могут работать несколько людей.
Эти подходы имеют свои существенные недостатки, который мы описали в отдельной статье.
Система обработки заказов может быть представлена в виде личных кабинетов на сайте. Менеджер имеет свой интерфейс по обработке заказов, заказчик создает заказы и отслеживает ход выполнения заказов, начальник по продажам следит за общими метриками системы продаж.
Также в системе может быть кабинет логиста, который ищет предложения на рынке. Может быть кабинет склада, кабинет инженера, который выполняет расчеты по заказу, кабинет бухгалтера, которые отмечает оплаты по заказу.
Список заказов в личном кабинете
Так может выглядеть страница заказа.
Так может выглядеть страница заказа.
Подобную систему можно неограниченно развивать в сторону глубины проработки заказов — поиск сырья, согласование параметров по проекту, подгрузка данных извне для заказа.
Важно, чтобы система предусматривала подобную возможность кастомизации и развития, но об этом позже.
Зачем нужна система учета заказов бизнесу?
1. Ускорение процесса обработки заказа. Время — деньги. Чем быстрее заказ проходит свой жизненный цикл, тем меньше шансов, что сделка сорвется, меньше требуется ресурсов (помним закон Паркинсона: «Работа занимает все отведенное для нее время»).
Чтобы что-то ускорить, необходимо это измерить. Для этого необходимо фиксировать все задержки при обработке заказа и находить узкие места.
Если это делать в Excel, очень сложно фиксировать время. В личных кабинетах можно логировать любое действие, например, смену статуса Заказа. Это позволяет выявлять отрезки, где заказ просто стоит на месте без движений.
Также задержки могут стать частью KPI для персонала, занимающегося заказами. Быстрых необходимо поощрять и ставить их KPI в качестве стандарта работы.
2. Стандартизация системы обработки заказов.
Чем стандартнее выполняется каждый конкретный заказ, тем меньше ресурсов тратится на его обработку и меньше ошибок возникает при обработке заказа.
Система обработки заказов задает некую лыжню, которой обязан следовать каждый человек, работающий в системе. Можно сильно ограничить человека в свободе отхождения от процесса. Эту степень свободы можно варьировать за счет бизнес-правил.
Системы на основе Excel дают слишком много свободы оператору, поэтому и стандарты сложнее соблюдать и контролировать. Система обработки заказов позволяет повысить точность в распределении задач сотрудников относительно заказа.
Каждый выполняет строго отведенную роль в процессе обработки заказа. На практике этого не так легко добиться, и требуется итеративное приведение процесса к нужной Лыжне (реализация базового процесса и постепенное закручивание гаек).
3. Логирование событий по заказам в системе. Каждое действие по заказу можно записывать в базу данных для дальнейшего анализа.
Можно составить цифровую картину, как в реальности работает ваш бизнес в плане обработки заказов. Эта информация будет максимально объективна. Система просто фиксирует все события по заказам и действиям сотрудников относительно заказов.
4. Метрики и статистика по заказам в системе. Множество структурированных данных о заказах позволит получить массу интересной информации по заказам:
где возникают задержки?
кто наши главные клиенты по деньгам?
где возникают перерасходы и почему?
находить позитивные аномалии (сверх ожидаемого положительный результат) и делать выводы, как это удалось;
у кого какая нагрузка по заказам? кто простаивает, кто больше продает и т.д.
какие регионы дают больше выручки?
Понимание этих вопросов повышает вероятность принятия правильных решений.
5. Уменьшение человеческого фактора при обработке заказов и зависимости от конкретных людей. Чем точнее система построена, тем меньше все завязано на личности. Это снижает риски бизнеса в случае ухода ключевых людей.
Сама система становится ключевым объектом. В идеале необходимо разложить процесс заказа на атомарные составляющие, каждая из которых не требует уникальных навыков. Получается в итоге конвейер обработки заказов, где каждый человек играет строго определенную роль.
Второй момент — это ошибки. Человек устает, человек отвлекается. Система должна «присматривать» за своим оператором, помогать ему избегать ошибок. А если они возникли, то подсказывать, как их можно исправить.
6. Дистанционное обслуживание клиентов через личный кабинет. Удаленное взаимодействие с клиентом дает множество преимуществ. Можно параллельно обрабатывать сразу несколько запросов. Один оператор может взаимодействовать через чаты сразу с несколькими клиентами. Не требуется время на перемещения и задержки, связанные с пробками, очередями, опозданиями.
Уменьшается время на церемонии приветствия и разговоры на общие темы. Человек обращается со своей потребностью, а вы сразу приступаете к решению его задачи/обработке заказа без лишних слов.
7. Возможность массовой обработки заказов (когда нет центрального диспетчера)
Если клиент может сам создавать заказ через личный кабинет, то нет необходимости делать некий пул, в который поступают обращения клиентов для создания заказа (например, по телефону).
Это дает возможность обрабатывать множество обращений в единицу времени. Клиенты создают заказы, и они сразу поступают на обработку без лишнего перенаправления с задействованием человека.
8. Экономия на ФОТ. Чем меньше нужно людей для обработки заказов, тем лучше для бизнеса. Необходимо повышать отдачу от каждого сотрудника за счет автоматизации.
При ручной обработке сотрудник может обработать 5 клиентов в час, а через систему это может быть 1000 (т.к. нет жесткой привязки клиента ко времени сотрудника).
Автоматизация — это не разовое действие-внедрение, а постепенный процесс повышения эффективности сотрудников в системе.
9. Система оформления заказа не позволяет потерять или сломать информацию. Вся информация хранится в едином месте — в базе данных системы, причем в строго структурированном виде. Это позволяет ее анализировать и использовать более эффективно, нежели это были были некие файлы и папки на диске.
Если у системы есть регулярное обслуживание, делаются бекапы. Это позволяет с уверенностью сказать, что данные не потеряются. В случае возникновения аварии можно восстановить прошлую копию (за прошлый день).
Сотрудники работают через интерфейс личных кабинетов. В этом случае проблематично взять и сломать полбазы, т.к. интерфейс обычно подразумевает точечные изменения в данных. В случае с Excel файл очень легко повредить данные — выделить все и удалить, случайно вставить большой кусок информации не туда. В случае с бумажными документами — они могут сгореть, их могут вынести, вырвать некоторые листы, на них могут пролить кофе.
10. Прозрачность и оперативность получения информации. Главная выгода от работы системы — множество данных для анализа ситуации. Можно разработать такие отчеты, которые будут наглядно показывать различные срезы по жизнедеятельности вашего бизнеса.
Любой отчет нужен для принятия определенных решений. Подумайте, какая информация вам нужна для принятия решений (и какие это будут решения). Также важно получать информацию вовремя, а не через месяц после события. Для этого используются уведомления. Система может анализировать данные в базе по определенным правилам и уведомлять вас о каких-то ключевых важных событиях, когда требуется ваше вмешательство (например, долго заказ висит в отгрузке, клиент написал рекламацию и т.д.)
11. Уменьшение количества ошибок по заказам. Система позволяет выявлять проблемные, зависшие заказы. Можно отслеживать дубли по заказам или клиентам.
Строгие форматы данных позволяют минимизировать ошибки операторов при занесении информации (например, внесение телефона вместо email).
Система регистрации заказов. Что важно учесть? Проблемы системы заказов
Имеет смысл сразу представлять в общих чертах нюансы по использованию системы обработки заказов. Это позволит избежать неприятных казусов в ходе эксплуатации системы.
Гибкость, адаптация системы под процессы компании.
Система должна адаптироваться под процесс продаж, а не продажи под систему.
Именно процесс продажи и обработки заказа может быть конкурентным преимуществом компании. Будет неправильно ломать свой процесс в угоду некой системы. Если система негибкая, и ее сложно менять, то любые инновации по процессу обработки заказа будут тормозиться. Система должна позволять быструю адаптацию под изменяющиеся реалии бизнеса.
Какие это могут быть изменения?
внедрение нового этапа в жизненном цикле заказа;
внедрение новой роли в систему;
добавление новой информации к заказу;
наделение клиента дополнительными возможностями в его личном кабинете;
интеграция с программными системами клиентов и т.д.
Работа на разных устройствах системы учета заказов. Крайне важно иметь возможность оперативного доступа к информации в системе. С телефона, на даче, в авто, может быть, в застрявшем лифте.
Это позволит оперативно управлять некими процессами и вносить коррективы. Если система работает через браузер через Интернет, то она доступна практически везде и всегда. Это дает вам возможность физически находиться где угодно, но при этом сохранять оперативную связь со всей бизнес-системой.
Уведомления. Насколько гибко можно управлять уведомлениями? Куда они могут приходить? Можно ли убирать ненужные уведомления? Все это очень важные вопросы, ведь при очень большом потоке ненужных уведомлений, вы просто перестаете на них реагировать.
Уведомления должны быть триггером к некоторому действию, а не превращаться в действие само по себе — «так, сейчас мне надо разобрать кипу никому не нужных уведомлений». Создание правильных уведомлений — итеративный процесс. Вы по ходу использования системы будете придумывать все более тонкие случаи, когда вам будут нужны уведомления.
В начале создания системы важно знать, что у вас будет возможность создавать очень гибкие уведомления, которые будут создаваться на специфичные ситуации в процессе обработки заказов.
Уровни доступа в системе. Каждый сотрудник должен иметь для работы все необходимое, но не более того. Лишние доступы повышают бизнес-риски. Если человек работает только с заказом А, то ему не нужно ничего знать о заказе Б. Руководитель отдела продаж может знать все о продажах, но не нужно давать ему информацию о деталях производства.
Должна быть возможность тонкой настройки доступов. В системе Falcon Space это делается за счет ролей + на уровне прописывания доступа к объекту для конкретного пользователя на SQL. Это позволяет очень гибко задавать разграничение доступа для людей, работающих в системе.
Скорость выполнения операций и быстродействие системы. Если система тормозит, это очень напрягает пользователя. При работе с системой человек не должен замечать деталей загрузки. Он должен быть сосредоточен на бизнес-процессе, а не злиться, что страница долго загружает отчет.
При быстрой работе системы у пользователя вырабатывается некий ритм работы, и уменьшается количество отвлечений, что повышает производительность человека.
Простота, понятность и защита от ошибок. Оцените удобство работы с системой. Неудобная непонятная система будет провоцировать пользователя на ошибки. Система должна вести пользователя для достижения нужных целей, а не быть препятствием.
В сложных местах система должна подсказывать пользователю как поступить, что ввести, в каком формате и в какой стадии процесса он находится. Делайте интерфейс системы максимально простым (со временем он все равно станет сложным из-за новых внедрений). Это позволит снизить порог входа для пользователей системы и уменьшит количество ошибок операторов.
Минимизация издержек по времени. Система должна позволять находить временные издержки. Это не просто инструмент учета данных, но инструмент учета времени.
Любой бизнес — это движение от статуса к статусу. Чем быстрее это движение — тем больше мы можем выполнять операций за день, неделю, месяц.
Важно уменьшать этот промежуток времени между статусами. Чтобы его уменьшить, его надо фиксировать и измерять. А затем анализировать и принимать управленческое решение.
Система обработки заказов должна позволять фиксировать любые временные интервалы при изменении состояния (статуса) любого объекта (заказа, заявки на склад, этапа проекта и т.д.). Ни одна готовая коробочная система не сможет этого дать по умолчанию. Это ваш уникальный опыт и способ работы с временными издержками, специфичными для вашего бизнес-процесса обработки заказов.
Метрики и показатели работы системы контроля заказов. Метрики по умолчанию в системе не годятся. В ходе работы будет возникать необходимость получения узких, нетривиальных метрик, которых скорее всего не будет среди начального набора.
Важно иметь возможность собирать все необходимые данные относительно работы над заказами и иметь возможность делать аналитические отчеты по этим данным.
Система распределения заказов — цикл заказа
У каждой вещи есть жизненный цикл. Заказ — не исключение. Весь заказ можно разбить на некоторые стадии, которые он последовательно проходит. Эти стадии, статусы являются скелетом системы обработки заказов. Статус определяет, что сейчас происходит с заказом, и что необходимо дальше делать с заказом.
Заказ существует не в вакууме. Его обрабатывают различные люди, выполняющие свою часть работы по исполнению заказа. Менеджеры готовят КП. Инженеры делают техническую оценку проекта. Юристы согласуют договор. Бухгалтер выставляет счета и фиксирует оплаты, склад отгружает, логист обеспечивает комплектующие заказа.
Каждый выполняет над заказом строго определенную функцию, не влезая в чужой огород. На странице заказа сотрудник имеет только те возможности, которые обусловлены его ролью и текущим статусом заказа.
Это можно представить в виде таблицы, где строки — это роли в системе, а столбцы — статусы заказа. На пересечении — что может делать с заказом в данном статусе сотрудник данной роли.
Пример статусов заказа.
Стандартную схему выполнения заказа можно представить следующим образом: Лид (Интерес) — Запрос КП — КП — Договор — Оплата — Производство (и комплектация) — Поставка — Закрытие документами — Сервис.
1. Интерес. Есть некий потенциальный клиент, который оставляет заявку на возможную продажу (т.е. проявляет интерес). Это еще далеко не заказ, но уже создается заявка, которая является прообразом будущего заказа.
2. Запрос КП. Наша задача стимулировать клиента создать формальный Запрос КП, в котором он укажет все значимые данные по заказу, необходимые для калькуляции стоимости заказа.
В нашем случае мы просим заказчика создать концепцию проекта и бесплатно помогаем ее составить в случае затруднений. Концепция проекта никак не завязана на нас и нашу платформу, и является более формальным описанием фантазий клиента по поводу своего проекта.
3. КП. На основе хорошо сформулированного запроса можно сделать коммерческое предложение, которое будет содержать смету затрат, сроки, детализацию по работам и особые условия, специфичные для данного клиента.
Данный этап может быть более сложным и может быть разбит на подэтапы, т.к. в некоторых случаях требуется более глубокая проработка технической части проекта. В этом случае подключаются инженеры, вводятся дополнительные стадии подготовки КП.
В нашем случае КП готовится в CRM и затем выгружается в виде Excel файла для клиента и передается по почте. Пример шаблона.
4. Договор. Заключение договора, оформление бумаг, обмен бумагами, отметка факта получения документов.
В системе очень важно фиксировать все артефакты по процессу обработки заказа. Это позволит в будущем более точно восстановить картину событий по заказу.
Мы исходим из принципа, что все, что связано с заказом, должно храниться в едином месте. Т.е. точка входа в заказ должна быть единой — это страница заказа в личном кабинете.
5. Оплата. Необходимо получить оплату по заказу. Этот факт фиксирует в системе одна из ролей (например, бухгалтер или менеджер). Имеет смысл это выделять в отдельный этап, если вы ни при каких обстоятельствах не начинаете работу по заказу, пока не будет денег.
Если это не так, то можно сделать просто признак заказа оплачен или нет, но при этом не делать отдельный статус (например, вы можете сразу перевести в статус Производство еще не оплаченный заказ и начать над ним работу).
6. Производство. Выполняем основную работу по заказу. Если это продажа готовых товаров, то это скорее сборка и комплектация. В случае услуг или создания товаров, это может быть большой внутренний цикл и даже создание отдельных заявок на производство со своими статусами.
7. Поставка. Товар или результат оказания услуг необходимо поставить клиенту. Зафиксировать факт поставки. Если поставка сложная, то можно дополнительно создавать заявки на транспортировку внутри системы, либо создавать заявки во внешние системы (например, создавать заявку в транспортной компании по API).
8. Закрыто. После выполнения всех работ заказ необходимо подкрепить закрывающими документами, например, актом выполненных работ. Обязательно занести артефакты в систему. Это может быть скан подписанного документа.
Вы можете сделать так, что закрыть заказ без подобного скана было просто нельзя. Т.е. в некой степени у вас будет уверенность, что все закрытые заказы будут иметь все необходимые закрывающие документы.
9. Сервис. Если ваш процесс обработки заказа предполагает постпродажный сервис, то дальше вы переводите в Сервис, проставляете некие даты-напоминания по заказу (провести профилактический осмотр продукта через год), отправляете клиенту некие заранее подготовленные КП на дополнительные услуги по сервису.
Примерно так может выглядеть процесс обработки заказа. Может быть много нюансов по разделению статусов, созданию дополнительных типов заявок (транспортировка, ремонт, оценка). Именно поэтому при глубокой проработке процесс заказа будет уникальным в большинстве случаев.
Что необходимо учесть при движении заказа по статусам в онлайн системе заказов
Задержки в обработке заказа. Задержки могут иметь систематический характер. Наша задача — понять, где задержка, в чем причина возникновения и как можно ее нейтрализовать.
Понять это можно, используя статистические параметры. Вы можете для каждого заказа замерять средние значения времени нахождения в статусах и делать выводы, где задержка аномально высока.
В чем могут быть причины задержек: перегрузка сотрудника, халатность (просто забывают и забивают на заявки), отсутствие важного уведомления, нет контроля, нечеткий процесс обработки.
Артефакты статуса заказа. В идеале каждый статус должен иметь свое фактическое подтверждение. Поставили заказ в статус Отменился — хорошо бы дать скрин сообщения Клиента в мессенджере, где он отменяет заказ.
Это упрощает дальнейший анализ по истории заказа. У вас будет не только оценочное суждение менеджера, но и точный артефакт, который подтверждает установку данного статуса. В качестве артефакта может выступать созданный документ (КП), скан документа (акт), фото переписки, голосовая запись, скан отзыва клиента.
Объем уведомлений. Необходимо варьировать объемом уведомлений. Слишком много малозначимых уведомлений — плохо. Люди просто перестанут на них обращать.
Уведомление должно прямо стимулировать получателя на определенное действие. Пришел новый заказ — проверь его и запусти в обработку. Уведомления типа «У вас много открытых задач» не очень помогает. Оно просто усиливает стресс человека, и он меньше будет обращаться к этому инструменту.
Цифровые следы клиента и менеджеров. Каждое действие по заказу логируется. Сменили статус — это записалось в лог. Клиент скинул дополнительный файл — тоже запись в логе.
В итоге потом можно полностью восстановить полную картину действий по заказу — от первого обращения до закрытия заказа: кто, что, когда делал по этому заказу. Это удобно. Но это работает только в том случае, если все процессы работают через систему.
Автоматическая обработка событий по заказу. Некоторые элементы обработки заказа можно автоматизировать. Это уменьшит нагрузку на персонал и уменьшит количество возможных ошибок и задержек.
Постепенно все, что возможно надо автоматизировать. Сначала заказ может создавать менеджер в системе, но постепенно можно внедрить кабинет клиента, и он сам будет создавать себе заказ.
Также необходимо свести к минимуму неформальное взаимодействие менеджера и клиента: звонки по телефону и встречи. Чем меньше неформализованного взаимодействия, тем проще его контролировать, улучшить и автоматизировать.
В идеале добиться такого состояния, когда менеджеру и клиенту совсем не требуется личного общения.
Клиент оформляет заказ в личном кабинете, менеджер обрабатывает, выдает информацию по заказу в строго типизированном виде, клиент через ЛК подтверждает параметры.
Дополнительное общение может потребоваться только в случае нештатных ситуаций или проблем.
Из чего состоит система исполнения заказов и учета клиентов
Здесь мы рассмотрим основные блоки и возможности, которые могут быть реализованы в подобной системе управления заказами.
Кабинет менеджера по продажам. Менеджер является центральным звеном в системе и координирует все процессы по заказу. Основной функционал для менеджера — списки заказов и процесс обработки заказа.
Кабинеты директора, начальника отдела продаж (НОП). Директора, как и НОП, интересуют общие метрики продаж. Также его могут интересовать проблемные места: где возникают проблемы, рекламации, задержки и потери (возвраты).
Функционал этого кабинета — это отчеты с возможностью детализации, а также общая статистика в виде дашбордов и графиков.
Кабинет клиента, клиентский сервис. Клиент самостоятельно входит на сайт в свой личный кабинет. Он может посмотреть свои заказы, состояние по ним. Главный функционал — он может самостоятельно формировать заказ и давать по нему обратную связь. Это уменьшает нагрузку на персонал компании.
Кабинет администратора. Это служебный кабинет для обслуживания системы. Администратор меняет настройки системы, добавляет и блокирует пользователей, управляет структурой каталога, модерирует данные (если необходимо).
API — программный интерфейс системы. Вполне возможно, что вашим клиентам будет удобно создавать заказ не из личного кабинета, а их своей 1С или другой учетной программы.
В этом случае система должна предлагать некий API, к которому смогут подключаться клиенты. Методы API делаются под каждую систему отдельно. Это может быть создание заказа, получение заказа, загрузка каких-то данных по заказу, получение уведомления.
API может быть, как со стороны системы, так и со стороны клиента. Т.е. система при наступлении определенного события будет вызывать метод АПИ внешней системы (например, выполнять определенный GET или POST запрос на внешний адрес).
Модуль оплаты. Если оплата происходит в клиентском кабинете, то должен быть интегрирован платежный шлюз, который позволит принимать платежи на расчетный счет через различные средства: карты, электронные деньги, терминалы и т.д.
Альтернативный вариант — это подготовка документа счета для последующей оплаты клиентом в ручном режиме.
Каталог. Если есть некая номенклатура товаров, которые клиент может заказывать, то имеет смысл сделать удобный каталог для поиска подходящей продукции.
Пример каталога в нашем демо. Каталог может содержать категории, фильтры, а также различные способы отображения товаров.
Каталог необязательно должен быть представлен в привычном для интернет-магазинов виде. Это может быть и просто таблица с кучей фильтров с более лаконичным интерфейсом и более функциональными возможностями (дополнительные операции над выбранными товарами).
Поддержка пользователей. Это некая тикет-система, позволяющая обрабатывать вопросы пользователей: как клиентов, так и менеджеров.
Смысл такой системы не только в помощи пользователям, но и в улучшении самой системы. Если пользователи задают одни и те же вопросы, имеет смысл внести коррективы в интерфейс системы, чтобы люди сразу понимали его верно.
Склад и доставка. Это две большие подсистемы, которые обеспечивают логистику. Конечно, можно использовать и некое внешнее решение, но все же удобно, когда вся обработка данных делается в едином месте, и не нужно морочиться со сложной интеграцией.
Сюда же можно отнести и систему ремонта, если мы используем некоторое оборудование, задействованное в обработке заказов (либо суть заказа — аренда некоего оборудования).
Производство. Если заказ заключается в создании чего-то, то нужен блок Производство, где фиксируются основные моменты по выполняемому заказу. Само производство может фактически выполняться в другой системе, но важно отмечать ключевые события в системе управления заказа.
Этот блок может быть, как очень простой (отметка Производство завершено), так и целый блок с множеством ролей, когда весь процесс производства выполняется по шагам в системе. Если брать наш пример, то мы отдельно ведем CRM и отдельно ведем систему реализации клиентских проектов. При этом связь между системами есть, и она реализована через специальные поля связи (идентификатор клиента).
Финансы и бухгалтерия. Финансовый блок позволяет отслеживать затраты, вести отчеты БДДР, БДР. Отслеживать платежи.
Часто бухгалтерия использует продукты 1С, в этом случае имеет смысл делать интеграцию системы обработки заказов с бухгалтерией 1С — передавать в нее данные по заказам и получать информацию об оплатах.
Программа лояльности клиента.
Один из способов удержания клиента — внедрение программ лояльности.
Чем больше покупает клиент, тем больше преференций он получает. Выражаться это может по-разному. Например, карта лояльности, участие в клубах, скидка для VIP клиентов.
Личный кабинет в этом плане позволяет аккумулировать накопления клиента. Можно выводить его процент скидки, его бонусы, его принадлежность неким клубам (пример -IKEA Family). Читайте более подробно о системе лояльности в личном кабинете.
Можно очень тонко персонализировать работу с клиентом (но работает с клиентом не менеджер, а система в целом). Также можно стимулировать клиента делать то, что выгодно системе через награду бонусами, которые можно конвертировать в продукцию компании.
Обратная связь покупателя. Личный кабинет клиента позволяет в ненавязчивой форме внедрить сбор обратной связи. Например, после каждой покупки просьба оценить заказ. Если меньше 4, то спросить кратко, что не так.
И все это без надоедливых звонков. Захочет ответить — проголосует. Не захочет — проигнорирует. Хороший момент для вовлечения клиента через баллы: начислить баллы (за голосование, к примеру) и дать возможность их потратить на что-то полезное.
Чем больше вы получаете адекватной обратной связи от клиента, тем точнее вы можете оказывать сервис.
Тем больше у вас будет возможностей по более плотной работе с клиентом.
Задачи для сотрудников. Если заказ движется по статусам, то люди в системе двигаются от задачи к задаче. Вы можете связывать различные статусы заказа с различными задачами. Можно это назвать заявками.
Заказ сформирован? Менеджер ставит задачу (или создает заявку) на его транспортировку. Задачи могут быть как привязаны к чему-то (заказу, проекту, клиенту), так и просто быть сами по себе (проработать конкурента в сети).
Задача — это минимальный юнит работы компании.
Делать свою или использовать готовую? Совершенствование системы управления заказами
Вероятно пока у вас в голове не возник этот вопрос. Но будет не очень хорошо, когда вы выбрали какую-то систему, поработали в ней некоторое время, а потом оказывается, что она имеет существенные ограничения.
Как определиться какой тип системы управления заказами подойдет? Предлагаю следующую схему.
Простой и стабильный процесс обработки заказа. Если ваши процессы стабильны и просты, и вы не планируете как-то особенно совершенствовать свой процесс обработки заказа, то ищите подходящую готовую систему. Не факт, что она существует. Но факт, что подходящее готовое решение будет дешевле внедрить, нежели делать свою систему (при адекватных условиях приобретения решения). Если же такой системы на примере нет, то переходим к следующему варианту.
Своя система на некой платформе. Если ваш процесс может меняться, либо вы стремитесь непрерывно оттачивать свои процессы — берите готовое решение на платформе с возможностью доработок.
Это наш вариант. Наша платформа Falcon Space имеет готовое решение для обработки заказов, которое можно дорабатывать как угодно и развивать в любую сторону:
добавлять новые кабинеты;
менять внешний вид;
изменять структуру данных по заказам;
внедрять новые процессы.
Этот вариант предполагает проектную часть (т.е. адаптацию решения под процессы компании). Следовательно, он более дорогой чем, покупка готового решения. Однако, это ни в какое сравнение не идет по стоимости с 3 вариантом — разработка системы с нуля под свои нужды.
Главные преимущества этого подхода:
скорость доработок и изменений в системе;
невысокая стоимость владения продуктом;
получение широких возможностей платформы в текущий момент и в будущем при обновлениях платформы.
Основной минус — система налагает свои архитектурные ограничения (именно они позволяют добиться громадного прироста по сравнению с разработкой с нуля).
Своя система — разработка с нуля. Это Fullstack разработка системы с подключением целой бригады программистов, дизайнеров, аналитиков, тестировщиков.
Раньше мы делали проекты именно в этом сегменте. Он подходит очень немногим. Это те проекты, где нужно все сделать максимально под свои нужды, по своим стандартам, с сильным упором на масштабирование и полной независимостью от каких-либо платформ.
Главные минусы разработки с нуля:
Дорого — многие вещи делаются под проект. Любая новая доработка — это именно создание чего-то нового, а не просто настройка в системе. Клиенты, привыкшие к CMS с настройками, недоумевают, почему они платят за очевидные вещи — в этом случае они не правы, т.к. они сами выбрали путь разработки с нуля. Они получили максимальную гибкость, но за нее есть своя плата.
Долго — процесс fullstack разработки довольно сложен, и подразумевает довольно много сервисных телодвижений. Любая доработка (даже просто добавление поле в Заказе) проходит кучу стадий, и зачастую требует участия нескольких специалистов. Если на платформе это можно добавить на 1–2 часа с проверкой, то здесь все может растянуться на пару дней.
Много багов — если система делается с нуля, в ней много нового непротестированного кода. Этот код на 100% содержит ошибки. Будет некий период стабилизации кода — будут всплывать ошибки, которые нужно править (а правка идет не так быстро, как хотелось бы). Постепенно багов станет меньше, но все же этого момента не избежать в подобных проектах.
Система управления заказов на базе веб-платформы Falcon Space
Наша платформа Falcon Space и ее решения — это второй вариант, где мы готовим множество готовых к употреблению кирпичиков из которых собирается новая система. Эти кирпичики можно гибко комбинировать за счет использования SQL. Вся доработка ведется прямо в кабинете. Это позволяет делать быстрые изменения в системе.
Для технического сопровождения и развития системы надо знать всего лишь 2 популярных технологии:
SQL Server (бизнес логика и хранение данных);
Bootstrap (стилизация интерфейса).
Как создать систему обработки заказов в виде личных кабинетов
В этом разделе обсудим как создать свою систему управления заказами по шагам.
1. Начальное описание системы учета заказов. Мы называем это концептом проекта. Создайте базовое описание системы своими словами, без технических терминов. Более подробно. Там же вы найдете шаблон концепции проекта.
2. Оценка реализации проекта. На базе концепта можно сделать первичную оценку и получить КП. Это даст вам ориентир по срокам и стоимости внедрения первой версии программы. Чем точнее начальное описание системы, тем точнее будет оценка проекта.
3. Создание технического задания на систему учета заказов. Обычно это первый этап проекта, где в виде документа детально фиксируется основные требования по системе.
ТЗ может включать как элементы описания, так и элементы реализации, т.е. как будет выглядеть система, структура страниц, структура базы данных и т.д.
Подробнее про создание ТЗ. После написания ТЗ происходит детализация оценки, и именно она является основой для дальнейших этапов до внедрения первой версии программы.
4. Реализация системы управления заказами. Создается тестовый стенд, и на нем постепенно появляются новые кабинеты, новые страницы и функции на них.
Параллельно с работой программистов есть возможность смотреть и пробовать работать с системой. Да, она пока не имеет множества функций, но вы можете внести коррективы в процесс, дать обратную связь и начать первое знакомство с ней. Реализация первой версии программы обычно занимает 1–2 этапа (1 этап — это около 3–4 недель).
5. Внедрение в эксплуатацию системы заказов. Внедрение в эксплуатацию подразумевает переподключение всех аккаунтов на основные, чистку базы от тестовых данных, заведение пользователей в системе, обучение и поддержку пользователей.
На первых порах может быть довольно много обращений: где-то всплыли ошибки, где-то можно сделать удобнее, или возникло замедление страницы. Постепенно количество этих обращений уменьшится. Важно организовать оперативную работу по обработке обратной связи от пользователей.
6. Сопровождение и развитие системы работы с заказами. Любая активно используемая система не стоит на месте. Появляются новые идеи как ее улучшить, сделать более удобной для пользователей. Также могут всплывать ошибки, которые нужно оперативно обрабатывать. Для этого необходимо систему поддерживать.
Более подробно процессы поддержки, развития и сопровождения в рамках работы на платформе Falcon Space описаны здесь.
Процесс создания любой учетной системы итеративный по своей сути. Вы не можете знать, что вам потребуется через год. Не смысла пытаться угадать все наперед. В этом случае велик риск сделать какую-то ерунду, которая не приживется в компании. Действовать лучше по этапам, постепенно наращивая возможности системы и шлифуя ее.
Расширенные возможности для онлайн системы учета заказов
Система может быть очень простой, например, это просто таблица заказов и страница заказа. Рассчитана для одной роль менеджера.
А может быть очень сложной — много ролей в системе. Согласование деталей по заказу. Подготовка документации. Витиеватый путь заказа по статусам. Сложная бизнес логика по автоматическим действиям при смене заказов.
Здесь мы обсудим несколько дополнений, которые могут быть в вашей системе обработки заказов.
Бот телеграм для уведомлений и команд по заказу. Чем удобны мессенджеры? Они всегда под рукой. Они быстро работают, не требуют загрузки, они всем понятны. Сотрудник может получать некоторые уведомления прямо в мессенджер, что увеличит степень оперативности на события системы. Также он может через телеграм выполнять некие управляющие действия — отправить заказ клиенту, закрыть его или передать заказа дальше по циклу.
Почему именно телеграм, а не вацап, Viber?
Во-первых, у телеграм гораздо все лучше обстоит дело с API (широкие возможности, низкий порог входа по условиям).
Во-вторых, в нашей платформе интеграция с ботом Телеграм идет из коробки! Для управления ботом надо знать только SQL подробнее.
Интеграция с Гугл диск для работы с документами. Google Disk — внешнее хранилище, позволяющее работать с различными типами файлов — Таблицы, Документы, Презентации и др. Вы можете хранить документы на Google Disk и прямо из кабинета редактировать их в интерфейсе Excel таблицы или Word документа.
Можно генерировать файлы из шаблонов с данными клиента и экспортировать их в PDF, с последующей отправкой клиенту на электронную почту. Все это возможно реализовать на базе нашей веб-платформы. Демостенд работы с Google Drive.
Ежедневные отчеты на почту. Возможно кому-то из системы будет удобно получать некую сводку на почту. В этом случае можно реализовать гибкие отчеты, которые будут автоматически формироваться в назначенное время и отправляться на почту.
Это может быть состояние продаж за день, ежемесячный отчет о продажах, результаты сотрудников за определенный отрезок времени.
Интеграции с другими системами. Чем глубже интегрирована ваша система управления заказами с внешним миром, тем меньше будет человеческих ошибок, ручных операций и задержек по обработке данных.
Важно, чтобы система могла иметь возможность интегрироваться по API с любыми системами. Платформа Falcon Space имеет универсальный API, который работает через HTTPS GET/POST запросы в формате XML, JSON. Вся настройка API осуществляется также через SQL. Подробнее про API Falcon Space.
Постановка целей и KPI. KPI — это ключевые показатели, которые стремятся достигнуть в компании. KPI может быть у человека (количество выставленных КП за день), у отдела (общая выручка за месяц) или у всех компании (количество новых клиентов).
Установка KPI явно показывает направление, куда должна двигаться компания. KPI может стать основой для системы премий и стимулирования сотрудников. Технически выражаться KPI в виде неких панелей результатов, которые видят все. Также на этой панели можно размещать результаты премирования за прошлый период. Таким образом, все видят, к чему стремиться и работают над достижением этой цели.
Система автоматического заказа — как это может выглядеть
У всех есть телефон. И надо полагать, что для оперативной информации люди будут заходить в систему именно с телефона.
Итак, пользователь набирает адрес сайта, вводит логин и пароль, и попадает на свою панель — дашборд. Он видит ключевые цифры по своей работе, видит заказы, где требуется от него какие-то действия.
Также он может посмотреть уведомления по системе. Критичные отмечены красным. Некритичные синим. Далее он переходит в один из заказов, где может поменять статус, добавить документ, некие данные в поля или прокомментировать в чате текущее состояние по заказу.
Какие-то роли будут работать всегда с ПК. Вероятно, большая часть обработки проводится в таблицах, подтаблицах и модальных окнах для получения дополнительной информации или выполнения действия по отдельным заказам.
Красота и эстетика дизайна — не главное в таких системах. Упор необходимо делать, чтобы пользователь вообще не замечал, что он работает с системой. Он не должен обращать внимание на детали системы. Он должен быть сконцентрирован на решении своих задач. Поэтому система должна быть предсказуемой, быстрой и простой для понимания.
Заключение
Рассматривайте внедрение системы обработки заказов не как статью расхода, а как стратегическую инвестицию, как совершенствование системы управления заказами. Именно система в итоге будет работать как конвейер по движению заказов. Систему нужно строить под процессы, а не наоборот. Бизнес будет меняться, а система должна поспевать за ним.
Идеал подобного процесса:
Когда каждый знает в точности, что делать, как делать и когда делать.
Когда нет никаких задержек и заказ очень быстро проходит все стадии от Новый до Закрыто.
Когда заказчик доволен и готов рекомендовать ваш сервис.
Когда любые аномалии и отклонения сразу можно отследить и выяснить причину их возникновения.
Когда клиент может делать множество операций по заказу самостоятельно, тем самым снижая нагрузку на ваши ресурсы.
Достичь идеала трудно. Если использовать жесткую систему, которую невозможно или сложно менять, это становится невозможным. Двигайтесь итеративно к своему идеальному процессу обработки заказа.
Начните с описания концепта проекта: какие возможности будут в системе, какие роли будут, какой будет жизненный цикл заказа. Это станет отправной точкой по созданию своей системы управления заказами.
Falcon Service — сервис с личными кабинетами для клиентов и менеджеров на точках предприятия (филиалы, департаменты и т.д.). Смотреть демо
Кейсы
Неделя рекламы 
Новости 
How to 
Интервью и дискуссии 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании 
