Настраиваем виджет «Нужна помощь?».
Задача простейшая: расположить на нем кнопку вызова чата с оператором.
Проблема: невозможно подвесить на эту кнопку onclick.
Или я плохо смотрел? Буду благодарен за пинок в нужном направлении.
Смотрели хорошо, действительно beta-версия виджетов этого не умеет. Но функция интересная и, безусловно, нужная. Записали это в roadmap :)
Мне кажется, отсылка более одного — в рамках одной рассылки — письма одному и тому же емейлу есть однозначный и безусловный косяк. Юзер не виноват, что кто-то где-то считает Карла Маркса и Фридриха Энгельса четырьмя разными людьми :) и скорее всего не хочет получать даже одно письмо, а тут на его голову сваливается вот такое счастье.
Вы правы, один и тот же емейл не должен получать несколько одинаковых писем, это мы решим в ближайшее время.
Предполагаю, мы столкнулись именно с этим случаем и Convead решил, что visitor_id «главнее» email. И как мне кажется такие случаи (а их будет много, т.к. многие движки имеют подобный механизм) нужно абсолютно четко отсекать.
Если в случае с рассылками все достаточно однозначно, то вот здесь мы пока не пришли к единому мнению. Дело в том, что ряд сайтов (в т.ч. среди наших клиентов) по каким-то причинам используют фейковые емейлы, которые вполне могут быть и не уникальными. Мы долго думали, стоит ли рассматривать такие граничные случаи, но сейчас уже наверное склоняемся к тому, что не стоит, и что действительно визиторов нужно «склеивать» по емейлу, т.к. в подавляющем большинстве случаев это будет правильным. Сделаем это в ближайшее время, спасибо за фидбек!
Посмотрел, ваша рассылка ушла не 26 раз одному человеку, а 26 разным людям с одинаковым емейлом (это видно, если посмотреть на id-шники визиторов). Видимо, когда вы тестировали, вы как-то передали 26 раз один и тот же емейл для разных визиторов. Convead специально не склеивает визиторов по емейлу, потому что это не всегда правильно. А вот что делать с одинаковыми емейлами у разных юзеров в рассылках мы пока думаем (в т.ч. поэтому рассылки еще в beta). Ну, видимо, исходя из вашего фидбека, надо все-таки склеивать их при отправке :)
значит «Ключевые стр» рекомендуете убить, дабы не вводили в заблуждение?
Все не обязательно, но «Product» при нормально работающих эвентах точно не нужна, т.к. они фактически дублируют друг друга. К слову, завтра мы планируем релиз, где просто уберем понятие «тип» у ключевых страниц, чтобы они больше никого не смущали.
Кстати виджет не обидится, если я его defer?
Не тестировали, если честно. Но я бы не рекомендовал этого делать по тем же причинам, по которой GA и Метрика рекомендуют вставлять свои скрипты именно в head: так меньше вероятность того, что что-то не сработает из-за ошибок на странице или если пользователь быстро закроет вкладку. Ну и сам код асинхронный и не должен что-то сильно тормозить (это стандартная отмазка GA и Метрики :)).
Директ добавляет ?yclid= ко всем объявлениям, если в установках кампании это разрешено. Можно отловить заход оттуда по наличию этого агрумента. Как добавить кастомный агрумент в настройках Директа не нашел — возможно нужно отредактировать ВСЕ ссылки…
Огромное спасибо за наводку, вот про yclid-то мы и забыли! В завтрашнем релизе это тоже учтем (тогда не нужно добавлять ничего руками в ссылки).
Дальнейшее обсуждение предлагаю перенести в приват, т.к. оно уже становится слишком частным. Спасибо!
Посмотрел ваш магазин и аккаунт изнутри. Тут имеет место ряд проблем:
Вот сейчас пробежался по «отказным» — они все посмотрели как минимум один товар.
На самом деле эвент «Просмотр товара» ваш магазин не присылает. В инструкции по настройке написано, что он должен вызываться после основного кода Convead, а он у вас стоит на странице выше кода. В консоли JS есть ошибка об этом: «ReferenceError: convead is not defined».
Кстати, вообще обратите внимание на ошибки JS на странице товара, там у вас есть синтаксическая ошибка выше по коду в var displayPrice = ; — из-за нее потенциально тоже могут быть разные проблемы.
Если ставить код эвента 'view_product' после основного кода неудобно — просто заверните его в DOM.ready():
Здесь есть определенная терминологическая проблема. Вы настроили ключевую страницу «Product», но Convead не считает это просмотром товара, т.к. для него «просмотр товара» — это именно эвент «view_product», про который я написал выше. Звучит довольно бредово, согласен, но здесь проблема в том, что мы находимся в стадии активного развития, проверяем различные гипотезы и часто изменяем поведение системы и в результате можем просто забыть о чем-то важном или считать это само собой разумеющимся.
Так, изначально мы придерживались идеи настройки системы без необходимости добавлять какие-либо куски JS на сайт, кроме основного кода. Мы думали, что достаточно проассоциировать какую-либо страницу на сайте с тем или иным этапом воронки продаж и все заработает. Так появился механизм «Ключевых страниц» и их типы («Product», «Cart», «Purchase» и т.п.). Идея была в том, чтобы просто настроить паттерны для этих ключевых страниц и ваши посетители будут распределяться по воронке. Однако со временем мы поняли, что не все так просто… У кого-то роуты сайта постоены на использовании GET-параметров, у кого-то — нет. У кого-то нет отдельной страницы чекаута или совершения заказа и т.д. Все это конечно можно было бы решить через настройку аккаунта, но когда мы прикинули, сколько галочек и полей нужно будет заполнить пользователю, то отказались от этой идеи и перешли от системы ключевых страниц к системе эвентов. Эвенты, кроме всего прочего, открыли также возможность учитывать такие важные для интернет-магазина события, как «положил товар в корзину» и некоторые другие. В настоящее время мы поддерживаем около десятка различных эвентов, в т.ч. и кастомные, которые удобно ставить на всякие кнопочки на сайте и затем сегментировать своих пользователей по этим эвентам.
А ключевые страницы мы решили оставить, поскольку бывает необходимость в том, чтобы отслеживать посещение именно определенной страницы. Кроме того, только посещения ключевых страниц сохраняются навсегда в таймлайне посетителя. Вот что действительно следовало бы сделать, так это убрать типы ключевых страниц, потому что именно они вас и смутили, за это прошу прощения :)
В общем, если вы отладите JS на страницах товаров, то Convead начнет учитывать просмотры товаров в воронке продаж.
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе». Это абсолютно точно не так, основной трафик идет из Директа, это я знаю точно. Счетчик показывает половину «прямых», половину «поиска». СТОЛЬКО прямых быть не может, это тоже известно.
При определении источника визита Convead в первую очередь ориентируется на заголовок HTTP referer. Мы разбираем его на части и пытаемся понять, на что он похож, и к какому источнику его можно отнести. Так же должен определяться и Яндекс.Директ. Я просмотрел выборочно порядка сотни ваших посетителей, но среди них не обнаружил ни одного с реферером из директа. Может быть вы точно знаете, что кто-то пришел из директа и сможете прислать мне ссылку на него?
Есть еще такое предположение: у вас много прямых заходов (с пустым referer), это может например говорить о том, что переход осуществлен из https:// на http://, в этом случае как раз реферер будет пустым. Последние новости из мира SEO говорят, что поисковики активно экспериментируют с шифрованием всего трафика, так что такая ситуация с переходом из поиска по рекламе теоретически может быть. Правда, обычно они используют промежуточный редиректер, который как раз редиректит с http:// на http://, но все же прецеденты появления пользователей с пустыми реферерами из поиска и рекламы уже были.
Лайфхак: если Convead не сможет определить источник по рефереру, то он попробует поискать в текущем URL вашего сайта параметр utm_source. Если найдет его — то он запишет визит в источник «Реклама» независимо от реферера. Так что просто добавьте ко всем вашим ссылкам в объявлениях что-то типа "...?utm_source=yandex_direct" и все будет считаться правильно. Эта рекомендация, кстати, пригодится при любом анализе трафика, не только в Convead.
Вообще хочу поблагодарить вас за фидбек, нам этого очень не хватает! Мы знаем свой проект слишком хорошо, чтобы объективно оценить удобство его использования и настройки, а также пользу от внедрения. Поэтому такая обратная связь от живых людей и настоящих магазинов бесценна, это открывает глаза и позволяет взглянуть по-новому на то, что мы считали не столь уж важным (хороший пример в ключевыми страницами, которые только путают). Еще раз спасибо :) Я доступен для любых вопросов.
Вася увидит открытый текст и будет кричать про безопасность :)
Мы, конечно, думали о шифровании, но решили не заморачиваться с этим по целому ряду причин. Если интересно — перечислю их отдельно.
тогда какая разница между «смотрели», «не заинтересовались» и «отказ», если во всех этих группах они посмотрели кучу товаров?
Я ввел вас в заблуждение своим предыдущим комментарием, поторопился. На самом деле обстоит так:
Покинули сайт (отказы) — это те, кто не посмотрел ни одного товара.
Смотрели товары — это те, кто посмотрел хотя бы один товар за визит.
Не заинтересовались — это те, кто посмотрел хотя бы один товар за визит, однако не прошел дальше по бизнес-процессу (ничего не купил и не положил в корзину).
Важно: под «Смотрели товары», «Положили в корзину» и пр. понимается наличие соответствующих эвентов ViewProduct, AddToCart и т.п., которые должны корректно передаваться с вашего сайта.
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе».
Напишите пожалуйста мне в ЛС id вашего аккаунта или домен, я посмотрю изнутри, что там насчет источников визитов.
1. Как-то замаскировать данные в JS не получится, но я, если честно, не совсем понимаю смысл этого мероприятия, ведь они «светятся» только для их владельца, сервер же генерирует вам персонализированный кусок JS-а. Думаете Вася Пупкин не знает, что он Вася Пупкин с таким-то емейлом? :)
Если, не смотря на выше сказанное, вы все-таки не хотите передавать данные через JS, то можете делать это с бекэнда, для этого у нас есть полнофункциональная библиотека на Ruby с Readme и примерами, а также чуть хуже документированная библиотека на PHP. С помощью этих библиотек вы вообще можете интегрировать ваш магазин с Convead практически без JS-а, передавая все данные с бекенда.
2. Вы говорите про понятие «Отказ» в привычных терминах веб-аналитики (Яндекс.Метрика или Google Analytics) — там действительно «отказами» считаются закрытия страницы без переходов. Convead же оперирует терминами жизненного цикла клиента в интернет-магазине. С точки зрения воронки продаж вашего бизнеса «отказной» клиент — это тот, что не проявил интереса к товарам (не добавлял их в корзину и не покупал).
У нас было три стейджинга на 1 тестировщика :) Потом маразм прошел и мы поняли, что все-равно один тестировщик в один момент времени использует только один сервер. Остальные два оставили для просмотра реквестерам фич. Но проблема одного тестового сервера на несколько готовых фич осталась.
У тестировщика есть свой тестовый сервер для проверки задач, но прежде чем скидывать задачу на проверку программист должен выложить ее в рабочем состоянии на тестовый сервер.
Каким образом программист узнает, свободен ли этот тестовый сервер, и не тестирует ли на нем сейчас кто-то свои задачи? Постоянно спрашивает у тестировщика? Просто у нас были постоянные проблемы с этим: программистов несколько, а тестировщик один. В результате в общем чате постоянные вопросы типа «Стейджинг свободен?! Занимаю!» и т.п. А если тестировщик в данный момент занят, то вообще непонятно что: программист переходит к следующему таску, а данный таск «подвисает» в неком статусе «ожидает тестирования»… В общем, как-то нам это сложно показалось. У вас с этим как?
Я вот чего только не пойму: как с таким режимом жить-то? Работать — понятно, хорошо (в теории). Но жизнь ведь не только из работы состоит. Как «среднестатистическому» человеку можно практиковать такой сон, если:
а) у него есть маленький ребенок, с которым нужно посидеть/отвести в садик/покормить (извини, малыш, папе надо поспать 20 минут);
б) он поехал путешествовать с друзьями или пошел в турпоход (чуваки, привал, у меня по расписанию 20 минут сон);
в) надо ехать куда-либо на машине в перегоном более 4 часов;
г) еще 100500 ситуаций.
В моем понимании это все, конечно, интересно в плане поиграться со своим организмом, но еще еще такой аспект как социальная среда. Человек вынужден приспосабливаться к среде, в которой он живет и с которой взаимодействует, и если 99.99% всех остальных людей работают днем и спят ночью, то такой режим сна как минимум доставит немало неудобств, причем как самому практикующему, так и всем, кто с ним находится в контакте.
Получается, что практическое применение этого метода весьма ограничено (как правильно было замечено в статье — м.б. какими-то экстремальными ситуациями)? Иначе нет смысла привыкать, проходить режим зомби, чтобы в ближайшем отпуске сорваться и отоспаться за все пропущенное время :)
Очень часто, как исполнителю, мне приходилось встречаться с позицией «я плачу деньги, значит я диктую условия». И в любых спорных ситуациях аргумент ну мы же платим! почему-то считался прямо-таки тузом (если не джокером) в рукаве. Было очевидно, что никак заказчик не может понять, что любая сделка должна быть взаимовыгодной, и тот факт, что у него есть деньги, никак не отменяет того, что ему оказываются равнозначные по стоимости услуги. Т.е., проще говоря, в голове большинства заказчиков его деньги всегда важнее (ценнее) оказываемой ему услуги. Безумно трудно что-то с этим сделать, я так и не смог с этим справиться.
Еще одна похожая ситуация — отношения работодателя и работника. По моим личным наблюдениям ситуация, когда работодатель считает, что он купил себе раба за ХХ руб. в месяц, встречается повсеместно. Хотя, если разобраться, это ведь тоже всего лишь сделка (трудовой договор), результат переговоров (собеседования), условия которой должна быть взаимовыгодной. Однако почему-то подавляющее большинство наших сограждан считает, что отстаивать свои интересы в рамках трудового договора — «западло» и «не лояльно». А работодатель часто считает, что ему за зарплату «все всё должны». Особенно часто это встречается в не-айтишной сфере.
1. А если все-таки нет доступа к системе в рабочие часы? Точка простаивает, или есть какие-то инструкции для работы в оффлайне?
2. Это я скорее коряво сформулировал вопрос… Забираете ли вы «сырые» заказы с сайта в 1С и обрабатываете там, или же менеджеры предварительно обрабатывают заказы где-то в админке сайта, после чего отправляют их в 1С? Или заказы с сайта вообще вы обрабатывается в отдельном потоке, который не пересекается с ритейловой 1С-кой?
Это бесценно! Мы, как ваши микро-коллеги, отлично вас понимаем :)
Если по существу, то вот что хотелось бы узнать:
1) Как вы решаете проблемы недоступности 1С в торговых точках, если не секрет? Например, нет интернета или «обновление сломало один эс»? Что они делают в таком случае?
2) Опять же, если это не коммерческая тайна: помимо торговых точек, которые работают в 1С, у вас есть какой-то выделенный отдел, который обрабатывает онлайн-заказы, которые прилетают в 1С с сайта?
Я имел ввиду именно второе: перевод проекта на русский. Интуитивно я понимаю, что не должно быть тут каких-либо проблем, но я излазил уже все настройки своего тестового проекта и просто ну нигде не вижу, как я могу добавить какой-то язык, кроме перечисленных пяти. А по вашей ссылке 404, наверное это приватный проект.
Не совсем понял, что значит «экспорт сразу в PHP» (в каком формате? gettext или ...?), но есть даже библиотека для работы с API CrowdIn: github.com/akeneo/php-crowdin-api (требует PHP >= 5.3.3).
Если в случае с рассылками все достаточно однозначно, то вот здесь мы пока не пришли к единому мнению. Дело в том, что ряд сайтов (в т.ч. среди наших клиентов) по каким-то причинам используют фейковые емейлы, которые вполне могут быть и не уникальными. Мы долго думали, стоит ли рассматривать такие граничные случаи, но сейчас уже наверное склоняемся к тому, что не стоит, и что действительно визиторов нужно «склеивать» по емейлу, т.к. в подавляющем большинстве случаев это будет правильным. Сделаем это в ближайшее время, спасибо за фидбек!
Все не обязательно, но «Product» при нормально работающих эвентах точно не нужна, т.к. они фактически дублируют друг друга. К слову, завтра мы планируем релиз, где просто уберем понятие «тип» у ключевых страниц, чтобы они больше никого не смущали.
Не тестировали, если честно. Но я бы не рекомендовал этого делать по тем же причинам, по которой GA и Метрика рекомендуют вставлять свои скрипты именно в head: так меньше вероятность того, что что-то не сработает из-за ошибок на странице или если пользователь быстро закроет вкладку. Ну и сам код асинхронный и не должен что-то сильно тормозить (это стандартная отмазка GA и Метрики :)).
Огромное спасибо за наводку, вот про yclid-то мы и забыли! В завтрашнем релизе это тоже учтем (тогда не нужно добавлять ничего руками в ссылки).
Дальнейшее обсуждение предлагаю перенести в приват, т.к. оно уже становится слишком частным. Спасибо!
На самом деле эвент «Просмотр товара» ваш магазин не присылает. В инструкции по настройке написано, что он должен вызываться после основного кода Convead, а он у вас стоит на странице выше кода. В консоли JS есть ошибка об этом: «ReferenceError: convead is not defined».
Кстати, вообще обратите внимание на ошибки JS на странице товара, там у вас есть синтаксическая ошибка выше по коду в var displayPrice = ; — из-за нее потенциально тоже могут быть разные проблемы.
Если ставить код эвента 'view_product' после основного кода неудобно — просто заверните его в DOM.ready():
Здесь есть определенная терминологическая проблема. Вы настроили ключевую страницу «Product», но Convead не считает это просмотром товара, т.к. для него «просмотр товара» — это именно эвент «view_product», про который я написал выше. Звучит довольно бредово, согласен, но здесь проблема в том, что мы находимся в стадии активного развития, проверяем различные гипотезы и часто изменяем поведение системы и в результате можем просто забыть о чем-то важном или считать это само собой разумеющимся.
Так, изначально мы придерживались идеи настройки системы без необходимости добавлять какие-либо куски JS на сайт, кроме основного кода. Мы думали, что достаточно проассоциировать какую-либо страницу на сайте с тем или иным этапом воронки продаж и все заработает. Так появился механизм «Ключевых страниц» и их типы («Product», «Cart», «Purchase» и т.п.). Идея была в том, чтобы просто настроить паттерны для этих ключевых страниц и ваши посетители будут распределяться по воронке. Однако со временем мы поняли, что не все так просто… У кого-то роуты сайта постоены на использовании GET-параметров, у кого-то — нет. У кого-то нет отдельной страницы чекаута или совершения заказа и т.д. Все это конечно можно было бы решить через настройку аккаунта, но когда мы прикинули, сколько галочек и полей нужно будет заполнить пользователю, то отказались от этой идеи и перешли от системы ключевых страниц к системе эвентов. Эвенты, кроме всего прочего, открыли также возможность учитывать такие важные для интернет-магазина события, как «положил товар в корзину» и некоторые другие. В настоящее время мы поддерживаем около десятка различных эвентов, в т.ч. и кастомные, которые удобно ставить на всякие кнопочки на сайте и затем сегментировать своих пользователей по этим эвентам.
А ключевые страницы мы решили оставить, поскольку бывает необходимость в том, чтобы отслеживать посещение именно определенной страницы. Кроме того, только посещения ключевых страниц сохраняются навсегда в таймлайне посетителя. Вот что действительно следовало бы сделать, так это убрать типы ключевых страниц, потому что именно они вас и смутили, за это прошу прощения :)
В общем, если вы отладите JS на страницах товаров, то Convead начнет учитывать просмотры товаров в воронке продаж.
При определении источника визита Convead в первую очередь ориентируется на заголовок HTTP referer. Мы разбираем его на части и пытаемся понять, на что он похож, и к какому источнику его можно отнести. Так же должен определяться и Яндекс.Директ. Я просмотрел выборочно порядка сотни ваших посетителей, но среди них не обнаружил ни одного с реферером из директа. Может быть вы точно знаете, что кто-то пришел из директа и сможете прислать мне ссылку на него?
Есть еще такое предположение: у вас много прямых заходов (с пустым referer), это может например говорить о том, что переход осуществлен из https:// на http://, в этом случае как раз реферер будет пустым. Последние новости из мира SEO говорят, что поисковики активно экспериментируют с шифрованием всего трафика, так что такая ситуация с переходом из поиска по рекламе теоретически может быть. Правда, обычно они используют промежуточный редиректер, который как раз редиректит с http:// на http://, но все же прецеденты появления пользователей с пустыми реферерами из поиска и рекламы уже были.
Лайфхак: если Convead не сможет определить источник по рефереру, то он попробует поискать в текущем URL вашего сайта параметр utm_source. Если найдет его — то он запишет визит в источник «Реклама» независимо от реферера. Так что просто добавьте ко всем вашим ссылкам в объявлениях что-то типа "...?utm_source=yandex_direct" и все будет считаться правильно. Эта рекомендация, кстати, пригодится при любом анализе трафика, не только в Convead.
Вообще хочу поблагодарить вас за фидбек, нам этого очень не хватает! Мы знаем свой проект слишком хорошо, чтобы объективно оценить удобство его использования и настройки, а также пользу от внедрения. Поэтому такая обратная связь от живых людей и настоящих магазинов бесценна, это открывает глаза и позволяет взглянуть по-новому на то, что мы считали не столь уж важным (хороший пример в ключевыми страницами, которые только путают). Еще раз спасибо :) Я доступен для любых вопросов.
Мы, конечно, думали о шифровании, но решили не заморачиваться с этим по целому ряду причин. Если интересно — перечислю их отдельно.
Я ввел вас в заблуждение своим предыдущим комментарием, поторопился. На самом деле обстоит так:
Важно: под «Смотрели товары», «Положили в корзину» и пр. понимается наличие соответствующих эвентов ViewProduct, AddToCart и т.п., которые должны корректно передаваться с вашего сайта.
Напишите пожалуйста мне в ЛС id вашего аккаунта или домен, я посмотрю изнутри, что там насчет источников визитов.
Если, не смотря на выше сказанное, вы все-таки не хотите передавать данные через JS, то можете делать это с бекэнда, для этого у нас есть полнофункциональная библиотека на Ruby с Readme и примерами, а также чуть хуже документированная библиотека на PHP. С помощью этих библиотек вы вообще можете интегрировать ваш магазин с Convead практически без JS-а, передавая все данные с бекенда.
2. Вы говорите про понятие «Отказ» в привычных терминах веб-аналитики (Яндекс.Метрика или Google Analytics) — там действительно «отказами» считаются закрытия страницы без переходов. Convead же оперирует терминами жизненного цикла клиента в интернет-магазине. С точки зрения воронки продаж вашего бизнеса «отказной» клиент — это тот, что не проявил интереса к товарам (не добавлял их в корзину и не покупал).
Каким образом программист узнает, свободен ли этот тестовый сервер, и не тестирует ли на нем сейчас кто-то свои задачи? Постоянно спрашивает у тестировщика? Просто у нас были постоянные проблемы с этим: программистов несколько, а тестировщик один. В результате в общем чате постоянные вопросы типа «Стейджинг свободен?! Занимаю!» и т.п. А если тестировщик в данный момент занят, то вообще непонятно что: программист переходит к следующему таску, а данный таск «подвисает» в неком статусе «ожидает тестирования»… В общем, как-то нам это сложно показалось. У вас с этим как?
а) у него есть маленький ребенок, с которым нужно посидеть/отвести в садик/покормить (извини, малыш, папе надо поспать 20 минут);
б) он поехал путешествовать с друзьями или пошел в турпоход (чуваки, привал, у меня по расписанию 20 минут сон);
в) надо ехать куда-либо на машине в перегоном более 4 часов;
г) еще 100500 ситуаций.
В моем понимании это все, конечно, интересно в плане поиграться со своим организмом, но еще еще такой аспект как социальная среда. Человек вынужден приспосабливаться к среде, в которой он живет и с которой взаимодействует, и если 99.99% всех остальных людей работают днем и спят ночью, то такой режим сна как минимум доставит немало неудобств, причем как самому практикующему, так и всем, кто с ним находится в контакте.
Получается, что практическое применение этого метода весьма ограничено (как правильно было замечено в статье — м.б. какими-то экстремальными ситуациями)? Иначе нет смысла привыкать, проходить режим зомби, чтобы в ближайшем отпуске сорваться и отоспаться за все пропущенное время :)
Еще одна похожая ситуация — отношения работодателя и работника. По моим личным наблюдениям ситуация, когда работодатель считает, что он купил себе раба за ХХ руб. в месяц, встречается повсеместно. Хотя, если разобраться, это ведь тоже всего лишь сделка (трудовой договор), результат переговоров (собеседования), условия которой должна быть взаимовыгодной. Однако почему-то подавляющее большинство наших сограждан считает, что отстаивать свои интересы в рамках трудового договора — «западло» и «не лояльно». А работодатель часто считает, что ему за зарплату «все всё должны». Особенно часто это встречается в не-айтишной сфере.
2. Это я скорее коряво сформулировал вопрос… Забираете ли вы «сырые» заказы с сайта в 1С и обрабатываете там, или же менеджеры предварительно обрабатывают заказы где-то в админке сайта, после чего отправляют их в 1С? Или заказы с сайта вообще вы обрабатывается в отдельном потоке, который не пересекается с ритейловой 1С-кой?
Это бесценно! Мы, как ваши микро-коллеги, отлично вас понимаем :)
Если по существу, то вот что хотелось бы узнать:
1) Как вы решаете проблемы недоступности 1С в торговых точках, если не секрет? Например, нет интернета или «обновление сломало один эс»? Что они делают в таком случае?
2) Опять же, если это не коммерческая тайна: помимо торговых точек, которые работают в 1С, у вас есть какой-то выделенный отдел, который обрабатывает онлайн-заказы, которые прилетают в 1С с сайта?
Добавил в статью ссылку на ваш комментарий со скриншотами.
monosnap.com/image/TKvY8NTgWVSUzCACGYDe7baQCB85kl.png
monosnap.com/image/2wtT3w2k1vbL7TjyKnq9SYK2lVhrbM.png