Рубрики
Тех. решения

Mandrill Webhooks. Автоматизация получения информационных статусов сообщений

Эта небольшая статья будет посвящена вопросу автоматизации получения статусов сообщения от сервиса Mandrill. В статье не будет кода, только полезный текст и ссылки.

Для начала определимся с проблемой (задачей/целью). Скажем, в CRM или в другом вашем системе происходит массовая отправка маркетинговых писем клиентам. Вам, группе маркетинга или еще будь-то кому интересно получать информацию о том:

Рубрики
Тех. решения

Как реализовать хранение коммуникаций с клиентами?

Написал статью о том, как можно реализовать хранение коммуникации с клиентами. Почитать можно здесь: http://pontyk.com.ua/zametki/opyt-vnedreniya-tablicy-kommunikacii-s-klientami/ 

Рубрики
Тех. решения

Интеграция UMI.CMS с Telegram

Недавно написал статейку на профильном блоге о том, как можно быстро интегрировать UMI.CMS и Telegram бота. Об этом можно почитать здесь: https://goo.gl/WxSgyj

Рубрики
Тех. решения Управление проектами

Алгоритм системного решения проблем

Допустим, упал сайт. Или у кого-то отображается не тот номер телефона в подменах. Или в рекламной кампании обнаружены лишние ключевые фразы. Реакция по умолчанию: исправить и забыть. Такая реакция приводит к плохим последствиям: сложность проекта растёт, на починку уходит всё больше времени, а на настоящую работу — всё меньше.

Я для себя пришёл к такому алгоритму:

1. Обнаружена проблема
Сработал мониторинг. Или клиент прислал. Или сами заметили.

2. Подтвердить получение проблемы и срок реакции
Записать в тикет-систему / баг-трекер / докс. Уведомить менеджера / команду / клиента. «Принял, разбираюсь прямо сейчас». «Принял, посмотрю после задачи Х через час».

Если не уведомить, остальные будут нервничать в неизвестности. Не будет ощущения, что вы контролируете ситуацию. Что за вами не надо перепроверять. Что вам можно доверить что-либо важное.

3. Оценить критичность и составить план действий
Критичность определяется не паникой, а возможными последствиями в перспективе. Нужно представить и прочувствовать все последствия, сравнить с другими задачами и принять решение. Некоторые проблемы нужно решать прямо сейчас. Некоторые можно не решать.

Обычно получается так, что проблемы вытесняют задачи по развитию и системным решениям. Это не правильно. Если хорошо прочувствовать важность проблем и важность системных решений, то найдётся баланс.

4. Убедиться, что проблема действительно есть
Чтобы решить проблему, надо сначала её воспроизвести. Иногда это сложно. Надо либо воспроизвести, либо доказать, что её нет. «У меня не воспроизводится» — не ответ.

Снять проблему может только тот, кто о ней сообщил. Пока не снял, считаем проблему актуальной.

Иногда проблема только кажется проблемой, а на самом деле так и задумано. Тут помогает документация и память участников команды.

5. Подтвердить, что проблема есть, и сказать, когда исправите
Исправить можно сразу, через час, день, неделю или никогда. Зависит от критичности проблемы и ваших процессов.

Но информировать обязательно — для прозрачности, ощущения контроля и доверия.

6. Исправить
Исправить.

7. Проинформировать
Проинформировать, что исправили и рассказать, что собираемся делать дальше.

В этот момент менеджер и клиент считают, что главное уже сделано и ждут новостей по следующей Очень Важной Проблеме. На самом деле, самое важное ещё впереди. Если работу по алгоритму не довести до конца, то ошибки будут только накапливаться. Это в интересах менеджера и клиента не давать закрыть просто исправленную ошибку.

8. Сделать контрольную проверку
Проверить, что ошибка действительно исправлена. Обязательно сделать это другим способом. Желательно на следующий день со свежим взглядом. Например, сайт посмотреть в других браузерах и в мониторинге. Рекламу посмотреть не в интерфейсе, а в поиске и в статистике.

Вы не поверите, как часто контрольные проверки на следущий день обнаруживают недоисправленные ошибки.

9. Проинформировать
Мало кто делает контрольные проверки. У всех Нет Времени. Сделать и расказать — +1 в карму.

10. Что могло сломаться рядом? Что могли сломать, пока чинили?
Починили вёрстку в одном браузере? А в других? А на мобилках? А в версии для печати?
Изменили работу калькулятора на лендинге? А на основном сайте? А в других регионах? А события не поломали?
Обнаружили лишнее ключевое слово в одной РК? А есть в других? А в SEO? А в списке услуг на сайте?

Вообще-то, это надо делать сразу, но неплохо проверять ещё раз после.

Кстати, такое внимание к деталям и умение смотреть по сторонам — один из важных криериев проверки людей на стажировке.

11. Проинформировать
Ну вы поняли.

12. Посчитать цену ошибки
Мой любимый пункт. Почему-то считать очень не хочется. Или хочется посчитать по нижней границе. Но сделать это надо обязательно и не занижать.

Во-первых, команда часто не представляет, сколько стоят ошибки. Конкретное число в рублях отрезвляет и реально влияет на действия. Поводом к написанию этого поста стала серия очень дорогих ошибок. Это цена обучения. Если не посчитать, обучение будет менее эффективным.

Во-вторых, клиенты без точных данных рисуют в голове огромные цифры. А это далеко не всегда соответствует действительность.

Внимание: если в расчётах найдётся ошибка или процесс расчёта будет непонятен, то восстановить доверие будет сложно. Повышенная Бдительность.

13. Проинформировать
Вот здесь больно, да.

