.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

CRM для e-commerce — какой функционал запихнуть и с чем интегрировать?

Смешались в кучу кони, люди©

Пилим потихоньку облачные сервисы, в том числе, и для интернет-магазинов, постоянно сталкиваемся с непониманием заказчиком собственно термина «CRM» и, соответственно, присущего ему функционала. Все вкладывают в определение именно свои хотелки — от тупо карточки клиента c контактами и вплоть до комплексного настраимого обязательно бесплатного ERP-решения.

Вопрос: что, по вашему мнению, должно входить в базовый функционал продукта, чтобы его можно было смело обозвать CRM?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дайте пожалуйста предварительно ссылку на ваш продукт.
Я очень заинтересован в вашем продукте.
Нужна ERP система для работы с поставщиками (дропшиппинг), а также функционал B2C, CRM для информации с лендингом (большим количеством).
А также интеграция с КЦ (Call Centr).

Пока в публичном релизе только модули бухучета типа bookkeeper.kiev.ua и B2B интернет-магазины (с BPM/CRM под капотом) типа https://megawatt.store/ . Остальное — кастомные внедрения.
Продукты B2C пока, как раз, проектируются/разработываются

Prom.ua, это убожество, видел? А долю рынка видел? Вот и вся суть

Добрый день.

Первое — сделайте человеческий профиль клиента (на уровне модели данных). С инструментами дедубликации и нормализации.
Второе — разделите опять же на уровне модели данных реальных клиентов (синхронизируйте с контрагентами из учетной системы с правильной «первичностью» данных) и потенциальных клиентов, которых ошибочно у нас называют Лидами, Олями...
Третье — реализуйте дружбу с сайтом (SOA) и телефонией (сделайте более-менее универсальный CTI — коннектор), автоматизируйте процесс приема и обработки входящих коммуникаций и работы с заявкой или сервисным обращением.
Смело назовите CRM (всё равно определения этим трем буквам нет в природе).
Далее, раз Вы хотите расширить портфель модульных облачных решений, сделайте отдельный движок работы с коммерческими предложениями и заказами. В него смело тяните все продукты из учетной системы и правила ценообразования на них (цена — не атрибут продукта). Далее, реализуйте возможность настраивать коммерческие продукты — а именно всякого рода комбинации продуктов, конфигуратор их свойств и самое главное — правила подходимости и совместимости. Далее, упакуйте полученные домены продуктов или продуктовых предложений в портфельные предложения, которые учитывают профиль клиента, который собирается их купить. Если всё сделать правильно — этот модуль смело называйте омниканальным движком управления заказами и дружите уже его с каналами продаж (сайт, чат-бот, моб приложение, проч). Его же и встроите в ранее описанную CRM. Таким образом, получите два крутых продукта — кому-то нужно доводить клиента до состояния покупки (тогда это CRM), кому-то — быстро обрабатывать то, что положили в «корзину» на сайте (тогда — второй продукт). А кому-то и то и другое.

Как идеологически почти полностью согласен....но с точки зрения бизнеса — спустя годы реализации этого (допустим без проблем), что рынок начнет потреблять это? И конкуренты раздвинут долю и освободят место? Кому нужен еще один CRM? Плюс за эти «годы» конкуренты внедрят AI в свои продукты и дадут клиентам что-то другое чем просто «БД + конфигуратор».
Я конечно в бизнесе НОЛЬ — но или развивать сильные специализированные нишевые решения для отраслей где нет конкурентов или мало, ну или просто делать упор на качественном и успешном внедрении (продавать услугу), ну или действительно что-то новое (вот у меня на этой странице сейчас висит баннер people.ai)....

Все правильно. Но большая проблема искусственного интеллекта сейчас — это большие данные. А проблема больших данных — отсутствие больших данных)))). Они есть у всяких монстров и наверное телекомов. Именно поэтому и предложил подход, который на мой взгляд позволит влиться в бизнес интернет магазинов, далее, раз это облако, накопить данных, а потом их беспощадно анализировать. Но анализировать и выявлять шаблоны поведения именно в процессах работы с заявками и обращениями, а не в привлечении клиентов или их РФМ — сегментировании. Это как раз уже есть и хорошо работает в мире. Пример — emarsys.com. Но они как раз набрали именно данных для привлечения и удержания клиентов, но не для описанных мной процессов. А на рынке электронной коммерции сейчас действительно не хватает продуктов, учитывающих их специфику в продажах и обслуживании. Тем более, в формировании продуктовых предложений. А по поводу трёх букв — да назовите как угодно. И это действительно ниша — ну не купят наши интернет-магазины крутую зарубежную систему и не потратят пятизначную сумму в долларах.

