Площадка-агрегатор дверей: предложения салонов, дилеров и фабрик, сравнение по параметрам, цене, срокам и городу, лиды продавцам и модерация ассортимента.
SEO и платное продвижение площадки дверей: параметрические страницы под 6 400 запросов, Яндекс.Директ на коммерческие запросы, аналитика до переданного лида.
Маркетплейс дверей, в котором 500+ продавцов ведут собственный ассортимент, а площадка отвечает за витрину, модерацию, оплату и выплаты. Покупатель собирает один заказ у нескольких продавцов, платформа делит его на субзаказы, удерживает комиссию и агрегирует доставку.
Задача
Витрина не разделяла продавцов
— Товары загружали вручную, у позиции не было владельца. Покупатель не понимал, кто продавец, кто везёт заказ и кому он платит.
Комиссии считали в таблицах
— Начисления и удержания сводили в Excel, сверка занимала до недели, и продавец не видел, из чего сложилась сумма к выплате.
Модерация не успевала за ассортиментом
— Очередь из 50 000+ карточек проверяли вручную, поэтому часть товаров уходила в продажу с неверными размерами, ценами и фото.
Интернет-магазин напольных покрытий, в котором покупатель сам считает нужное количество упаковок и видит покрытие в своей комнате до покупки. Каталог, 3D-визуализация и остатки из 1С работают в одном контуре.
Задача
Покупатель не мог посчитать объём
— Ламинат, кварцвинил, паркетная доска и линолеум продаются разными фасовками. Чтобы понять количество, покупатель звонил в магазин — и часто уходил к конкуренту.
Покрытие невозможно было «примерить»
— Фотография рулона не передаёт цвет и фактуру. Из-за этого росли возвраты и отказы на этапе выбора.
Каталог плохо фильтровался
— У товаров десятки характеристик: класс износостойкости, толщина, фаска, тип замка, влагостойкость, основа. Плоский фильтр не позволял дойти до нужной позиции.
Интернет-магазин дверей на 12 000+ SKU: фасетный каталог по десяткам характеристик, конфигуратор комплекта под размер проёма и наличие по 9 складам. Цены, остатки и заказы синхронизированы с 1С, доставка и монтаж оформляются в том же заказе.
Задача
Каталог не тянул 12 000+ SKU
— Фильтры работали по типу и цвету, а решения принимаются по материалу, покрытию, стеклу, размеру, шумоизоляции и огнестойкости. Часть ассортимента вообще не попадала в выдачу.
Комплект считали вручную
— Дверь продаётся комплектом: полотно, коробка, наличники, доборы, фурнитура. Менеджер собирал состав в таблице и присылал смету письмом, поэтому заказ растягивался на дни.
Наличие по складам не отображалось
— Остатки девяти складов и пунктов выдачи жили только в 1С. Клиент оформлял «под заказ», а через день узнавал, что комплекта в нужном городе нет.
Построили SEO-структуру под параметрические и гео-запросы, вычистили дубли каталога на 12 000+ SKU и завели товарные кампании по фиду. Сквозная аналитика и коллтрекинг считают стоимость заявки по каждому каналу.
Задача
Спрос уходил в параметрические запросы
— Покупатели ищут «двери 80 см скрытые», «входные двери с терморазрывом», «противопожарные двери EI 60». Таких страниц на сайте не было, и запросы забирали конкуренты и маркетплейсы.
Каталог плодил дубли
— Фильтры и пагинация создавали тысячи почти одинаковых URL. Часть карточек SKU не индексировалась, а вес страниц размывался между дублями.
Реклама вела на общие разделы
— Кампании не были разведены по товарным направлениям и городам, ставки выставлялись вручную. Заявка стоила дорого, а часть бюджета уходила на позиции без наличия.
Свели в одну учётную систему сделки, заказы, склад по 9 точкам, замеры и монтажные наряды, закупки, документы и финансы. Интеграции с 1С, телефонией и банком убрали ручной перенос данных, дашборды показывают маржу и загрузку бригад.
Задача
Сделка и заказ жили отдельно
— Менеджер вёл воронку в таблице, заказ оформлял в 1С, а история переписки и звонков оставалась в телефоне. После ухода сотрудника восстановить работу с клиентом было невозможно.
Остатки девяти точек расходились
— Резервы ставили вручную и не всегда вовремя, поэтому один комплект продавали дважды. Отмены по отсутствию били по репутации и по бюджету на рекламу.
Замеры и монтаж планировали в чатах
— Бригады получали адреса сообщениями, материалы и сроки не фиксировались. Переносы и повторные выезды не учитывались в стоимости монтажа.
Разработали два кабинета на общей авторизации: покупатель видит заказы, статусы, замеры, монтаж и документы, дизайнер и подрядчик — персональный прайс, спецификации проектов и повторный заказ. Самообслуживание разгрузило менеджеров.
Задача
Кабинет не отвечал на вопросы покупателя
— Покупатель видел номер заказа, но не знал, оплачен ли он, на каком складе комплект, когда приедет бригада и наступила ли гарантия. Каждый такой вопрос шёл в звонок.
Документы выдавали по запросу
— Счёт, УПД и гарантийный талон готовили вручную и отправляли письмом. Бухгалтерии клиентов ждали документы неделями, а менеджер повторял одну и ту же работу.
B2B-направление жило вне сайта
— Дизайнеры и комплектаторы работали по персональным ценам, но спецификации проектов вели в Excel и присылали на почту. Ни истории цен, ни повторяемости заказов не было.
Сайт производителя межкомнатных дверей: каталог моделей и коллекций, подбор по покрытию и цвету RAL, конфигуратор нестандартного размера и расчёт комплекта. Заявки с гео-страниц уходят в тот салон дилерской сети, который отвечает за город.
Задача
Каталог не показывал производство
— Модели были перечислены списком без привязки к цеху, покрытиям и коллекциям. Покупатель не понимал, что видит продукт производителя, а не перепродажу.
Покрытия не были отдельной сущностью
— Эмаль по RAL, шпон и экошпон упоминались только в текстах, поэтому выбрать модель по цвету или типу покрытия на сайте было нельзя.
Нестандартный размер считали по телефону
— Проём, нестандартная высота и скрытые двери под покраску требовали разговора с менеджером и отдельного расчёта комплекта в таблице.
Продвижение бренда производителя, а не отдельного салона: семантика по моделям, покрытиям и коллекциям, посадочные под запросы о покрытиях, гео-страницы городов присутствия. Лид получает источник и уходит в тот салон, который отвечает за город.
Задача
Бренд не участвовал в спросе
— Запросы по покрытиям, нестандартным размерам и коллекциям забирали агрегаторы. В выдаче производителя почти не было, брендовый спрос не рос.
Не было страниц под покрытия
— Эмаль по RAL, шпон и скрытые двери под покраску не имели отдельных посадочных, поэтому реклама вела на общий каталог и стоила дороже.
Лиды не доходили до салонов
— Заявки из рекламы и с сайта собирались в офисе производителя и распределялись между дилерами вручную по таблице городов.
Учётная система производителя: лиды и дилеры, заказы салонов, передача заказов в цех со спецификацией и покрытием, планирование производства, себестоимость, отгрузки и взаиморасчёты с сетью. Загрузка цеха и маржа собираются в дашборды.
Задача
Заказы салонов жили в почте
— Спецификация приходила текстом или файлом, менеджер переносил её в таблицу и уже оттуда — в наряд цеха. На каждом переносе появлялись расхождения.
Покрытие и размер терялись по дороге
— Ошибка в цвете RAL, оттенке шпона или размере проёма выявлялась только в цехе. Заказ уходил в переделку, срок сдвигался, салон узнавал об этом последним.
Загрузка цеха не была видна
— Сроки салонам называли «на глаз»: у участков не было общего плана, срочные заказы ломали очередь, а материалы заказывались по памяти.
Кабинет дилера: персональный прайс и скидки, наличие и сроки производства, оформление и отслеживание заказов, документы и закрывающие, маркетинговые материалы, выгрузка прайса и API для собственной витрины салона. Публичный сайт остаётся витриной бренда, кабинет — рабочим инструментом дилера.
Задача
Прайс жил в файлах
— Персональные цены и скидки приходили вложениями, менеджер салона считал комплект в собственной таблице и не всегда видел актуальные условия.
Сроки уточняли у менеджера
— Наличие и срок изготовления по конкретному покрытию не были видны: каждый заказ начинался со звонка в офис производителя.
Документы терялись в переписке
— Счета, УПД и закрывающие документы салон искал по почтовым цепочкам, сверка взаиморасчётов затягивалась на недели.
Два интернет-магазина дверей с разным позиционированием и сайт услуг монтажа работают на общей платформе: единый каталог, заказы, клиенты и склад, но свои домены, шаблоны и правила цен. Управление разнесено по семи панелям под задачи каждой службы.
Задача
Два магазина на разных движках
— Ассортимент и цены велись дважды, поэтому один и тот же товар продавался по разным ценам без понятной логики, а остатки сайтов расходились.
Заявки на монтаж вне системы
— Замеры и установка принимались по телефону и в переписке: терялись адреса, сроки и договорённости по гарантийным работам.
Одна админка на все службы
— Контент-менеджер, склад и монтажная служба работали в общем интерфейсе без ограничения прав и перекрывали работу друг друга.
Два магазина продвигаются по раздельным стратегиям и не забирают друг у друга показы, а услуги монтажа получили собственные посадочные и гео-страницы. Трафик, заявки и выручка трёх сайтов сведены в одну отчётность.
Задача
Магазины каннибализировали друг друга
— Один запрос выводил оба домена в топ-10, бюджет Директа рос на внутреннюю конкуренцию, а заявки распределялись между магазинами случайно.
Монтаж не имел своих посадочных
— Замер, демонтаж и установка были свёрнуты в раздел о доставке, поэтому спрос на работы уходил к подрядчикам конкурентов.
Три сайта без общей аналитики
— Метрика стояла на каждом домене отдельно, и сравнить стоимость заявки между магазинами и монтажом было невозможно.
Заказы из двух интернет-магазинов и заявки на монтаж сведены в одну воронку с общим складом, резервами и нарядами бригад. Закупки, документы и финансы ведутся в той же системе, а KPI считаются отдельно по каждому сайту и направлению.
Задача
Три источника заявок врозь
— Заказы двух магазинов и заявки на монтаж обрабатывались в разных интерфейсах, поэтому сводку по направлениям собирали вручную в конце недели.
Склад без резервов
— Остатки сверяли по файлам, из-за чего менеджер подтверждал позиции, которых на складе уже не было, и заказ уходил в просрочку.
Наряды и бригады без учёта
— Замеры и монтаж распределялись в чате: сроки пересекались, расход материалов не фиксировался, а акты собирали заново по памяти.
Кабинет объединяет три сценария: покупатель видит заказы обоих магазинов и заявки на монтаж, мастер получает наряд и закрывает его фотоотчётом, диспетчер распределяет работы по бригадам. Наряды ушли из чатов, а акты закрываются в день сдачи объекта.
Задача
Статус заказа узнавали по телефону
— Клиент не видел этап сборки и доставки, поэтому звонил в поддержку по каждому заказу — и отдельно по второму магазину, где была своя история покупок.
Документы и гарантия по запросу
— Чеки, акты и гарантийные талоны высылали вручную, а история обращений нигде не сохранялась, поэтому спорные случаи решали заново.
Наряды жили в мессенджерах
— Мастер получал адрес и срок текстом, фотоотчёты не фиксировались, а расхождения по материалам всплывали только при сдаче работ.
Сайт сети из 50+ магазинов: покупатель выбирает город, видит наличие нужной двери в ближайшем салоне, оформляет самовывоз и записывается на замер именно в эту точку. Цены, остатки и заказы приходят из 1С.
Задача
У сети не было единого сайта
— У части магазинов оставались сайты-визитки с разным ассортиментом и устаревшими ценами, у остальных — только карточка на карте. Покупатель не понимал, где смотреть товар, и уходил к конкурентам.
Наличие товара не было видно
— Двери крупногабаритные, перевозка между городами дорогая, поэтому важно было знать, есть ли модель в ближайшем салоне. На сайте такой информации не было: остаток выясняли звонком.
Запись на замер уходила не в тот магазин
— Заявки с форм попадали в общий колл-центр и распределялись вручную. Часть замеров уезжала в соседний город, и точка теряла продажу, за которую уже заплатила рекламой.
Продвижение разбито по магазинам: у каждой точки своя посадочная страница, карточка в Яндекс.Бизнес, локальные кампании и отчётность. Бюджет распределяется по потенциалу города, а лид виден до конкретного салона.
Задача
Все города продвигались одинаково
— Одна федеральная кампания и один шаблон объявления на всю сеть. Магазин в районном центре и салон в миллионнике получали сопоставимый бюджет, а заявку нельзя было привязать к точке.
Городские страницы были дублями
— Для каждого города генерировалась страница с подменой названия. Поисковые системы держали их в дополнительных результатах, органического трафика такие посадочные почти не приносили.
Карточки на картах расходились с фактом
— Часть магазинов не была подтверждена в Яндекс.Бизнес, у других стояли старый телефон и неверный график. Отзывы копились без ответов, и точки теряли посетителей, которые искали салон рядом.
Единая учётная система сети: сделки и заказы всех магазинов, центральный склад и остатки точек, резервы и перемещения, наряды на замер и монтаж, гарантия, кассы и планы продаж. 1С, банк, телефония и сайт сведены в один контур.
Задача
У каждой точки был свой учёт
— Часть магазинов вела заказы в таблицах, часть — в локальных базах 1С. Свод по сети собирали вручную к середине следующего месяца, и цифры расходились с фактическими продажами.
Остатки не были видны между точками
— Продавец не знал, есть ли нужный размер у соседнего магазина, и оформлял закупку у поставщика. Оборотные средства замораживались в товаре, который уже лежал на складе другого города.
Замеры и монтаж жили в мессенджерах
— Наряды передавали бригаде сообщением, сроки никто не контролировал, акты выполненных работ собирали на бумаге. Срыв выявляли уже по обращению клиента.
Два кабинета на одном ядре. Покупатель видит статусы заказов, замеров и монтажа, хранит документы и повторяет заказ по спецификации. Директор точки — план продаж, остатки, наряды монтажников и задачи смены. Центральный офис перестал работать справочной службой.
Задача
Статус заказа узнавали звонком
— Понять, пришла ли дверь в магазин и назначен ли монтаж, можно было только по телефону. Центральный офис тратил на такие вопросы до двух третей рабочего времени.
Документы и гарантия терялись
— Чеки, акты и гарантийные талоны выдавали на бумаге, клиент приносил их в салон при обращении. К моменту гарантийного случая часть документов найти не удавалось.
Директор собирал отчёты вручную
— План и факт продаж по точке сводили в таблицах, цифры расходились с учётом. На подготовку недельного отчёта у директора уходило несколько часов.
Сайт шоурума в ТЦ «Декоратор», который работает и витриной, и инструментом B2B-продаж: каталог профильных систем с сертификатами, конструктор спецификации под проём, страницы выполненных объектов и запрос КП. Цены и остатки приходят из 1С.
Задача
Каталог не описывал профильные системы
— Алюминиевые, стальные и противопожарные конструкции стояли в одном списке без характеристик. Класс огнестойкости, ограничения по ширине проёма и комплектующие уточняли у менеджера по телефону.
Спецификацию собирали в Excel
— На объект из 20–30 проёмов уходило полдня: размеры переписывали из письма, классы огнестойкости сверяли по сертификату. Ошибка в размере возвращалась уже с монтажа.
Сертификаты и протоколы были недоступны
— Сканы сертификатов и протоколов испытаний лежали в папках менеджера. Проектировщик и служба эксплуатации не могли проверить документы до закупки и запрашивали их письмом.
Локальная система спроса для шоурума в ТЦ «Декоратор»: семантика по гео и типам конструкций, страницы под отрасли и объекты, Яндекс.Бизнес с отзывами и Директ по B2B-запросам. Результат считается до стоимости объекта, а не до клика.
Задача
Спрос ограничен проходимостью ТЦ
— Обращения приходили только от посетителей «Декоратора» и по рекомендациям. Заявок из поиска и с карт не было, поэтому выручка зависела от потока внутри торгового центра.
Семантика не разделена по гео и конструкциям
— Запросы «противопожарные двери с сертификатом», «офисные перегородки под заказ» и «двери в шоуруме» вели на одну страницу каталога и конкурировали между собой.
Организации не было на картах
— Карточка в Яндекс.Бизнесе не оформлена: ни часов работы, ни фотографий конструкций, ни маршрута до витрины в торговом центре, ни отзывов по объектам.
Учётная система шоурума: лиды и сделки, КП и спецификации, замеры на объекте, наряды монтажных бригад, закупка профиля под заказ, склад и резервы, документы и финансы по объектам. Обмен с 1С, банком и телефонией — в одном контуре.
Задача
Объекты жили вне учёта
— Сделка, спецификация, замер и монтаж велись в разных файлах и переписках. При передаче объекта другому менеджеру история терялась, а сроки никто не видел целиком.
Наряды монтажникам передавали голосом
— Бригада получала адрес и состав работ сообщением, и состав мог отличаться от спецификации. Переносы и незакрытые наряды всплывали только на сдаче объекта.
Профиль закупали под объект вслепую
— Комплектующие заказывали по памяти, без сверки со спецификацией и остатками склада. Часть позиций приезжала позже даты монтажа, и объект сдвигался.
Кабинет для подрядчиков, комплектаторов и частных клиентов: объекты и статусы, КП и спецификации с согласованием версий, документы и сертификаты, заявки на замер и монтаж, повторный заказ типовых конструкций и выгрузка спецификации для проектной документации.
Задача
Спецификации согласовывали по почте
— Каждая версия КП уходила вложением, правки возвращались в теле письма. К моменту монтажа никто точно не знал, какая версия утверждена заказчиком.
Документы запрашивали у менеджера
— Счёт, УПД, акт, паспорта и сертификаты на конструкции каждый раз запрашивали письмом. Менеджер выгружал их вручную, и заказчик ждал до следующего рабочего дня.
Заявки на замер и монтаж терялись
— Вызов замерщика и дату монтажа согласовывали в переписке, переносы не фиксировались. На объекте выяснялось, что доступ или размеры проёмов изменились.
Сайт фабрики межкомнатных дверей построен вокруг подбора и спецификации: покупатель или дилер собирает комплект в конфигураторе, сразу видит цену и отправляет запрос КП, а цены и наличие приходят из 1С.
Задача
Комплект не собирался онлайн
— Полотно, коробку, наличники, доборы и фурнитуру считал менеджер. Покупатель видел цену только за полотно, остальное уточнял письмом.
Нестандартные размеры уходили в переписку
— Проёмы отличаются от типовых, а на сайте не было ни ввода размеров, ни проверки допустимых отклонений для выбранной модели.
Покрытия жили отдельно от моделей
— Эмаль, шпон и экошпон описывались в общих текстах, поэтому подбор шёл по фотографиям: цвет и фактуру уточняли по телефону.
Продвижение фабрики межкомнатных дверей: семантика по моделям и покрытиям, посадочные страницы коллекций, гео-страницы дилеров, Директ на модельные запросы и сквозная аналитика заявок с передачей партнёру.
Задача
Весь трафик шёл на главную
— Отдельных страниц под модели, покрытия и размеры не существовало: поисковик показывал сайт по общим запросам, а посетитель не находил нужную дверь.
Реклама работала по широким ключам
— Кампании собирались вокруг «купить двери в Москве», заявка стоила дорого, а доля нецелевых обращений росла с бюджетом.
Заявки не доходили до дилеров
— Лиды с сайта уходили на общий ящик: дилер узнавал о запросе в своём городе с задержкой или не узнавал вовсе.
ERP позаказного производства дверей: заказы дилеров и прямых клиентов, разбор спецификации и постановка в цех, план по участкам, нормы расхода материалов, себестоимость заказа, брак, склад и отгрузки в одном контуре.
Задача
Спецификации переписывали вручную
— Данные из письма переносили в таблицу, затем в наряд. Ошибка в размере или покрытии обнаруживалась уже на раскрое, когда материал был испорчен.
План участков не был виден
— Раскрой, покраска, сборка и упаковка планировались по опыту: загрузка цеха и реальные сроки прояснялись только в процессе работы.
Материалы закупали с запасом
— Расход эмали, плёнки, шпона и фурнитуры не фиксировался по заказу, поэтому склад пополняли «на глаз» и замораживали деньги в запасе.
Кабинет дилера заменил заказы письмом и Excel: персональный прайс, оформление заказа с конфигуратором, статусы производства по этапам, документы, рекламации, образцы и взаиморасчёты в одном месте.
Задача
Заказ собирался в таблице
— Дилер присылал файл с моделями и размерами, менеджер переносил его в учётную систему. Ошибки в размерах и покрытии всплывали уже в цеху.
Статус приходилось выяснять
— Понять, на каком этапе находится заказ, можно было только через звонок менеджеру, который шёл в цех или звонил мастеру участка.
Документы терялись в переписке
— Счета, спецификации и УПД лежали в разных письмах: бухгалтерия дилера собирала закрывающие документы вручную к концу месяца.
Сайт премиального бренда дверей, стеновых панелей и скрытых конструкций, который ведёт архитектора от визуала отделки до готовой спецификации и запроса КП. Каталог, подбор отделки, визуализация в сцене помещения и заявка на образцы работают в одном контуре.
Задача
Отделки невозможно было оценить онлайн
— Подборки жили в PDF-каталогах и на фотографиях с искажённым цветом. Архитекторы запрашивали образцы вслепую и часто получали не тот тон, который закладывали в интерьер.
Каталог не отвечал на проектные вопросы
— Модели лежали плоским списком без привязки к типу конструкции, коллекции и типу объекта. Подобрать решение под конкретный интерьер можно было только через менеджера и переписку.
Спецификация собиралась вручную
— Менеджер переносил позиции из переписки в Excel и считал размеры проёма, доборы и наличники руками. Ошибки в артикулах отделок всплывали уже на замере, когда заказ согласован.
Продвижение строится вокруг проектов, а не розничного потока: контент об интерьерах и отделках приводит архитекторов, партнёрская программа удерживает их в бренде, а аналитика считает стоимость проектной заявки на цикле сделки в шесть-девять месяцев.
Задача
Спрос собирали розничные запросы
— Семантика была построена вокруг «купить двери», хотя маржинальный клиент ищет отделку под интерьер и решение для конкретного объекта. Проектные кластеры не были собраны и не имели посадочных.
Реклама вела на главную
— Кампании не различали архитектора и частного покупателя, а объявления не показывали ни отделки, ни реализованные объекты. Бюджет тратился на широкий трафик без проектного намерения.
Сообщество дизайнеров не удерживалось
— Партнёрская программа существовала на словах: не было условий, личного кабинета и совместных публикаций. Архитектор возвращался к бренду только по личной памяти менеджера.
Учётная система для студии и производства: проектная сделка ведётся от замера до монтажа, спецификации собираются по помещениям, образцы отделок учитываются на выдаче и возврате, а маржа считается по каждому объекту. 1С, банк и телефония связаны с карточкой проекта.
Задача
Проектные сделки велись в таблицах
— Этапы проекта не были связаны между собой: КП, согласование отделок, замер и производство жили в отдельных файлах. Статус приходилось уточнять у менеджера, а сроки срывались без предупреждения.
Образцы отделок не учитывались
— Комплекты образцов выдавали под расписку в мессенджере и не отслеживали возврат. Часть библиотеки образцов терялась на объектах, а менеджеры не знали, что доступно для следующего проекта.
Замеры и монтаж шли в мессенджерах
— Наряды на замер и монтаж передавались в переписке, без ответственного, времени и подтверждения от бригады. Логистика на объект согласовывалась в последний день.
Кабинет, в котором архитектор ведёт свои объекты: помещения и спецификации, версии согласования, образцы отделок, сроки производства и поставки, документы и бонусы за проекты. Отдельный кабинет заказчика показывает ход работ на объекте без звонков менеджеру.
Задача
Согласование шло почтой и Excel
— Каждая правка отделки рождала новый файл с новым именем, и версии расходились между дизайнером, менеджером и цехом. На сверку редакций уходили дни, а часть правок терялась в переписке.
Статусы производства узнавали звонком
— Дата готовности и поставки на объект не были видны партнёру, поэтому вопросы по срокам забирали время менеджеров. Дизайнер не мог самостоятельно спланировать монтаж и другие работы на объекте.
Образцы заказывали перепиской
— Запрос на образцы отделок оформлялся сообщением без состава и адреса, а выданные ранее образцы не были видны. Часть библиотеки оставалась у дизайнеров неопределённо долго.
Собственный сайт агентства как продукт: 390+ маршрутов на Laravel 12, страницы описываются конфигурацией, а не копированием шаблонов, генераторы и калькуляторы собирают заявку, блог и документация работают как источник органического трафика. Релизный процесс и мониторинг держат скорость и не дают плодиться дублям.
Задача
Страницы собирали копированием
— Новая посадочная появлялась как копия соседнего шаблона: разметку, мета-теги и микроразметку правили руками. Через десяток страниц блоки расходились, а правку приходилось вносить в каждом файле отдельно.
Конфигурация расползлась по коду
— Заголовки, описания и состав блоков жили одновременно в контроллерах, шаблонах и конфиге. Проверить страницу целиком до публикации было нечем: часть метаданных задавалась в одном месте, часть — в другом.
Индексация забирала мусорные адреса
— Шаблонные комбинации фильтров и параметров порождали тысячи почти одинаковых URL. Canonical, правила обхода и приоритеты не были системными, поэтому краулинговый бюджет уходил на дубли вместо коммерческих страниц.
Спрос на услуги агентства разложен по услугам, отраслям и технологиям, под каждый интент закреплена своя посадочная, а контент-хаб и документация дают органический трафик. Директ работает на коммерческие кластеры, аналитика доводит заявку до сделки во внутренней CRM, поэтому каналы оцениваются по стоимости лида и выручке.
Задача
Спрос был размазан по десяткам интентов
— Коммерческие запросы, отраслевые и технологические смешивались в одной выдаче. Посетитель попадал на общую страницу услуг и не находил ни состава работ, ни сроков, ни примеров под свою задачу.
Контент не приносил трафик
— Блог велся нерегулярно: статьи выходили без привязки к кластерам, без перелинковки и без ответа на вопрос читателя. Органика давала около 12% обращений, остальное держалось на рекомендациях.
Платный трафик съедал бюджет
— Кампании в Директе собирались по общим ключам без минус-слов и без разделения брендового и небрендового спроса. Заявки приходили дорогими и часто нецелевыми: студенты, вакансии, закупки по 44-ФЗ.
Внутренняя система агентства: клиенты и контрагенты с реквизитами и счетами, воронка сделок, проекты, задачи и тикеты, коммерческие предложения из шаблонов, документы — счет, УПД, акт — с предзаполнением, реестры, роли сотрудников и дашборды по загрузке и деньгам.
Задача
Данные жили в таблицах и почте
— Карточки клиентов, реквизиты, договоры и переписка хранились в разных файлах у разных сотрудников. Чтобы собрать историю отношений, менеджер поднимал почту за год и уточнял детали у коллег.
КП собирали в редакторе
— Состав работ и цены копировали из прошлых предложений, поэтому версии расходились, а суммы и ставка налога пересчитывались вручную. Ошибку находили уже после отправки заказчику.
Документы оформляли отдельно
— Счет, УПД и акт печатали в сторонней программе и переносили реквизиты копированием. Закрывающие документы уходили с задержкой, а сверка расчётов занимала неделю в конце квартала.
Закрытая часть платформы, где клиент агентства видит ход работ и документы без переписки: этапы проекта, задачи и правки, версии коммерческого предложения, счета, УПД и акты, обращения в поддержку. Роли сотрудников клиента, уведомления и двухфакторный вход закрывают доступ и снимают рутину с менеджеров.
Задача
Статус проекта узнавали письмом
— Клиент писал менеджеру, менеджер собирал сведения по команде и отвечал через день. Простого вопроса «на каком этапе задача» хватало, чтобы остановить работу двух человек.
Согласования терялись в переписке
— Замечания по предложению и макетам приходили в почту и мессенджеры вперемешку с другими темами. Версии путались, часть правок не доходила до команды, а спорные пункты всплывали на сдаче этапа.
Документы отправляли вложениями
— Счет, УПД и акт уходили письмом на разные адреса, бухгалтерия клиента запрашивала их повторно, а закрывающие документы накапливались к концу квартала.
Платформа, на которой салоны, дилеры и фабрики публикуют предложения по дверям, а покупатель сравнивает их по параметрам, цене, сроку поставки и городу. Сделка закрывается у продавца, площадка продаёт лиды и видимость: 120 000 предложений и 9 400 заявок в месяц.
Задача
Одну карточку заводил один человек
— Каждую позицию контент-менеджер переносил из письма вручную. Продавцы не могли сами обновить цену и срок, поэтому половина карточек устаревала за месяц.
Предложения нельзя было сравнить
— У одного продавца цена стояла за полотно, у другого за комплект, у третьего срок указывался без привязки к городу. Покупатель сравнивал несопоставимые данные и уходил звонить продавцу напрямую.
Заявки распределялись по памяти
— Менеджер выбирал продавца в таблице и пересылал заявку письмом. Часть обращений терялась, ответ приходил через часы, а конфликты «почему лид ушёл не мне» разбирались в переписке.
Продвижение площадки на параметрических запросах: «двери 80 см эмаль Москва», «входные двери с установкой СПб». Собрали семантику по параметрам и городам, вывели в индекс 2 300 страниц сравнений и подборок и связали каждый визит с переданным продавцу лидом.
Задача
Спрос жил в параметрах, а не в категориях
— Покупатели искали «двери 80 см эмаль Москва» и «входные двери с установкой СПб», а площадка предлагала две общие категории. Часть таких запросов отдавалась конкурентам и агрегаторам объявлений.
Автогенерация плодила дубли
— Фильтры каталога открывали любые комбинации параметров, включая пустые. Заголовки страниц совпадали, canonical и пагинация были настроены неверно, и поисковая система теряла приоритетные страницы.
Гео в семантике не разделялось
— Москва, Санкт-Петербург и города присутствия шли одним кластером: покупатель из СПб видел предложения салонов из другого города и уходил из выдачи.
Операционная система площадки: тарифы и лимиты лидов, счета и закрывающие документы, модерация ассортимента, маршрутизация заявок с таймером ответа, реестр споров и дашборды по выручке. Один контур вместо таблиц, писем и ручных расчётов.
Задача
Тарифы и лимиты считали в таблицах
— Подписки и остатки лимитов велись в Google-таблицах. Продавец иногда получал заявки сверх оплаченного пакета, а счёт выставлялся с задержкой в две недели.
Распределение заявок было непрозрачным
— Менеджер выбирал продавца по памяти и переписке. Новые салоны почти не получали лидов, сильные забирали больше, а претензии разбирались без данных о передаче.
Качество ответа продавцов не измерялось
— Площадка не знала, за сколько продавец отвечает на заявку и какую долю принимает. Обосновать стоимость подписки или понизить тариф нерадивому продавцу было нечем.
Кабинет продавца, в котором салон сам ведёт ассортимент и прайс, следит за лимитом лидов, отвечает по заявкам и видит окупаемость подписки по городам и категориям. Кабинет покупателя хранит избранное, сравнения и историю заявок между устройствами.
Задача
Продавец зависел от поддержки площадки
— Любая правка цены, срока или города шла письмом: ожидание до двух дней. Пока менеджер обновлял прайс, продавец терял показы по актуальным позициям.
Окупаемость подписки была непонятна
— Отчёт по лидам приходил раз в месяц в Excel, без разбивки по городам и категориям. Продавец не понимал, какие предложения приносят заявки, а какие только расходуют лимит.
Покупатель терял свои подборки
— Избранное и сравнение жили в браузере: на другом устройстве подборка исчезала, а отправленная заявка не связывалась с историей и статусом ответа продавца.
Продвижение площадки сразу на двух сторонах: покупателей приводим из поиска и товарных кампаний, производителей — через B2B-лендинги, расчёт выгоды и партнёрскую программу. Удержание продавцов держится на отчётности, обучении и управлении репутацией.
Задача
Спрос уходил к конкурентам
— Каталог не индексировался по типам дверей, брендам и городам, поэтому поисковый трафик забирали агрегаторы и собственные магазины продавцов.
Продавцов искали обзвоном
— Менеджеры собирали базу производителей вручную: не было лендинга с понятной выгодой и расчётом дохода от площадки.
Продавцы уходили после старта
— В первые три месяца продавец не видел отчётов и не понимал, какие карточки работают, поэтому сворачивал ассортимент.
Учётная система площадки: продавцы и договоры, комиссии и выплаты, реестры заказов, финансы и сверки, модерация, споры, логистика и поддержка. Данные сходятся с 1С продавцов, платёжным провайдером, службами доставки и банком.
Задача
Продавцы и договоры в таблицах
— Реквизиты, тарифы и лимиты хранились у менеджеров, поэтому условия комиссии у двух похожих продавцов могли отличаться без всякой причины.
Выплаты считали вручную
— Реестр начислений и удержаний собирали из выгрузок заказов: на сверку уходило до пяти дней, а продавец ждал деньги без объяснения суммы.
Споры не имели регламента
— Жалобы покупателей и конфликты с продавцами разбирались в почте: сроки не фиксировались, история решения нигде не сохранялась.
Кабинет продавца, где ассортимент, цены, заказы, выплаты и аналитика продаж ведутся без менеджера площадки, и кабинет покупателя, где виден весь заказ от нескольких продавцов. Оба кабинета работают в одном контуре с поддержкой и уведомлениями.
Задача
Продавец зависел от менеджера
— Правка цены, снятие товара с продажи и загрузка прайса шли через письмо: ответ ждали сутки, а позиция всё это время продавалась по старой цене.
Покупатель не видел заказ целиком
— При покупке у трёх продавцов приходило три письма с разными статусами, и понять, что уже едет, а что нет, было невозможно.
Поддержка отвечала на одно и то же
— Больше половины обращений — «где заказ», «когда выплата», «как поменять цену»: ответы не были собраны в одном месте для самостоятельного поиска.
Мы документируем проекты по одной схеме — так кейс можно сравнить с вашей задачей.
Задача и контекст
С чем пришёл клиент, что мешало работать и какие ограничения были по срокам, бюджету и системам.
Решение и модули
Что именно спроектировали и внедрили: каталог, расчёты, личный кабинет, интеграции, админ-панель.
Стек с ролями
Какие технологии использовали и какую задачу решает каждая — без «стека ради стека».
Интеграции
С чем связали систему: 1С, CRM, платежи, склад, маркетплейсы, службы доставки.
Состав работ и сроки
Этапы проекта и что передаём клиенту: код, документация, доступы, обучение команды.
Результат
Как изменились процессы и показатели после запуска — там, где клиент подтвердил цифры.
Направления и стек
Проекты в портфолио сгруппированы по направлениям разработки. Если вашего
случая в списке нет — это не значит, что мы его не делали: часть работ
не публикуется по NDA.
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie
(Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия —
от него можно отказаться. Подробнее:
Политика использования cookie
и
обработка персональных данных.
Настройки cookie
Выберите, какие категории cookie можно использовать. Необходимые отключить нельзя:
без них не работают формы и сессия.