14. Найти системное решение
Надо сделать так, чтобы ошибка никогда не повторялась. Тут появляются мониторинги, чек-листы, регламенты и другие бюрократические штуки. Часто их не делают, потому считают любую бюрократию злом. Бюрократия бывает проблемой, но чаще проблема в отсутствии базовых процессов и чек-листов.

Кстати, «человек ошибся» — это не разовая ошибка. Люди ошибаются всегда, поэтому людей считаем системной ошибкой.

Ещё бывают редкие ошибки и дешёвые ошибки. Их может быть дешевле не лечить и честно об этом сказать. Например, глючащий несколько дней сервис онлайн-консультанта снизит выручку на 40 т.р.. Цена смены сервиса с переобучением людей и перестройкой аналитики — ~400 т.р. и ещё не известно как на конверсию повлияет. Решение Всё Поменять здесь было бы поспешным.

15. Проинформировать
Если не спрашивают, всё равно рассказать. Системные решения — это же самое важное.

16. Сделать отчёт для себя / команды / клиента в будущем
Отчёт идёт прямо по этому формату. По этим отчётам потом хорошо искать причины похожих проблем. И учить новеньких.

17. Что осталось сделать?
Закрывать тикет можно только когда ответ на этот вопрос пуст.

Как быть уверенным, что сделано действительно всё? Доверять внутреннему чутью. Чутье — это накопленный опыт и боль.

Ещё раз алгоритм списком (можете скопировать к себе)

  1. Обнаружена проблема
  2. Подтвердить получение проблемы и срок реакции
  3. Оценить критичность и составить план действий
  4. Убедиться, что проблема действительно есть
  5. Подтвердить, что проблема есть, и сказать, когда исправите
  6. Исправить
  7. Проинформировать
  8. Сделать контрольную проверку
  9. Проинформировать
  10. Что могло сломаться рядом? Что могли сломать, пока чинили?
  11. Проинформировать
  12. Посчитать цену ошибки
  13. Проинформировать
  14. Найти системное решение
  15. Проинформировать
  16. Сделать отчёт для себя / команды / клиента в будущем
  17. Что осталось сделать?

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

В тривиальных случаях прохожу по алгоритму в уме. В сложных — открываю докс, копирую алгоритм и иду по пунктам.

Спасибо за статью Всеволоду Устинову.
Источник: http://vsevolodustinov.ru/blog/all/algoritm-sistemnogo-resheniya-problem/

Рубрики
Тех. решения

Активация магазина в интернет-эквайринге LiqPay.ua

Как же раньше было удобно работать с LiqPay:

  • зашел
  • зарегистрировался в сервисе
  • добавил компанию
  • указан реквизиты или номер карты
  • написал в чат с запросом активации

PROFIT: тебя активировали

Сейчас же активацию ужесточили, и сделать это просто, для тех кто знает что делать. Для тех, кто не знает пишу!

Что необходимо для активации возмещения Вашего магазина?

Вариант 1

Уполномоченному лицу нужно добавить Доверенное лицо, на номер телефона которого зарегистрирована учетная запись в LiqPay, в Приват24 для юридических лиц. При этом, доверенное лицо должно быть верифицировано в любом отделении ПАО КБ “Приватбанк”.

Инструкция для Уполномоченного лица:

  1. Уполномоченному лицу войти в личный кабинет юридического лица Приват24 в раздел “Матрица полномочий” ссылка: https://cb.privatbank.ua/p24/mcredentials ;
  2. Выбрать вкладку «Доверенные лица»;
  3. Нажать на кнопку “Добавить Доверенное лицо”;
  4. Заполнить “Данные нового доверенного лица”;
  5. В блоке «Ответственный за» выделить чек-боксом “Эквайринг” (на этом шаге важно проверить чтоб не были выбраны дополнительные чек-боксы для указанного Доверенного лица);
  6. Подписать внесенные изменения ЭЦП (электронно-цифровой подписью).

Инструкция для Доверенного лица:

  1. Подойти в любое отделение ПАО КБ “Приватбанк” с Паспортом и ИНН;
  2. Пройти короткую процедуру верификации у любого менеджера отделения.

После выполнения инструкций, указанных выше: написать на почту monitoringceb@privatbank.ua или на support@liqpay.com, ну или написать в он-лайн чат на сайте https://liqpay.ua/

Вариант 2

Зарегистрировать новую учетную запись на финансовый номер телефона уполномоченного лица, указанного в реквизитах регистрируемого предприятия, обслуживаемого в ПАО КБ “Приватбанк”.

Инструкция для Уполномоченного лица:

  1. Зарегистрировать учетную запись LiqPay на свой финансовый номер телефона уполномоченного лица, указанного в реквизитах регистрируемого предприятия, обслуживаемого в ПАО КБ “Приватбанк”;
  2. Создать магазин и указать реквизиты предприятия, на которое будут поступать возмещения;
  3. В настройках магазина (пункт “Права доступа”) добавить данные Доверенного лица. Указанное лицо будет иметь полный доступ к управлению магазином.
Рубрики
Заметки Тех. решения

Организация отправки данных в Ecommerce Google Analitycs

Представим, что у вас есть много проектов (веб-сайты, приложения), которые работают с одной базой заказов (скажем это CRM система), но на каждом проекте продается свой специфический товар, будь то потребительские товара, одежда, канцелярские товары или страховка…

Вы организовали хранение данных и сейчас захотели отправлять данные в GA, но есть некоторые проблемы (возможно вы еще о них не знаете, но они есть):

  • все проекты используют различные языки, фрейморки и т. д. (Android, iOS, сайты на .net, php) и нужно под каждый продукт писать свой код, которые отправляет данные в GA
  • нужно учитывать, что заказы, которые оформляет заказчик могут изменяться, отменяться
    -… возможно вы что-то еще придумаете, напишите об этом в комментариях