Не для этого форума вопрос ИМХО....да и вообще есть конечно каноны, но ничто не мешает вам сказать что у вас есть CRM и вы видете ее функциональность такой то такой.
Ну или взять 3-4 лидеров рынка, проанализировать функциональность, разбить на элементы и составить матрицу покрытия (проставить какие то галочки или оценки). В получившейся массе — те елементы что есть у всех — и будут «что, по вашему мнению, должно входить в базовый функционал продукта, чтобы его можно было смело обозвать CRM?».
Потом из этого вы же не сможете все сразу запилить? :) Придется начинатть с самого критичного.
Так — не думая особо- это: Клиенты, Контакты, Сотрудники, Лиды, Сделки/Заказы/Продажи, Проекты, Таски, Календарь, Интеграция с телефонией/почтой/прочими каналами, Аналитика/отчеты/дашборды, Проекты/Портфели.....
ИМХО конечно

Ну или взять 3-4 лидеров рынка, проанализировать функциональность, разбить на элементы и составить матрицу покрытия (проставить какие то галочки или оценки)

Именно так и делаем, но дополнительно рубим все, не особо применимое к группе кейсов, под которые пилится софт («чистый» интернет-магазин)

Интеграция с телефонией/почтой/прочими каналами

 — это, скорее, HelpDesk-модуль

Аналитика и тыды будет по умолчанию в ЛК клиента, в зависимости от подключенных модулей. .

Логать все активитеты, т.е. точки соприкосновения с клиентами через различные каналы, это как бы core CRM.

Да, облачная телефония, мессенджеры, почты и т.д. — обязательно

Ну может не все сразу, но обычно под СРМ подразумевают 3 процесса, помимо самой датабазы клиентов и активитетов: маркетиг аутомейшн(высылка всяких компаний, автоматизация, лидскоринг и тд.), сейлс аутомейшн(процесс продаж и тд., далее фишки типа кросс сейлс, апсайлс, некст бест акшн и тд) и сервис(ну собственно кастомер сервис, кейс менеджмент и так далее). Где вам стоить начинать вам виднее, просто потенциально — это огромный скоуп, но именно для вашего случая может быть не все это актуально. У лидеров рынка типа Сейлсфорс или Майкрософт сейчас меньше фокуса на понятие СРМ, они стремятся продавать платформу к которой можно быстро и гибко подкрутить/реализовать любой процесс.

Знаю человека, который запилил 2 CRM. Одну для очень крупного предприятия вторую для FinTech. Могу познакомить для общения. Во 2 случае были интересные решения.

Ну мы тоже достаточно мощные CRM/BPM пилим и внедряем, сейчас, наоборот, нужно «массовое», усредненное решение именно для интернет-магазинов, под интеграцию с другими нашими SaaSами. Вопрос в том, какой именно функционал туда впихивать по дефолту.

Во 2 случае были интересные решения

Потырить интересные решения — мы всегда только за ))))

Не с претензией или издевкой...но раз вы пилите много и мощно — то вы должны всем рассказать что туда впихивать, а не расспрашивать у Java — разработчиков.
Даже если тут люди что то и скажут, какова ценность этих мнений и советов?
Выглядит примерно, как завод по производству электроники всякой, на форуме инженеров микроэлектроники — выясняет какие функции должны быть у смартфона что бы порвать какой-то рынок...эта информация — ИМХО это исследование + удача/интуиция и так просто нельзя ее где-то взять или опросить 10ток людей.

Не с претензией или издевкой...но раз вы пилите много и мощно — то вы должны всем рассказать что туда впихивать, а не расспрашивать у Java — разработчиков.

А почему вы решили, что тут только разработчики? На Доу масса BA и внедренцев с плотным фидбэком от клиентов.

Напишите мне в Телеграмм (@VadymGavrylov) помогу с коммуникацией

CRM отдельно от программы для управленческого учета — не имеет смысла. Хотя нынче модно.

Тогда следующий вопрос — что ты понимаешь под «программой управленческого учета» и какой минимальный функционал она должна включать?)))
Вот я проектирую модуль с кодовым наименованием «CRM», еще будет складской, подключаемый б/у и тыды, какой иненно минимальный функционал должен быть именно в условном модуле «CRM»?

Ок. Мое понимание терминологии. Есть две разные группы потребностей :
1.Учет (понимать чего у нас как)
2. Оптимизация процесса (делать быстрее, с меньшим количеством ошибок и с большим кайфом).

Учет полноценен, когда он основан на управленческом плане счетов, есть P&L, Balance, Cash flow, анализ затрат, дебиторки, кредиторки и прочее. Это может называться более простыми словами чтобы директор не пугался, но суть остается.

Теперь про CRM. Одно из самых перегруженных понятий. Каждый под ним понимает что-то свое : для кого-то это система постановки задач сотрудникам (sic да, именно сотрудникам, причем тут клиенты сам не знаю). Для кого-то система рассылки емейлов по тригеру, для кого-то чат в одном окне для общения с клиентами. Что общее для всех интернет-магазинов — это должна быть система которая консолидирует заказы из разных источников, и позволяет удобно понимать в каком они состоянии. Я бы это назвал не «CRM» а «оптимизацией процессов».

