Кейс: от сервисной боли к продукту

Этот текст — единственный публичный кейс происхождения МарджинЛейэр: как ООО «Битапл» (Betuple) пришло к продукту из повторяющегося разрыва между поставкой и финансами на клиентских договорах. Не портфель внедрений и не набор выдуманных заказчиков. Цифры ниже — иллюстративные ориентиры пилота, анонимизированы, не гарантия и не «рост маржи сам по себе».

Для кого: владелец, руководитель поставки и финансы, которым на этапе проверки важно понять происхождение решения.
Когда читать: проверки перед пилотом, не как замена вашим 2–3 договорам.
Что получите: боль, роли, экраны кабинета, как считали ориентиры, чем продукт не является.
Следующий шаг: запросить 20-минутный разбор и план пилота.

МарджинЛейэр — слой принятия коммерческих решений до выставления счёта клиенту. Не замена трекера, не замена учёта, не система учёта проектов, не юридический счёт, акт или УПД. Позиционирование компании: ООО «Битапл» и МарджинЛейэр.

Почему возник разрыв

В сервисной работе ООО «Битапл» команда делала объём, часы были в трекере, а коммерческое «что можно выставить на этой неделе» собирали вручную. База объёма жила в договорах и письмах. Изменения объёма не проходили единый трассируемый путь до вехи. Финансы видели риск у границы счёта, когда пространство для решения уже узкое.

Это не история «внедрили систему — маржа выросла». Это история повторяющегося операционного разрыва: поставка и финансы смотрели на разные факты в разные дни. Продукт вырос из требования собрать владельца, руководителя поставки и финансы в одном еженедельном контуре.

Повторяющийся паттерн (клиентский счёт, не подрядчик)

Контур этой истории — исходящий счёт клиенту. Приложения и акты исполнителю в кабинете закрывают другой поток; в этой истории они не были ядром боли.

Продуктовый ответ: механизм, не лозунг

Механизм: договор → факт часов → изменение объёма в деньгах → готовность к счёту. Из трекера видно, можно ли выставлять счёт на этой неделе — без переноса задач в другую систему. Кабинет собирает пакет: веха биллинга, операционные файлы счёта и акта, статус оплаты, при необходимости выгрузка в Контур.Эльбу. Юридическое закрытие — в учёте.

Экран Какую дыру закрывал в той практике
Ведомости работ Одна утверждённая база вместо «версии в почте»
Запросы на изменения Денежный статус до вехи, не после счёта
Дашборд Расход часов и риск на неделе; не полный ОПиУ
Экономика контракта Валовая маржа договора; может расходиться с риском дашборда, пока не выровняли затраты
Биллинг Пакет клиенту; операционный акт ≠ УПД
Паспорт показателей пилота Пороги запуска и отказа до старта, не «понравилось демо»

У финансов нет меню «Проекты» — так устроен кабинет: биллинг, отчёты, дашборд одного проекта. Роль «клиент» — клин входа заказчика, не ядро этой истории происхождения.

Роли, как они стояли в контуре

Без именованного владельца процесса сводки остались бы витриной. Это ограничение честно повторяем заказчикам пилота.

Иллюстративные ориентиры, не отчёт портфеля

На периметре нескольких договоров в пилотном контуре (анонимизировано): доля оспариваемых строк исходящего пакета — ориентир примерно с 18% до 9% за шесть недель; медианное время от статуса «можно выставлять» до отправки пакета — короче примерно на 25%. Это не несколько разных внедрений, не обещание вашему портфелю и не эффект «сам по себе».

Если вход часов мусорный (списания без проекта и типа задачи), картина будет красивой и неверной — тот же риск, о котором говорим в каноне. Jira и ряд трекеров в первой версии дают вход факта один раз на ключ; Яндекс Трекер очередь повторяет. Практика не строилась на мифе еженедельной повторной синхронизации Jira.

Ранние сигналы: маржа до счёта. Готовность пакета: готовность к счёту.

Какие выводы из этой истории лучше не делать

Как эта история связана с вашим пилотом

Эта история объясняет, почему слой появился. Ваш пилот — 4–6 недель, 2–3 живых клиентских договора, критерии в паспорте до старта. Типичные имена показателей: спорные позиции к счёту клиенту; время до статуса «можно выставлять»; доля изменений объёма с денежным статусом. Подробная рамка: критерии пилота. Защита бюджета внутри компании: согласование запуска или отказа.

Сценарий заказной разработки, близкий по боли: заказная разработка и готовность к счёту.

Семь дней, если узнали свою боль

  1. Сверить по 2–3 договорам: база ведомости, факт часов, открытые изменения без статуса.
  2. Назначить владельца, поставку и финансы на один слот.
  3. Записать 3 показателя и пороги до любой настройки интеграций.

Частые вопросы

Есть ли другие публичные клиентские кейсы?

Нет. Публичный кейс происхождения один: ООО «Битапл». Не выдумываем портфель внедрений.

Можно ли считать 18% и 9% вашей гарантией?

Нельзя. Это иллюстративный ориентир пилота на периметре нескольких договоров, анонимизировано.

Продукт заменил трекер в Битапл?

Нет. Задачи остались в трекере. Слой — коммерческие решения до счёта.

Это история про оплату подрядчиков?

Нет. История про исходящий пакет клиенту. Контроль актов исполнителю — отдельный кластер кабинета и сайта.

Где юридические реквизиты оператора?

О компании: ООО «Битапл». Карточка: betuple.ru.

См. также

Следующий шаг

Эта страница не заменяет пилот на ваших договорах. После разбора обычно: черновик паспорта показателей, список источников данных, план на 14 дней. Решение о масштабировании — по вашим порогам, не по этой странице.