Сейчас перед многими компаниями стоит вопрос грамотно настроенной синхронизации 1С с интернет-магазином или b2b порталом организации. И вариантов решения данной задачи достаточно много.
Дмитрий Душков
7 апреля 2013
Сейчас перед многими компаниями стоит вопрос грамотно настроенной синхронизации 1С с интернет-магазином или b2b порталом организации. И вариантов решения данной задачи достаточно много. Обычно для интеграции с веб-системой на стороне 1С используют стандартный обмен с web-сайтом в формате CommerceML. Данное решение является стабильным и проверенным на многих проектах. В данном вопросе мне есть чем поделиться, т.к. не так давно я специально проводил анализ систем интеграции для нужд нашего собственного продукта, поэтому предлагаю вашему вниманию обзор и сравнение формата обмена CommerceML и других способов интеграции:
Обмен с сайтам по формату CommerceML
В типовых конфигурациях 1С:Предприятие существует 2 типа обмена, основанного на формате CommerceML:
Веб-приложение и веб-сайт: разница за 8 минут
- Обмен по схеме Поставщик-Покупатель Обмен по схеме Поставщик-Покупатель можно использовать для обмена с сайтом, если база 1С будет выступать в качестве Поставщика, а сайт в качестве Покупателя. Но обмен по этой схеме возможно использовать лишь в ручном режиме, загрузка и выгрузка производится вручную. Также вручную необходимо обрабатывать загруженные заказы и формировать на них ответы.
- Обмен с web-сайтом 1С-Битрикс Обмен с web-сайтом 1С-Битрикс после настройки выполняется в автоматическом режиме, но заказы необходимо проводить в 1С вручную. Заказ выгружаемый по такой схеме не контролируется на наличие остатка на складе. И при проведении заказа может оказаться, что заказанный товар уже зарезервирован другим заказом.
Больше не нужно искать и обзванивать каждое диджитал-агентство
Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →
web-расширение
В ассортименте программных продуктов 1С есть компонента web-расширение для платформы 1С:Предприятие. Данное решение основано на технологии Web Forms, которая интегрирует веб-форму, элемент управления и источник данных. Для доступа к данным элементы управления используют технологию ADO.NET, а пользовательский интерфейс работает на ASP.NET
Основной недостаток этой технологии — ограниченный дизайн компонентов веб-форм, сайт должен использовать ASP.NET, необходимость дополнительного лицензирования и фактически прямой доступ в базу данных.
Использовать подключаемую DLL
Подключаемых dll для обмена на рынке нет, нужно писать самому. Есть только примеры. Для автоматического обмена по протоколу sftp из встроенного языка можно использовать существующие утилиты вроде WinSCP.exe. Однако, более надежно написать для этих целей внешнюю компоненту. Тем более, что есть готовые библиотеки для С++.
Как подключить скрипт Python к html
Использовать COM интерфейс
Использование COM интерфейса предполагает наличие у сайта com-объекта, к которому можно подключиться
Связь по COM-интерфейсу поддерживается многими приложениями в среде Windows, однако, для обмена с web-сайтом это довольно экзотическое решение. Для реализации такого решения также требуется наличие программиста владеющего технологиями COM.
Использовать web-сервисы 1С
Для web-сервисов необходимо открывать порт со стороны 1С, что представляет потенциальную угрозу проникновения в базу из Интернет.
Наиболее удобно для обмена 1С с сайтом использовать встроенную в платформу 1С:Предприятие технологии web-сервисов. Но использование этого решения отталкивает компании из-за необходимости открывать доступ к 1С из Интернет.
Перейти на 1С 8.3 (Возможно)
В версии 8.3 1С:Предприятие реализована поддержка SSL, сертификатов в web-сервисах и объектах встроенного языка использующих FTP и HTTP-соединение. В данном случае в web-сервисах уже обеспечивается необходимый уровень безопасности доступа к данным. Для данной платформы пока еще не реализованы типовые конфигурации, что ограничивает ее распространение.
Универсальный обмен XML
Универсальный механизм обмена XML гибко настраивается без вмешательства программиста с помощью конфигурации «Конвертация данных». Но не позволяет осуществлять обмен в автоматическом режиме. А также, в данном варианте обмена не отслеживаются изменения объектов. Поэтому приходится выгружать все объекты, даже если они не изменялись. В лучшем случае для документов можно установить интервал выгрузки.
Самописный обмен
1С выгружает файлы формата txt, xml или csv, которые передаются на сайт по протоколам http или ftp. Сайт обрабатывает полученные файлы.
Самописный обмен позволяет достаточно гибко описать все правила и алгоритмы обмена, однако он хорошо работает при обмене небольшими объемами данных, при больших объемах начинаются проблемы с производительностью.
Веб-сервер на стороне 1С
Встроенная в платформу 1С:Предприятие технология web-сервисов позволяет создать конфигурацию с полноценной CMS-системой генерирующей по запросу html-код. Таким образом кардинально решается вопрос обмена с сайтом, его по сути дела нет, так как сайт работает на базе 1С. Данное решение потенциально обладает низкой производительностью производительностью.
Комбинированный
Каждый из описанных выше вариантов имеет свои преимущества и недостатки. Какой из них выбрать в конечном итоге зависит от множества факторов. И в каждом случае решается индивидуально. По нашему опыту наиболее оптимальным является решение, использующее сразу несколько вариантов обмена для разных ситуаций.
По собственному опыту могу сказать, что когда встал выбор какой тип обмена использовать в масштабном проекте по созданию готовой b2b системы с универсальной интеграцией в большинство конфигураций 1С, на основе глубокого анализа нами был выбран формат CommerceML с доработанным функционалом. Именно он сочетает в себе гибкость настройки универсального обмена XML, высокую автоматизацию и повышенную производительность. В итоге в указанной выше системе интернет-дистрибуции мы использовали оптимизированный CommerceML формат для обмена сайта с базами 1С:Предприятие. При этом есть возможность гибкой настройки объектов обмена без программирования, путем добавления объектов в пакет XDTO. Большие объемы данных система передает по протоколу sftp, что заметно повышает отказоустойчивость и гарантирует безопасность.
Таблица сравнения обменов
Сравнение выполнено по следующим параметрам: производительность, отказоустойчивость, безопасность, эргономика.
Преимущества
Есть в стандартной поставке 1С.
Приемлемый уровень безопасности, нет доступа в базу 1С из интернет.
При работе по схеме Поставщик-Покупатель необходимо вручную инициировать обмен.
Избыточность данных протокола снижает производительность.
Данные не зашифрованы.
Большие объемы данных могут вызвать отказ в работе.
Нет стандартных средств автоматического мониторинга процесса обмена.
Прямой доступ в базу 1с позволяет упростить процесс отладки.
Включено в некоторые стандартные поставки.
Под каждого пользователя надо покупать лицензию 1С.
Производительность сильно зависит от скорости доступа к базе 1С.
Прямой доступ в базу, потенциальная угроза доступа к данным в 1с из интернет.
Падение сервера 1С вызовет падение сайта.
Производительность зависит только от объема данных
Приемлемый уровень безопасности , доступа в базу 1С из интернет нет.
Трафик шифруется при обмене по протоколу sftp.
По сравнению с другими вариантами наиболее высокая отказоустойчивость при передаче больших объемов данных.
Трудоёмкое написание библиотеки.
Подойдет только для реализации транспорта данных.
Приемлемый уровень безопасности , доступа в базу 1С из интернет нет.
Производительность сильно зависит от скорости доступа к базе 1С.
Возможны сбои при частых таймаутах.
Трудоёмкое написание COM интерфейса.
Прямой доступ в базу 1с позволяет упростить процесс отладки.
Производительность сильно зависит от скорости доступа к базе 1С
Открыты порты доступа в базу, есть потенциальные угрозы
Возможны сбои при сбоях в базе 1С
Высокая степень безопасности, поддержка протоколов шифрования
Есть средства для повышения уровня отказоустойчивости.
Необходима миграция с текущей платформы 1С.
Универсальный обмен XML
Приемлемый уровень безопасности, доступа в базу 1С из интернет нет.
Инициация обмена по умолчанию осуществляется оператором.
Обработка больших файлов правил сильно снижает производительность.
Данные передаются в открытом виде
При больших объемах данных возможны сбои.
Возможны варианты оптимизации
Безопасность зависит от реализации решения
Долгий процесс отладки обмена
Веб-сервер на стороне 1С
Нет промышленных внедрений.
Решение на уровне прототипа.
Производительность ниже, чем у обычных веб-серверов
Низкий уровень безопасности, открыт порт доступа в базу данных 1С.
Сайт не работает при сбоях с базой 1С.
От редакции
Настоящие эксперты в области веб-разработки делают не только красиво, но и функционально. Хотите найти веб-студию, способную обеспечить не только аккуратный, приятный дизайн, но и последующее удобство при использовании интернет-магазина? Тогда обязательно изучите независимый рейтинг разработчиков интернет-магазинов! Он позволяет получить представление сразу о всех лучших веб-студиях, специализирующихся именно на этом типе сайтов, причем сразу по 4 ценовым категориям.
Владимир Завертайлов
Генеральный директор в Сибирикс
Хороший обзорчик, спасибо )
Вот от меня стандартные вопросы, которые сразу помогают понять, с чем мы имеем дело, прямо на разговоре.
Чтобы понять, какой тип интеграции подходит именно вам, давайте уточним у вашего технического специалиста ряд вопросов:
- Была ли изменена конфигурация 1С? Есть ли у вас программист, который вносит в нее доработки?
- Каталог в вашей 1С и на сайте будет 1:1 такой же, или есть отличая по структуре, номенклатуре или карточкам товаров?
- Характеристики товаров в 1С у вас хранятся в описании или внесены характеристиками? Нужен ли на сайте фильтр по характеристикам?
- Какие сущности должны передаваться с сайта (заказы, контрагенты, счета, товары и т.п.) и на сайт (обновление статусов, заявки, заказ-наряд, счета, остатки. ). Какие поля должны быть у каждой из сущностей?
Дмитрий Афанасьев
Руководитель в Диафан
Действительно, вопрос интеграции сайта и 1С перед веб-разработчиками встает все чаще, об этом я могу судить по количеству обращений к нам в веб-студию в последнее время.
Однако на практике мечты клиента об идеальной грамотной синхронизации сайта с 1С разбиваются о достаточно узкую квалификацию специалистов по разработке веб-сайтов, но гораздо ранее о прайс разработчика.
Поэтому варианты «Разработать подключаемую DLL» или «Использовать COM интерфейс» можно рассматривать так же, как транспортным компаниям говорить о возможности телепортации груза, вместо традиционной перевозки.
Обмен информацией по XML, CSV и прочие «ручные» варианты заказчиками, как правило, не рассматриваются в пользу автоматических обменов.
Обмен с сайтом по формату CommerceML действительно является самым популярным. Однако справедливости ради надо сказать, что обмен по этому формату возможен не только с сайтом, разработанным на 1С-Битрикс, но и еще как минимум на пяти платформах, которые указаны на странице http://v8.1c.ru/edi/edi_app/130/ как совместимые.
Чаще всего заказчики выбирают и, я уверен, в дальнейшем будут выбирать уже готовые решения (полу)автоматической интеграции на базе CommerceML. И по сути, этот выбор будет происходить на этапе выбора платформы для создания сайта (CMS), имеющей синхронизацию с 1С.
Захар Наханов
Технический директор в AREALIDEA
Несмотря на обилие методов синхронизации между 1С и сайтом перечисленных в статье, на практике в 99% случаев встречается два основных способа обмена данными.
Первый — стандартный обмен из коробки CommerceML, поставляется со многими системами управления сайтами. Способ подходит для тех клиентов, чью бизнес-логику 1С и сайта можно вписать в этот формат. Он является наиболее идеальным вариантом, так как на текущий момент стандарт хорошо проработан и его внедрение не требует существенных затрат, а настройкой может заниматься не специалист.
Второй вариант — разработка своего формата обмена между 1С и интернет-проектом. Им может быть формат XML или CSV.
В зависимости от задачи применяются различные решения для оптимизации обмена:
- основные данные грузятся сразу и только один раз, а в дальнейшем приходят только измененные,
- выгрузка данных через небольшие интервалы времени (в этом случае они не успевают накопиться в большом объеме),
- логирование и e-mail уведомления в случае сбоев или ошибок выгрузок.
Разработчикам следует помнить, что обмен лучше проводить по зашифрованному каналу, а также о том, что 1С-Битрикс постоянно дорабатывает процедуру выгрузок и необходимо следить за текущими обновлениями, так как то, что полгода назад можно было сделать лишь с помощью кастомизированной выгрузки, сегодня уже может быть доступно в стандартном решении.
Азат Низамеев
Технический директор в Reaspekt
Раньше обмен данных с 1С был для нас одной из самых сложных задач. Мы пробовали несколько вариантов:
- Обмен с сайтами по формату CommerceML,
- Универсальный обмен XML,
- Самописный обмен.
И в результате, многим клиентам приходилось отказывать. Сейчас используем функционал 1С-Битрикс (по формату CommerceML).
Практически все задачи им покрываются. До недавних пор существенной проблемой было состыковать структуру базы 1С и web-сайта.
К счастью, разработчики 1С-Битрикс дорабатывают расширения для 1С, и теперь появилась возможность прямо в 1С настраивать выгружаемые разделы.
Ищете исполнителя для реализации проекта?
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Источник: cmsmagazine.ru
Взаимодействие Android с сайтом.
Нужно написать сайт и приложение Android на диплом. Скажите, с помощью чего взаимодействует приложение с сайтом? Лучше и сайт и приложение писать с помошью SQLite? Или можно сайт с помощью MySQL? Буду рада ссылкам.
Спасибо.
Отслеживать
задан 10 фев 2012 в 12:39
Наташенька Наташенька
571 1 1 золотой знак 11 11 серебряных знаков 30 30 бронзовых знаков
Нужно написать сайт типо интернет-магазина, и следовательно приложение на эту же тему.
10 фев 2012 в 13:03
чтобы в приложении можно было выбирать товар, просматривать его характеристики, просматривать корзину, отправлять заказ на сервер. Я пока не совсем в этом всём разбираюсь, по-этому мне необходима помощь, в виде информации.
10 фев 2012 в 13:14
10 фев 2012 в 13:17
10 фев 2012 в 13:51
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
Не важно какую БД вы будете использовать на сайте. Т.к. интерпретатор, будь то PHP или любой другой, все равно будет той «прослойкой» между данными и вашим телефоном. Поэтому вполне логично воспользоваться PHP + MySQL для сайта, так как информации по этим двум понятиям очень и очень много, легко разобраться, легко о них написать в дипломе. Так же легко можно написать простенький сайтик с теми же возможностями, как у приложения, а, может, и больше.
Для Андроида, вам понадобится ряд классов (например такой), которые позволяют делать GET и POST запросы, а так же принимать от них данные. Данные в свою очередь вы будете выдавать (с помощью PHP) в удобном для вас виде (JSON, XML, CSV), главное чтобы телефон умел правильно их интерпретировать (т.е. иметь соответствующий парсер), а скрипт формировать.
Для получения данных, вы можете использовать обычный GET запрос, который будет обрабатываться специальным для этого скриптом, например, запрос может выглядеть так:
/androidapprequest.php?func=getprodinfoformat=json
Т.е. ваш скрипт androidapprequest.php выдаст вам информацию о продукте с индексом 755, в формате JSON. Аналогично вы можете придумывать функции, и обрабатывать их на стороне сервера, выдавая только запрошенные данные.
Таким же образом вы затем сможете расширить функционал, добавив функции не только чтения, но и добавления данных.
Источник: ru.stackoverflow.com
Как запустить проект с сайтом и приложением
Денис Гордиенко, руководитель Bright Mobile, о проблемах, которые ждут руководителя бизнеса, когда идёт комплексная разработка ИТ-продукта, состоящего из сайта, приложения и интеграций со сторонними API.
2240 просмотров
Ozon, YouDo, Avito. Мы уже привыкли к тому, что у крупных сервисов есть и сайт, и приложение. Причём, сделанное практически полнофункционально: что есть на сайте, то дублируется и в приложение. Во второй половине 2019 года, вижу и в заказной разработке подобный тренд.
Основатели все чаще приходят не только за приложением, а за целой системой: чтобы был сайт, приложение, и всем этим можно было управлять из единой панели (в одном из сервисов предполагалось аж 4 роли админа). Сегодня и пойдёт речь о нюансах в разработке таких проектов.
Но как показывает практика, для первой версии делать единый функционал и в вебе и в приложениях — это слишком затратно. Внутреннее API и сайт будут стоить примерно в два раза дороже приложения. Сомнительная выгода при двукратном увеличении чека.
Ранее мы запускали проекты на webview-движке Сервис ПИ (модуль к 1С-Битрикс). Там говорить о полном функционале было легко — по факту менялся только адаптивный шаблон. В начале этого года перевели разработку на Ionic.Framework, а ядро переписали с нуля, получив RTPlatform. Хоть движок стал работать быстрее/круче/веселее, но фишка с функционалом сразу и на сайте, и в приложении пропала — нужно как минимум делать отдельный шаблон, а как максимум переделывать экран с нуля, оставляя только API.
Появилась глобальная задача оставить на сайте самое важное для пользователя и проекта, когда человек находится стационарно, а в приложение вынести функции, необходимые в момент времени, к которым нужно иметь доступ оперативно.
Опросив 10 основателей, за месяц понял, что некоторые вещи, конечно, зависят от специфики бизнеса, но 80% — это общие правила для всех.
Что важно на сайте
Внешний вид
Пользователям важно, чтоб сайт был красивым. В отличие от приложений, где размер экрана не оставляет места для искушённых иллюстраций, а для пользователя на первом месте удобство и скорость, у сайтов вёрстка в стиле «голый бутстрап» редко адекватно воспринимается. При этом, в приложениях, «голый ionic» не нравится 20%, нормально воспринимается 70%, ещё 10% от него в восторге. Как говорится, невероятно, но факт. В итоге, основателю приходится заказывать индивидуальный дизайн для сайта, а в бюджетных вариантах купить шаблон и потратиться на его адаптацию.
SEO — это главное преимущество сайтов перед приложениями, поэтому, принебрегать его использованием не стоит. SEO продвижение на порядок дешевле, чем контекстная и прочая cpp реклама, где нужно платить за клики, показы, переходы. Для этого применяются разделы Новостей, Блога или Статей.
Круто будет применить UGC для снятия барьера между пользователем и сервисом. В случае маркетплейса услуг, например, это контент от самих специалистов, которые оказывают услуги.
Этот раздел у меня под вопросом, потому что сильно зависит от специфики проекта. Если пользователь что-то покупает или заказывает на сайте и ему нужно отслеживать заказ, иметь возможность написать исполнителю и т.п., то раздел нужен. Если это не принципиально, то нет. Наглядный пример — такси. Вы заказываете мотор с приложения или с сайта?
У Яндекса, например, есть и то, и другое, а запуская новый агрегатор делать заказ с сайта было бы излишней тратой денег.
В некоторых случаях можно ограничится лендингом с формой захвата, чтобы пользователь мог просто оставить заявку, а она по API улетела в приложение мастеру или в админку оператору на проверку.
Что важно в приложении
В приложении важна оперативность передачи или получения данных. Для сравнения, у вебщиков загрузка страницы в 5 сек считается нормой, а для крупных проектов даже хорошим результатом, а для мобильщиков, если экран грузится больше 2-х сек, то уже зашквар. С учётом того, что единый функционал в приложении стоит дороже сайта, то приложение используется в проектах, где нужно оперативно выцеплять пользователя (push) или точно работать с его локацией (gps).
Если говорить про маркетплейсы услуг, то чаще приложениями пользуются исполнители, а не заказчики. Исполнителям нужно видеть новые заявки как можно быстрее, с момента появления — от этого зависит заработают они или нет.
Как технически реализовывать “отклик” — это другой вопрос. Это может быть мессенджер, возможность оставить свое предложение под заявкой на бирже заданий, можно реализовать по принципу “ кто первый отклинулся — того и заявка” или сделать автоматическое назначение заявки исполнителю, как это делают в такси.
Актуально, примерно в 70% случаях. Если основная идея продукта в том, чтобы найти или трекать ближайшего кого-то или что-то, то это всё выносится в приложение. На вскидку, в этом году запускали вот такие идеи, где GPS был, как кровь из носу:
- Кешбек-сервис с поиском ближайшего заведения
- Биржа предложений от поваров, с отметками, где они находится
- Сервис поиска пропавших родственников
- Сервис аренды недвижимости
- Сервис поиска парковочного места
Маркетплейс, как автоматизация процессов и масштабирование бизнеса
Возможно, в начале статьи стоило оговориться, что я специализируюсь на разработке маркетплейсов, но хотелось, чтобы статья была полезна максимальному количеству людей. Тем не менее, пример приведу всё-таки из своей основной области. Не во всех маркетплейсах заявки от заказчиков напрямую попадают исполнителям, от покупателей — продавцам. Во многих случаях есть еще менеджерское звено. Вот тут рассказывал подноготную одного раскрученного стартапа с такой идеей:
Заказчики оставляют заявки, администратор перезванивает, уточняет детали. Исполнители уже получают подготовленную заявку, где отражена вся необходимая для них информация.
Часто ко мне обращаются с идеей создания маркетплейса не с нуля. У человека уже есть оффлайн бизнес, есть сайт на котором оставляют заявки, менеджеры, обрабатывающие входящий трафик, и сами исполнители (мастера в той или иной отрасли, которые фактически выполняют задание). При этом, исполнители могут быть как штатные, так и на сдельщине.
Владельцу бизнеса хочется автоматизировать процесс назначения заявки, чтобы можно было масштабироваться на другие города и работать с удаленными сотрудниками.
Запускать и сайт, и приложение, для пользователей и исполнителей — дорого. А, если есть работающий сайт, то бессмысленно, с точки зрения продвижения. Зачем тратиться на новый сайт, когда уже есть трафик на старом?
В таких случаях я рекомендую делать следующее.
Доработка сайта. На сайте добавляется виджет для сбора заявок, вместо обычной формы обратной связи. Она отправляет заявку не в админку или почту, а в CRM или админку управления заказами.
Панель администратора. Админка здесь разделяется на два ключевых звена. Первое — это админка сайта, которая остаётся для управления контентом и SEO. Вторая — это админка управления заявками, которая реализуется через CRM (если много взаимосвязанных сущностей), либо в простеньком веб-интерфейсе, напрямую подключённому к API приложения. Второй вариант, само собой, существенно дешевле.
Приложение. Приложение в минимальной версии нужно только мастерам. Там они настраивают профиль, получают заявки по своей специализации и отчитываются за выполнение. Получается такой мини-планадо, только в своей отрасли.
В итоге, выходит такая схема. Клиент находит сайт в поисковике, оставляет заявку. Диспетчер перезванивает, узнает необходимые данные и уточняет заявку. После уточнения, она попадает в приложение для исполнителей, а исполнители бронируют за собой и выполняют.
Вроде бы выходит логика работы стандартного маркетплейса с промежуточным звеном, но за счёт готового сайта получается существенная экономия:
- Сама разработка сайта, в среднем 200-300 тыс
- SEO продвижение за 3-4 месяца. Тут всё сильно от сферы зависит, оценю по минимуму в 100 тыс
- Экономия времени 3-4 месяца — вы уже получаете эти заявки.
Очевидно, что сайт тоже придётся со временем модернизировать, если будет масштабирование по регионам или даже странам. Но для старта, текущего корп.сайта будет вполне достаточно.
25 комментариев
Написать комментарий.
Открыл статью , где в названии написано как запустить сайт+ мобильные приложения!
Итог: статья о каком то типе, который описал как он тратил деньги на свой проект — не нужно не кому в 21 веке — слушать такую чушь , и Читать у эх точно
Развернуть ветку
Просто Денис ввёл всех заинтересованных читателей в заблуждение своим заголовком статьи «Как запустить проект с сайтом и приложением», а в результате просто пропиарил свой проект, хороший маркетинговый ход, а может случайность, сбился с мысли и рассказал о своих услугах.
А по факту (если изменить заголовок), то статья правильная.
Развернуть ветку
Денис ввёл всех заинтересованных читателей в заблуждение не только своим заголовком статьи «Как запустить проект с сайтом и приложением», а всем материалом! Уверен, что статья — это его мысли «вслух», чтобы проверить свою гипотезу: «Зайдет или не зайдет» — предлагать своим потенциальным клиентам «снабжать» свои сайты-лендинги мобильным приложением.
Мобильное приложение предлагается использовать в качестве альтернативы e-mail уведомлениям (только через мобильные PUSH-уведомления) «о поступлении заявки на сайт».
Я уверен, что «не зайдет»! Просто, под такое «придуманное» решение нет целевой аудитории. Все те, кто обрабатывают по 300+ заявок в день, уже давно используют специализированные десктопные CRM системы в которые «сваливаются» все обращения клиентов с сайтов и распределяются между менеджерами/складами/партнерами (у них «ярко моргают лампочки» и даже «вибрируют стулья» при каждой новой заявке :))). А для 10-30 заявок в день, достаточно настроить проверку почты в смартфоне и получать «мобильные PUSH-уведомления» о поступлении новой почты бесплатно.
А для «эстетов», кому нужно «жить и работать в телефоне», есть облачные CRM-системы для сайта, в которых уже реализован функционал учета и обработки заявок с сайта с получением уведомлений в мобильное приложение и даже прием звонков с сайта в мобильное приложение.
Например, я использую облачную CRM-систему для сайта — Slon.biz
Источник: vc.ru