Если у ваших менеджеров есть четкие правила работы с клиентом, то в нашей системе вы можете контролировать выполнение этих правил + вы можете качественнее диагностировать проблемы в вашем бизнесе, а в частности в продажах.
Например:
— контроль времени ответа за запрос — может быть менеджер курил, а не отвечал важному клиенту.
— контроль времени на резервирование товара — возможно ваши менеджеры тратят 30% своего времени на — разбор спорных ситуаций — клиент говорит просил забронировать, а менеджер говорит что не просил. Клиент не доволен.
— При болезни менеджера его контакты не удобно обрабатывать другому менеджеру. В случае с сервисом это очень просто, достаточно открыть 2 аккаунта.
С первым согласен.
По второму: Приоритеты зависят от политики компании. У одной компании не большой склад, поэтому она пытается обеспечить товарами по больше мелких клиентов, а не отдавать все нескольким крупным. Другие, у которых склад по больше продают в первую очередь крупные заказы.
Единственных нормальным показателем эффективности является оборот менеджера. И только по нему можно оценить качество его работы. Собственнику важнее чтобы увеличивался или был стабильным оборот.
Тем компаниям, на которых ориентирован сервис необходимо хотя бы контролировать чтобы менеджер не забыл ответить клиенту или ответил за 1 час, а не за 8.
Время ответа на запрос заданный по телефону или аське тоже может сильно варьироваться. Если менеджер не загружен, а это бывает крайне редко, он ответит быстро. Обычно ИМ звонит, задает вопрос и ждет ответ в ICQ или ответного звонка. Или задает вопрос в ICQ и ждет ответа. Иногда можно ждать больше суток.
У нас упор сделан на 2 вещи:
1. Если сервис окажется удобнее чем стандартная схема, то участникам процесса будет просто приятнее работать и проще. Количество пользователей будет расти и как следствие, это станет стандартом.
2. В интерфейсе есть панель для контроля работы персонала, как для ИМ так и для поставщиков, через которую нач.отдела продаж может контролировать своих менеджеров. То есть использовать сервис как CRM. В обычной CRM можно видеть только статусы сделок, но нельзя увидеть активность работы менеджера. То есть как именно он ответил клиенту и как быстро.
Наверное, не поняли Вы:).
Никакой привязки базы к сервису не требуется. Для поставщиков, которые привязку делают, мы другой, платный продукт предлагаем…
В данном случае главное договориться отдельным менеджерам друг с другом, что будут не по аське и мылу общаться, а через сервис.
Ещё как видели, у нас были проекты с Navision. Искали программиста 3 месяца и не нашли).
Я имел ввиду стоимость продукта по отношению к стоимости разработчика:
1С 100 пользователей 380 т.р. — программист 150 т.р. в месяц
Navision 100 пользователей 120 000 евро — программист 300 т.р. в месяц
Запросы потому что интернет-магазин постоянно что то запрашивает у поставщика. Это запрос наличия, запрос на резервирование и вопросы всяческие по товару. Именно эти три типа действий мы объединили в понятие «Запрос».
Автоматическое резервирование возможно только если интернет-магазин имеет доступ к резервам, например через сайт.
Который автоматически ставит заказ на резерв в ERP, например 1С.
Но у большинства поставщиков такой системы нет.
Да, 1с не лучший вариант. На зато не такой дорогой, как например Navision и позволяет модифицировать логику бизнес процессов и документооборот под себя.
А склад остается закрытым, поставщик просто загружает в сервис остатки, вместе ежедневной mail рассылки excel фала. Есть конечно поставщики, которые остатки не предоставляют. Но тогда интернет-магазины с ними не работают.
Ребята, наверняка с Вами скоро партнерку будем делать, но для использования мне лично гораздо важнее интеграция с CRM. Поэтому используем mailchimp — у него к amoCRM плагин — виджет есть…
«А почему не фреймворк?»
Разработчики сайтов обычно привыкают к какойто архитектуре и парадигме CMS системы. Они знают как именно на этой CMS делать сайт. Можно ставить им конкретные задачи и они с ними справляются, а если не справляются можно найти новых.
Разработка на FrameWork более рискованна, т.к. это разработка с нуля. Тут нужен системный архитектор, слаженная команда и определенная методология разработки. При смене архитектора есть высокий риск смены подхода к архитектуре. А это грозит переделке всей системы. У каждого архитектора или разработчика свой стиль. Поэтому нет смысла изобретать велосипед.
«И какой язык программирования выбрали?»
Выбрали PHP, это было 7 лет назад когда делали 1 интернет-магазин. Сейчас их уже более 20. Они все сделаны на одной CMS доработанной под себя + есть дополнительное ПО собственного производства.
«В дата-центре, у себя в серверной? „
У нас кластер из 15 арендованных выделенных серверов. Хостинг находится не в России. Вы все правильно говорите про безопасность + русские хостеры не соблюдают SLA.
В том то и тонкость, что не важно на какой CMS делать сайт для крупного e-commerce проекта. Важна команда, как вы правильно заметили, которая сделает систему под требования заказчика. Поэтому зачем платить за CMS).
Вам пришлось путь автоматизации проходить с нуля, а интегратор автоматизировал 10-ки компаний с подобными проблемами. Поэтому его команда сделает решение быстрее и качественнее + он имеет наработки из прошлых проектов. Если вы сделали решение одной средней FMCG сети, это не значит что у всех остальных все абсолютно также. В крупном e-commece проекте свои правила и к сожалению мало людей с релевантным опытом автоматизации.
А это значит, что настраивать БП в интернет-магазинах мало кто умеет. Поэтому и нет готовых решений.
Написав о своем подходе к решению данной проблемы вы лишь подтверждаете информацию из статьи. Любой интегратор разработает такое решение на 1c, MS NAV, SAP или с нуля. Только это займет в 3 раза меньше времени.
Поскольку российский рынок на несколько лет отстает от тех мест, где проводилось исследование, какие-либо выводы для РФ делать на основе этих данных бессмысленно.
Понятно, что тенденция, понятно, что тренд…
Вопрос, «какими будут облачные технологии?» не совсем понятен… Наверняка, еще более облачными и еще более технологичными :)
Интересная идея, но на мой взгляд будет смысл реализовывать у нас лет через 20 или сейчас в Японии (если уже там нет) Результат скорее будет положительным не из-за функции как таковой, а из-за маркетингового эффекта — какая-нибудь сеть или интернет-магазин внедрит и будет этим грамотно козырять… На практике сложно представить ситуацию, когда виртуальная модель поможет подобрать одежду.
Круче фейсбука точно не получится — это всего-лишь сервис, а ФБ — решает глобальную потребность в общении.
Например:
— контроль времени ответа за запрос — может быть менеджер курил, а не отвечал важному клиенту.
— контроль времени на резервирование товара — возможно ваши менеджеры тратят 30% своего времени на — разбор спорных ситуаций — клиент говорит просил забронировать, а менеджер говорит что не просил. Клиент не доволен.
— При болезни менеджера его контакты не удобно обрабатывать другому менеджеру. В случае с сервисом это очень просто, достаточно открыть 2 аккаунта.
По второму: Приоритеты зависят от политики компании. У одной компании не большой склад, поэтому она пытается обеспечить товарами по больше мелких клиентов, а не отдавать все нескольким крупным. Другие, у которых склад по больше продают в первую очередь крупные заказы.
Единственных нормальным показателем эффективности является оборот менеджера. И только по нему можно оценить качество его работы. Собственнику важнее чтобы увеличивался или был стабильным оборот.
Тем компаниям, на которых ориентирован сервис необходимо хотя бы контролировать чтобы менеджер не забыл ответить клиенту или ответил за 1 час, а не за 8.
У нас упор сделан на 2 вещи:
1. Если сервис окажется удобнее чем стандартная схема, то участникам процесса будет просто приятнее работать и проще. Количество пользователей будет расти и как следствие, это станет стандартом.
2. В интерфейсе есть панель для контроля работы персонала, как для ИМ так и для поставщиков, через которую нач.отдела продаж может контролировать своих менеджеров. То есть использовать сервис как CRM. В обычной CRM можно видеть только статусы сделок, но нельзя увидеть активность работы менеджера. То есть как именно он ответил клиенту и как быстро.
Никакой привязки базы к сервису не требуется. Для поставщиков, которые привязку делают, мы другой, платный продукт предлагаем…
В данном случае главное договориться отдельным менеджерам друг с другом, что будут не по аське и мылу общаться, а через сервис.
Я имел ввиду стоимость продукта по отношению к стоимости разработчика:
1С 100 пользователей 380 т.р. — программист 150 т.р. в месяц
Navision 100 пользователей 120 000 евро — программист 300 т.р. в месяц
Автоматическое резервирование возможно только если интернет-магазин имеет доступ к резервам, например через сайт.
Который автоматически ставит заказ на резерв в ERP, например 1С.
Но у большинства поставщиков такой системы нет.
Разработчики сайтов обычно привыкают к какойто архитектуре и парадигме CMS системы. Они знают как именно на этой CMS делать сайт. Можно ставить им конкретные задачи и они с ними справляются, а если не справляются можно найти новых.
Разработка на FrameWork более рискованна, т.к. это разработка с нуля. Тут нужен системный архитектор, слаженная команда и определенная методология разработки. При смене архитектора есть высокий риск смены подхода к архитектуре. А это грозит переделке всей системы. У каждого архитектора или разработчика свой стиль. Поэтому нет смысла изобретать велосипед.
«И какой язык программирования выбрали?»
Выбрали PHP, это было 7 лет назад когда делали 1 интернет-магазин. Сейчас их уже более 20. Они все сделаны на одной CMS доработанной под себя + есть дополнительное ПО собственного производства.
«В дата-центре, у себя в серверной? „
У нас кластер из 15 арендованных выделенных серверов. Хостинг находится не в России. Вы все правильно говорите про безопасность + русские хостеры не соблюдают SLA.
А это значит, что настраивать БП в интернет-магазинах мало кто умеет. Поэтому и нет готовых решений.
Понятно, что тенденция, понятно, что тренд…
Вопрос, «какими будут облачные технологии?» не совсем понятен… Наверняка, еще более облачными и еще более технологичными :)
Круче фейсбука точно не получится — это всего-лишь сервис, а ФБ — решает глобальную потребность в общении.