И теперь самое основное — без данных управленческой системы не получится нормально их оптимизировать. Разрекламированные битриксами синхронизации не помогают от слова вообще. Только в очень простых бизнесах. В момент обработки заказа нам нужно понимать сколько товара на складах, зарезервирован ли он, если зарезервирован, то на кого (может быть можно договориться с другим менеджером чтобы он подождал), ожидаем ли мы его от поставщика, есть ли он в прайсах поставщиков. Потом идет заказ поставщику, перемещение на точку магазина, с резервом под этот заказ, возврат и так. далее.

Управленческий учёт это такое же мутное понятие как и CRM. То что вы перечислили это просто складской учет

P&L, Balance, Cash flow, анализ затрат, дебиторки, кредиторки — складской учет?

Кэшфлоу, P&L, дебиторку и кредиторку для интернет-магазина наши фокус-группы не особо просят

Да. Пока мелкие. Правда 90% так и остаются мелкими все время.

Да. Пока мелкие. Правда 90% так и остаются мелкими все время.

Станут немелкими — за отдельные деньги будет им отдельная недешевая жирная коробочка )))
Пока речь о дешевом массовом SaaS

Они о них просто не знают. ))
Не знают, потому что, в том числе, не ощущают необходимость. В том числе, так как «работают на ощупь», частенько. («предприниматели начинают деятельность невзирая на отсутствие полного спектра требуемых знаний и профессиональной подготовки, в условиях дефицита ресурсов и времени»)

Ну, скажем так, вот те «взрослые» штуки им не очень то и нужны. Они в большей мере предназначены для «упаковки» (сжатия) информации о состоянии бизнеса для людей уровня «акционер», «собственник», «инвестор». Это уровень «стратегического планирования бизнеса». И слабо подходит для «операционного управления» (с оговорками).

Я в принципе темой бизнес софта и бизнес управления давно интересуюсь, и успел сформировать некоторый вижн. В частности относительно потребностей «начинающего» бизнеса (мсб) и того, чем эти потребности закрывать.

Имхо, но первейшую роль играют знания, методологическая информация о практиках ведения тех или иных видов бизнес активностей (бест практис). Инструменты идут вторым номером.

Лучше всего подходят практики основанные на Теории ограничений (учет прохода, метод критической цепи), далее идеи Деминга (теория вариабельности, цикл деминга, управление качеством, Функция потерь качества по Тагути) и россыпь всякого имеющего в названии «гибкие» или «адаптивные».

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

Я в принципе темой бизнес софта и бизнес управления давно интересуюсь,

интересоватся мало нужен опяти практической реалищзации

Лучше всего подходят практики основанные на Теории ограничений (учет прохода, метод критической цепи)

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

интересоватся мало нужен опяти практической реалищзации

ну естественно я без опыта ))) как вы могли подумать, что у меня есть какой либо опыт в этой сфере, тем более релевантный )

ну вы ж сами написали «я интересовался» а не «я разработал и внедрил кучу проектов»

ну да, ведь существует одна единственная форма определения.

Ну и многие учетные задачи решит наш основной продукт (он будет подключаемым модулем на одной БД с магазином)

Вот да, мы соответствующий модуль пилим именно под временным названием «складской учет/логистика»

больше по факту ничего и не нужно. я в свою складскую прогу просто добавил элементы CRM : типа коментарии и возможность прикреплять файлы к карточкам контрагента плюс простая напоминалка типа будильника (ну там перезвонить такого то числа) и этого в большинстве случаев достаточно.

Уффф
Все бы были такими нетребовательными, как вы )

если у вас есть конкретные требования то тогда не должно быть вопросов что писать. а если нет то не надо пытатся обьять необьятное.
Я пишу минимум который точно знаю по опыту. далее клиенты начинают скачивать смотреть пробовать внедрять. получаю фидбеки и смотрю что требуется людям реально работающим в бизнесе. спрашивать как вы других програмистов что нужно — бессмысленно — нужно спрашивать тех кто пользуется.

Проблема в том, что требования мы сами должны угадать, исходя из возможных хотелок ЦА )))

спрашивать как вы других програмистов что нужно — бессмысленно

 — не согласен, тут много опытнейших разработчиков-внедренцев со знанием хотелок клиентов и огромным портфелем кейсов.

Проблема в том, что требования мы сами должны угадать, исходя из возможных хотелок ЦА

проблема в том что вы пытаетесь угадывать вместо узнать мнение этой самой ЦА

тут много опытнейших разработчиков

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

Ключевое слово — внедренец )))

проблема в том что вы пытаетесь угадывать вместо узнать мнение этой самой ЦА

Не, расширяю фокус-группу ))

лично моя фокус-группа те кому я внедряю — они эе и тестеры (проект опенсорс — тестировать некому). Вы рискуете наслушавшись умников переусложнить проект мало кому нужными фишками. а это неоправжано усложнит работу как вам так и клиенту — пример тому 1С, превратившая с восьмой версии в монстра — но у них монополия на рынке а вам надо только пробится.

Подписаться на комментарии