Три центра управления цветочным бизнесом
Первый центр управления — заказ в торговой точке: разные каналы продаж сходятся в едином списке, а доставка и отчётность продолжают его исполнение. Для магазина с потоком небольших заказов важны скорость приёма и единая очередь работ.
Второй центр управления — операционная очередь с назначением флористов, контролем скоропортящегося запаса и задачами курьера. Здесь нужны явные границы ответственности: кто принял заказ, кто собрал, кто передал и чем подтверждено вручение. На праздничные даты следует отдельно определить лимиты приёма.
Третий центр управления — рецепт композиции, потребность мероприятия, смета и закупка. Потребность нужно сопоставлять с доступным ассортиментом поставщиков; предварительное бронирование, подтверждение и ожидание одобрения должны различаться. Доступность канала снабжения, географию поставки и сроки проверяют для конкретного магазина.
Кассовая продажа, операционное исполнение и проектная флористика требуют разных маршрутов работы. При проектировании Адаптум важно выбрать подход под структуру выручки магазина, а затем соединить процессы общими данными. Попытка обслуживать свадебный проект и покупку готового букета через совершенно одинаковую карточку создаёт лишние поля в одном случае и недостаток контроля в другом.
Четыре модели цветочного бизнеса
Розница у прилавка. Клиент выбирает готовый букет или просит собрать его сразу. Критичны фактическое наличие, время ожидания и правильное списание состава. Анонимная продажа допустима в модели данных: сотрудник не должен создавать фиктивного клиента ради закрытия чека. Если покупатель добровольно оставляет контакт для будущих заказов, продажа связывается с ним с учётом цели использования контакта. Для готовых букетов требуется учёт произведённых экземпляров: их компоненты уже израсходованы, повторно списывать стебли при продаже нельзя.
Интернет-магазин и доставка. Карточка на сайте обещает определённый внешний вид, размер и дату. Поэтому фиксируются версия предложения, выбранные параметры и допустимые замены. Доступность оценивается одновременно по цветам, производственным минутам, району и курьерскому интервалу. Оплата заказа на сайте не доказывает, что склад подтвердил резерв. При конфликте менеджер получает исключение с конкретным сроком реакции. Заказы площадок хранят внешний номер, комиссию, источник и правила расчётов; их нельзя считать столь же доходными, как прямые заказы с одинаковой ценой.
Регулярные корпоративные поставки. Бизнес покупает предсказуемый сервис для офиса, ресторана или сети точек. Здесь важны график, доступ в помещение, контакт на каждой площадке, смена композиций и единый расчётный период. При использовании многоразовых ваз появляется оборотная тара: что передано, что должно вернуться, что повреждено. Контроль договора дополняется контролем каждого исполнения; пропущенный визит не исчезает за успешно выставленным месячным счётом.
Мероприятия и оформление. Продажа начинается с консультации, концепции и нескольких версий сметы. За проектом закрепляются дата мероприятия, площадка, зоны оформления, позиции композиций, этапы оплаты, доступ на монтаж и время демонтажа. Согласованная версия проекта определяет закупочную потребность. Изменение числа столов после её утверждения оформляется изменением объёма с новой стоимостью и сроком решения. Кроме флористов учитываются монтажники, транспорт, арендуемые конструкции и возврат инвентаря. Проект завершается после демонтажа, возврата имущества и расчётов, а не после доставки первых цветов.
Общими остаются контакты, материалы, платежи и история согласований. Различаться должны маршруты выполнения: короткий для готового букета, полноценный доставочный для онлайн-заказа и проектный для мероприятия. На праздники отдельно ограничивают приём по датам и интервалам, фиксируют время закрытия заказа и доступное меню. Это управленческие решения, которые система должна поддерживать явно.
Покупатель и получатель в разных ролях
Один покупатель может отправлять цветы нескольким людям. Один человек может получать подарки от разных покупателей. Если поместить всех в одну карточку с полем «телефон клиента», магазин рано или поздно перепутает адресата сообщения или историю заказов.
В проектируемой модели «Заказ» содержит отдельные связи с покупателем, плательщиком и получателем. Физическое лицо может исполнять несколько ролей, но назначение каждой связи остаётся явным. Для корпоративного покупателя добавляются организация, контакт заказчика и контакт по расчётам. Получателя не следует автоматически включать в клиентскую рассылку.
К заказу привязаны позиции, согласованная версия состава, производственное задание, одна или несколько доставок, платежи, возвраты и обращения. Для доставки хранится снимок адреса: последующее изменение контактной карточки не должно переписать место уже состоявшегося вручения. Аналогично фиксируются текст открытки, имя отправителя для показа получателю и правила сохранения сюрприза.
«Повод» заслуживает отдельной записи: тип события, день и месяц, необходимость повторения, покупатель, связанный получатель и источник сведений. Год рождения не нужен, если достаточно напоминания о дате. Запись о коммуникациях отдельно хранит адресата, канал, назначение, основание использования контакта, дату разрешения и отказ от рассылки. Конкретные требования к обработке данных проверяют для юрисдикции магазина; сама архитектура должна позволять ограничивать доступ, сроки хранения и удаление.
Менеджеру доступны условия заказа и общение с покупателем. Флористу нужны состав, изображение, ограничения и открытка. Курьеру выдаются сведения текущей доставки, а не вся история покупок. Фотоподтверждение по возможности показывает букет и место передачи без лишних персональных подробностей. Правила доступа и хранения фотографий устанавливаются до запуска.
Один заказ от заявки до закрытия
Представим учебный пример. Ирина заказывает матери букет на субботу, доставка с 10:00 до 12:00. Бюджет согласован, белые лилии исключены по пожеланию покупателя, отправителя до вручения раскрывать нельзя. Это условия примера, а не история внедрения.
На этапе «Уточнение» менеджер проверяет дату, часовой пояс, адрес, интервал, контакты покупателя и получателя, открытку и возможность связаться с получателем. Заказ нельзя перевести в «Подтверждён», пока не согласованы цена, состав либо допустимый диапазон дизайнерской сборки, политика замен и способ оплаты. Отдельно проверяется вместимость выбранного интервала по производству и доставке.
После подтверждения возникает резерв материалов. В «К сборке» заказ проходит только при наличии действующего резерва, назначенного флориста и выполненного условия оплаты. Для розницы это может быть полученная предоплата; для утверждённого корпоративного договора применяется согласованная отсрочка. Скриншот оплаты не подменяет подтверждение платёжной системы.
В пятницу выясняется, что часть зарезервированных роз не прошла проверку качества. Ответственный фиксирует списание и нехватку, менеджер получает задачу согласовать замену. Он предлагает Ирине другой сорт с фотографией, изменением состава и, если требуется, новой ценой. В заказе сохраняются исходная версия, предложение, ответ покупателя, время и автор изменения. Пока разрешение не получено, спорная сборка заблокирована. Даже при заранее разрешённых заменах нужно проверить их пределы: цвет, вид, количество и бюджет.
Флорист собирает утверждённый вариант, отмечает фактический расход и завершает задание. Перед статусом «Готов» ответственный проверяет внешний вид, открытку, комплектацию и упаковку. Фото готового букета связано с заказом, но отправляется покупателю только по принятому правилу коммуникации.
Диспетчер допускает заказ к выдаче после проверки адреса, курьера и интервала. «Передан курьеру» содержит время и идентификатор доставки. «Вручён» требует результата передачи: времени, способа подтверждения и получателя в допустимом объёме данных. Если дверь не открыли, создаётся попытка доставки с причиной и следующим действием. Самовольная передача соседу не становится успешным вручением.
Наконец, «Закрыт» означает, что исполнение подтверждено и финансовое состояние согласовано с правилами магазина. Незавершённая претензия остаётся отдельной видимой записью. Статусы оплаты, изготовления, доставки и обращения ведутся раздельно: оплаченный заказ ещё не обязательно собран, а вручённый может потребовать частичного возврата.
Стебель и партия как основа доступности
Каталожная позиция «букет пастельный» удобна покупателю, но для производства нужна рецептура: какие цветы, сколько стеблей, какая зелень, упаковка, лента и дополнительные материалы. Версия рецепта связывается с позицией заказа, чтобы изменение каталога не меняло прошлые обязательства.
Рецепт связывается с ингредиентами и количеством стеблей; стоимость ингредиента может отличаться для конкретного события. Поэтому стандартный рецепт и расчёт определённого заказа следует хранить раздельно, сохраняя согласованную версию.
Складской контур должен различать номенклатуру и партию поставки. Для партии важны поставщик, дата поступления, закупочная стоимость, место хранения, фактическое состояние и рекомендуемый срок использования. Остаток в холодильнике не равен доступному остатку: часть уже зарезервирована, часть находится на контроле качества.
Для заданного магазина доступность рассчитывается как пригодный физический остаток минус действующие резервы. Ожидаемую поставку показывают отдельно с датой и надёжностью подтверждения. Она не становится полученными цветами до приёмки. Подбор партий можно строить по ближайшему допустимому сроку использования, но качество проверяет сотрудник: расчётная дата не гарантирует свежесть.
Списание оформляется событием с партией, количеством, причиной и ответственным. Причины стоит разделить: брак поставки, потеря качества при хранении, повреждение при сборке, пересорт. Перемещение между магазинами и расход на букет имеют другие типы движений. Иначе отчёт о потерях будет смешивать порчу и нормальное производство.
Стеблевой учёт, предупреждения о сроках и недостатке запасов, а также закупочная потребность из будущих заказов полезны в этой модели. Их техническую реализацию нужно отдельно спроектировать и проверить: описание не подтверждает наличие готовых функций в Адаптум.
Как потребность превращается в закупку
Закупщик получает потребность по утверждённым заказам и отдельно прогноз для свободной продажи. Рецептуры дают количество стеблей; закупочные единицы могут быть пачками или коробками. Поэтому расчёт заказа поставщику учитывает кратность упаковки, пригодный остаток, резервы, подтверждённые поступления и утверждённый запас. Необязательные предложения клиентам показываются отдельным сценарием, чтобы их не закупили как уже проданные букеты.
Заявка поставщику проходит состояния «Подготовлена», «Отправлена», «Подтверждена», «Частично получена» и «Закрыта» с причинами расхождений. Дата прибытия привязана к времени подготовки цветов и изготовления заказа. Приёмщик сверяет количество, сорт, качество и цену; недостача или брак создают претензию поставщику и пересчёт доступности. Ожидаемая компенсация поставщика не подменяет фактически полученные деньги или заменённый товар.
Если поставка не состоялась, система должна показать затронутые заказы и крайнее время решения. Закупщик ищет альтернативу, флорист проверяет художественную и технологическую пригодность, менеджер согласует изменение обещания покупателю. Такой разбор сохраняет ответственность: нехватка не растворяется в свободном комментарии «заменили цветы».
Себестоимость и деньги после вручения
Плановая прямая себестоимость заказа включает цветы по рецепту, упаковку, нормативное время сборки по внутренней ставке, закупаемые дополнения и переменные затраты доставки. Фактическая версия использует реальный расход партий и время. Руководитель заранее определяет, какие расходы входят в эту модель, чтобы упаковка или работа не учитывались дважды.
Наценка на цветы не равна марже заказа. Срочный выезд за материалом, комиссия платёжного сервиса и повторная доставка могут изменить результат. Общемагазинные списания лучше показывать отдельной строкой периода; распределять их по заказам можно только по явно принятой методике. Для контроля плановых и фактических затрат сопоставляют необходимое количество, заказанное количество и закупочную стоимость.
Платёж хранится отдельной записью с суммой, валютой, статусом и внешним идентификатором. Возврат связан с исходным платежом и причиной; запрос возврата и подтверждённый возврат имеют разные состояния. При частичной компенсации заказ не должен превращаться в полностью отменённый. Реквизиты банковской карты в CRM не копируют: расчёт выполняет платёжный провайдер.
Для корпоративного обслуживания нужен «Регулярный договор»: компания, точки доставки, периодичность, бюджет, согласующие лица, срок изменения заявки и условия расчётов. Из него формируются отдельные заказы на конкретные даты. Перенос одной доставки не меняет весь график, приостановка договора останавливает новые задания, а задолженность проверяется перед следующим запуском по согласованному лимиту. Акты и счета остаются связанными с исполнениями, а не только с общей карточкой организации.
Восемь показателей для директора
Панель руководителя должна объяснять, где теряются заказы, время и деньги. Для каждого показателя фиксируются источник, момент включения в выборку и обработка отмен. Ниже предложены определения для пилота; сравнивать магазины можно после выравнивания методики.
- Конверсия обращения в заказ. Число квалифицированных обращений, поступивших за неделю и получивших подтверждённый заказ в течение семи дней, делится на число квалифицированных обращений той же недели. Дубликаты и спам исключаются по единому правилу. Показываются только когорты с завершившимся семидневным окном.
- Вручение в обещанный интервал. Доставки, вручённые внутри согласованного интервала, делятся на все доставки с плановым вручением за неделю, кроме отменённых до принятого срока отсечения. Невручённые остаются в знаменателе; изменения обещанного интервала сохраняются в истории.
- Сборка вовремя. Производственные задания, готовые не позже планового времени выдачи, делятся на все задания со сроком готовности за неделю, кроме своевременно отменённых. Опоздания видны независимо от того, успел ли курьер компенсировать задержку.
- Доля заказов с заменой. Неотменённые заказы с датой исполнения в месяце, в которых после подтверждения менялся согласованный состав, делятся на все неотменённые заказы той же когорты. Отдельно показывается количество несогласованных изменений; цель контроля для них нулевая.
- Доля складских потерь. Себестоимость списанных из-за порчи или повреждения материалов за месяц делится на стоимость начального запаса плюс поступления за тот же месяц. Внутрисетевые перемещения исключаются из сводного знаменателя. Разрез по партии помогает находить источник потерь.
- Прямая маржа исполненных заказов. (Выручка после скидок и возвратов − определённые выше прямые затраты) / та же выручка × 100%. Выручка и затраты относятся к одной когорте заказов, исполненных за месяц. Выручка и затраты используются без возмещаемых налогов; поздние возвраты корректируют отчёт исходной когорты. При нулевой выручке процент не рассчитывается.
- Доля заказов с возвратом. Исполненные в месяце заказы с подтверждённым денежным возвратом в течение 30 дней делятся на все исполненные заказы этого месяца. Незрелая когорта помечается предварительной; суммы возвратов показываются рядом.
- Повторная покупка за 90 дней. Покупатели, совершившие второй оплаченный и исполненный заказ в течение 90 дней после первого, делятся на покупателей с первым таким заказом в выбранном месяце. Расчёт выполняется после полного окна наблюдения и использует покупателя, а не получателя.
Шесть задач для ИИ внутри процесса
ИИ полезен там, где превращает данные в проверяемый проект действия. Для конфигурации Адаптум можно предусмотреть следующие сценарии, проверив техническую доступность каждого на пилоте.
Разбор заявки. Из обращения ИИ предлагает значения полей: дата, интервал, бюджет, адрес, покупатель, получатель и ограничения. Неясное «в следующую пятницу» остаётся вопросом менеджеру; запись не подтверждается автоматически.
Изменение структуры и создание связей. Владелец формулирует задачу: «Добавь в заказ поле “Замена согласована”, сделай его обязательным при переходе к сборке, если состав изменился, и создай связанную сущность “Согласование замены”». Помощник сначала предлагает план: типы полей, связи, условие перехода, права и обработку существующих заказов. Проверяет, нет ли эквивалентных полей, показывает записи без необходимых сведений и не присваивает им согласие задним числом. После утверждения администратором изменение проверяют на тестовых случаях и только затем применяют к рабочим данным, если конкретная поставка поддерживает такое управление схемой. В повседневной работе ИИ также может готовить связанные записи заказа и повода с проверкой дубликатов; создание карточки получателя не означает разрешения на рекламу.
Варианты состава с учётом склада. Помощник предлагает несколько рецептур в бюджете, используя только актуальные пригодные остатки за вычетом резервов. Он показывает расход, партии, расчётную себестоимость и нарушения ограничений. Финальное решение принимает флорист; замену покупателю согласуют отдельно.
Объяснение отклонений. По запросу директора ИИ собирает отчёт, например о падении прямой маржи за неделю, с фильтрами, формулой, числом заказов и ссылками на исходные записи. Он различает обнаруженную связь и доказанную причину.
Контроль риска исполнения. Помощник находит заказы без резерва, подтверждённой оплаты или курьера перед сроком выдачи и готовит приоритетный список для ответственного. Риск опоздания служит сигналом проверить заказ, а не основанием самостоятельно менять обещанное время.
Подготовка повторного предложения. К разрешённому напоминанию о поводе ИИ готовит черновик с учётом прежних пожеланий и доступного ассортимента. Правило проверяет адресата, канал, разрешение и частоту. Без утверждённых правил сообщение не отправляется, а неактуальная дата не превращается в новую продажу автоматически.
Общий принцип: ИИ не должен самовольно заменять цветы, изменять цену, выдавать возврат или рассылать сообщения. Доступ к данным ограничивается ролью, предложения сохраняются с источниками, значимые изменения проходят установленное согласование. Чувствительные подробности не нужны помощнику там, где достаточно производственного ограничения.
Граница CRM и операционных систем
В предлагаемой архитектуре Адаптум объединяет отношения, обязательства, согласования, задачи и контроль исполнения. POS отвечает за продажу на кассе и применимые кассовые документы, складская система за партии и движения, бухгалтерская за расчёты и регламентированный учёт, служба доставки за маршрут и события курьера. При небольшом масштабе часть функций может находиться в одной системе, но источник истины для каждого вида данных всё равно назначается один.
При интеграции нужны внешние идентификаторы, защита от повторной обработки событий и очередь ошибок. Повторное уведомление об оплате не создаёт второй платёж. Потеря связи со складом делает остаток неподтверждённым и запускает проверку, а не разрешает продажу последнего стебля двум покупателям. Ежедневная сверка выявляет расхождения по оплатам, резервам и доставкам.
Начинать разумно с одного магазина и полного пути заказа: обычное вручение, нехватка цветов, отказ от замены, частичный возврат, неудачная доставка и корпоративный перенос. Условия приёмки задаются заранее: корректные связи, отсутствие двойного резерва, подтверждаемые переходы статусов и сходящиеся расчёты.
Такой пилот даёт руководителю основание решить, что автоматизировать дальше. Ценность настройки проверяется по качеству исполнения и достоверности данных; обещать проценты роста выручки до измерений было бы преждевременно.