Ключевые факты
|
Проект |
эстонский интернет-магазин по изготовлению ключей |
|
География |
Эстония |
|
Ниша |
изготовление и продажа ключей |
|
Платформа магазина |
InSales |
|
Интеграция |
Omniva в сценарии доставки, Maksekeskus в сценарии оплаты |
|
Тип работ |
backend-приложение, интеграция оплаты и доставки, автоматизация обработки заказов |
|
Архитектура |
отдельное приложение на отдельном сервере, которое работало промежуточным слоем между InSales и внешними сервисами |
|
Результат |
заказ перестал требовать ручного сопровождения на каждом шаге |
Коротко
Для эстонского магазина по изготовлению ключей мы разработали отдельное приложение, которое связало InSales с checkout-процессом оплаты и доставки. Доставка была завязана на Omniva, оплата — на Maksekeskus: покупатель мог выбрать способ оплаты и вариант доставки, а магазин получал статусы и трек-номера без ручного сопровождения каждого заказа.
До проекта заказ выглядел почти как ручная продажа по телефону. Покупатель оставлял заявку на сайте, в заказе были телефон и почта, а дальше менеджер сам связывался с клиентом, уточнял детали, отправлял ссылку на оплату, проверял поступление денег, отдельно оформлял доставку и вручную сообщал клиенту, что происходит с заказом.
|
Для небольшой компании это быстро стало узким местом. В бизнесе по изготовлению ключей не сидит огромный колл-центр: основную операционку тянули владелец и партнер. Поэтому интеграция была не “удобной доработкой”, а способом убрать с людей ежедневную ручную нагрузку. |
Мы сделали приложение-прослойку между InSales, Omniva и Maksekeskus. После этого покупатель мог выбрать способ оплаты и доставки прямо в процессе заказа, а статусы, доставка, трек-номера и информация по заказу начали проходить автоматически.
Как было до интеграции
На сайте не было автоматической оплаты и доставки.
Покупатель оформлял заказ, оставлял номер телефона и email. Дальше начиналась ручная работа: менеджер звонил клиенту, обсуждал заказ, отправлял ссылку на оплату, ждал оплату, потом отдельно оформлял доставку и дальше сам сообщал клиенту статус.
Такой процесс может работать, пока заказов мало. Но чем больше заявок, тем сильнее бизнес начинает упираться в людей.
Проблема была не в том, что менеджеры плохо работали. Наоборот: они держали процесс на себе. Но из-за этого владелец и партнер постоянно тратили время на рутину, которую нормальный интернет-магазин должен закрывать автоматически.
Почему простого подключения было мало
Задача была не в том, чтобы просто добавить кнопку оплаты или способ доставки.
Нужно было собрать весь маршрут заказа:
· покупатель выбирает товар;
· выбирает способ оплаты;
· выбирает доставку: ПВЗ или курьер;
· заказ создается в InSales;
· данные уходят во внешний сервис;
· оплата и доставка связываются с заказом;
· статусы меняются автоматически;
· трек-номер подтягивается без ручного поиска;
· клиент получает информацию по заказу на email.
|
Если подключить только оплату, менеджер все равно оформляет доставку руками. Если подключить только доставку, менеджер все равно вручную отправляет ссылку на оплату и проверяет деньги. Если не связать статусы, заказ опять начинает жить в разных системах. |
Поэтому решение должно было быть не точечной правкой, а отдельной интеграцией.
Что мы сделали
Мы разработали отдельное приложение, которое жило на отдельном сервере и работало как промежуточный слой между InSales, Omniva и Maksekeskus.
Это приложение принимало данные заказа из InSales, передавало их во внешние сервисы, возвращало нужные данные обратно и помогало синхронизировать процесс: оплату, способ доставки, статус и трек-номер.
Для клиента это выглядело как нормальный современный checkout: можно выбрать, как оплатить заказ, и сразу выбрать вариант доставки. Для менеджера это означало, что больше не нужно вручную вести каждый заказ от звонка до отправки.
Логика заказа
Для заказа собрали понятную цепочку статусов:
· “Новый”;
· “В обработке”;
· “Согласован”;
· “Товара нет в наличии”;
· “Клиент ждет поступление товара”;
· “Возврат”;
· “Отгружен”;
· “Доставлен”;
· “Отменен”;
· “Возврат ДС”.
Эта логика нужна была для реальной работы, а не для красивой схемы. Если товар есть, заказ идет к сборке и отправке. Если товара нет, клиенту нужно предложить ждать поступление или оформить возврат. Если заказ отгружен, клиенту нужен трек-номер. Если доставлен или отменен, клиент тоже должен получить понятное email-уведомление.
В ручном процессе все это держалось на памяти и внимательности менеджера. В интеграции статусы стали частью системы.
Оплата и доставка в одном процессе
Главная ценность интеграции была в том, что оплата и доставка оказались в одном сценарии.
Покупатель не просто оставлял заявку и ждал звонка. Он мог пройти более привычный путь интернет-магазина: выбрать товар, выбрать оплату, выбрать доставку, оформить заказ.
Для доставки можно было выбрать разные варианты: пункт выдачи или курьерскую доставку. После отправки трек-номера подтягивались автоматически, без отдельного ручного поиска и передачи клиенту по телефону.
Это сильно меняет ощущение магазина. Он перестает быть формой заявки и начинает работать как полноценный e-commerce.
Что изменилось для бизнеса
До интеграции заказ требовал постоянного участия человека. После интеграции значительная часть рутины ушла в систему.
Владелец и партнер получили больше свободы: не нужно вручную созваниваться с каждым клиентом, отправлять платежные ссылки, контролировать оплату, оформлять доставку и отдельно объяснять клиенту, что происходит с заказом.
Для небольшого бизнеса это особенно важно. Автоматизация здесь не про “сэкономить пару кликов”. Она про то, чтобы компания могла принимать больше заказов без пропорционального роста ручной нагрузки.
После внедрения оплаты, доставки и автоматической смены статусов команда получила больше времени на сам бизнес, а не на ручное сопровождение каждого заказа. Это помогло магазину спокойнее расти и обрабатывать заказы без постоянного телефонного контроля.
Результат
Мы сделали интеграционное приложение между InSales, Omniva и Maksekeskus, которое связало заказ, оплату, доставку, статусы и трек-номера в один процесс.
Магазин перестал работать как “заявка плюс звонок менеджера” и стал ближе к полноценному интернет-магазину: покупатель выбирает оплату и доставку сам, заказ проходит через систему, а менеджер не тащит на себе каждый шаг вручную.
Это хороший пример интеграции, где ценность не только в API. Ценность в том, что техническое решение попало в реальную боль бизнеса: освободить людей от повторяющейся операционки и дать магазину расти без постоянного ручного контроля.
Что получил клиент
Клиент получил не просто подключенный способ доставки или оплаты, а более взрослую схему работы интернет-магазина.
В ежедневной работе изменилось главное: менеджер перестал быть единственным связующим звеном между покупателем, оплатой, доставкой и статусами. Покупатель получил более привычный путь интернет-магазина, а команда магазина — процесс, который не требует звонка и ручного контроля на каждом шаге.
Для небольшого e-commerce-бизнеса это особенно ценно. Рост перестает означать, что владельцу и партнеру нужно пропорционально больше звонить, проверять, отправлять ссылки и искать трек-номера. Часть этой нагрузки берет на себя система.
