Данные о потенциальном участнике и билете поступают в систему из внешней базы данных или в виде электронного сообщения с сайта.
Система автоматически проверяет правильность заполнения данных:
Формат заполнения email;
Корректность телефонного номера и т.д.
Если данные заполнены корректно, запрос отправляется в обработку. Иначе игнорируется как ошибочный.
Автоматическая проверка на наличие лида или контакта в системе по параметрам: email, телефон, ФИО.
Если лид в системе уже имеется, запрос прикрепляется к нему и автоматически формируется билет.
Если лид не найден, создается карточка лида. На ее основе формируется билет.
Производится проверка наличия оплаты за билет.
Если оплата выполнена:
Клиент оповещается об оплате;
Проверяется наличие клиента в базе данных;
Если клиент новый, создается карточка клиента и на ее основе карточка участника.
На основе данных из карточки участника формируется билет и отправляется покупателю.
Если оплата не выполнена:
Система ожидает оплату 1 день (срок можно изменить в случае необходимости);
Производится проверка срока оплаты:
Если стоимость билетов осталась неизменной, покупателю отправляется напоминание об оплате.
Если срок вышел и стоимость билета изменилась, билет аннулируется, бронь снимается, участник оповещается о снятии брони.
Цена билетов растет по мере приближения мероприятия. В случае аннуляции неоплаченного билета из-за изменения цены покупатель может заново создать запрос и забронировать билет по обновленной цене.
Цикл «проверка оплаты – напоминание об оплате» повторяется вплоть до изменения цены и аннуляции билета или получения оплаты. В последнем случае выполняются действия из пункта «Оплата выполнена», т.е. формируется карточка клиента, участника, создается и отправляется покупателю билет.
Основное отличие продажи билетов B2B от предыдущего процесса заключается в том, что покупатель не предоставляет личных данных каждого участника.
Информация при закупке билетов от организации:
Количество билетов;
Мероприятие;
Контактное лицо;
Организация-покупатель.
Если при продаже B2C покупатель является участником мероприятия, то при продажах B2B покупатель (представитель компании) и участники (для кого покупают билеты) не совпадают, покупатель в данном случае может одним из списка.
После того, как в систему поступает заявка на участие от юридического лица, покупателю отправляется запрос на количество билетов.
Реализуется это действие при помощи автоматической отправки анкеты, где покупатель заполняет количество билетов, тариф, по которым он планирует их приобрести, реквизиты для выставления счета и другие данные, необходимые для обеспечения участия представителей компании в мероприятии.
После получения анкеты правильность данных проверяется. В случае выявления ошибок запрос анкетных данных повторяется либо выполняются уточнения любым другим удобным способом, например, в телефонном режиме.
На основе предоставленных данных формируется счет на оплату и отправляется клиенту.
Перед проверкой оплаты необходимо проверить условия оплаты, согласованные с клиентом. Это может быть 100% предоплата, частичная предоплата и т.д.
Если по условиям договора возможно формирование билетов до получения оплаты, они формируются согласно анкете и отправляются клиенту.
Если для формирования билетов необходимо получить предоплату, действия производятся аналогично работе с B2C:
Система ожидает оплату 1 день (срок можно изменить в случае необходимости);
Производится проверка срока оплаты:
Если стоимость билетов осталась неизменной, покупателю отправляется напоминание об оплате.
Если срок вышел и стоимость билетов изменилась, стоимость билетов обновляется, покупатель получает новый счет.
В случае согласия клиента на новую цену билетов, повторяется ожидание и проверка оплаты. При несогласии бронь аннулируется.
Бизнес-процесс продажи завершен.
Покупатель билетов B2B регистрируется в системе в качестве клиента. Лид – это потенциальный покупатель, с которым планируются переговоры. В случае запроса на покупку билетов – это уже клиент, и работа с ним ведется в рамках Сделки.
Для автоматизации продажи билетов необходима система «Продажа билетов», которая будет работать следующим образом:
Покупатель отправляет запрос, который автоматически направляется в систему.
Информация об участниках и мероприятиях добавляется автоматически с сайта конференций.
Данные о покупателях должны храниться в справочнике Покупатели
Данные об участниках – в справочнике Участники.
Система учета продажи билетов необходима для хранения данных о покупках и мероприятиях, а также формирования отчетности по проведенным мероприятиям, покупателям и участникам.
Покупатели – лица (организации), которые оплачивают билеты.
Участники – лица, которые примут участие в мероприятии (на них оформляются билеты).
Мероприятия – конференции, организованные компанией Java User Group.
При этом покупатель и участник могут быть одним и тем же лицом или разными. В качестве покупателя может выступать физическое лицо или организация. Участник – это всегда человек, который принимает участие в мероприятии по заказанному билету.
Ниже описан бизнес-процесс работы отдела маркетинга с учетом возможностей автоматизации.
Процесс начинается с того, что маркетолог создает новый бриф. В результате формируется документ «Бриф», который должен быть загружен в базу данных системы.
В финале этого шага маркетолог отправляет документ Бриф руководству.
Руководитель изучает бриф, после чего возможны два варианта развития событий:
В брифе выявлены недочеты. Руководитель пишет замечания к брифу и отправляет маркетологу. Далее маркетолог на основе замечаний создает новый документ Бриф и отправляет на повторную проверку.
В брифе недочетов не выявлено. Руководитель переходит к выбору рекламных площадок.
В системе обязательно должна быть возможность создать документ Бриф, добавить к нему замечания, создать на основании документа Бриф с замечаниями новый Бриф. Это позволит удобно работать с документами, при этом иметь возможность просмотреть предыдущие версии и замечания к ним.
Выбор площадок для рекламы выполняет руководитель на основе анализа брифа и возможностей каждой из площадок.
Это могут быть:
ВКонтакте
Google ADS
Яндекс Директ
Необходимо предусмотреть возможность выбора одной или нескольких площадок одновременно.
Одобренный бриф вместе со списком выбранных площадок отправляется маркетологу.
Рекламная кампания в данном случае – это документ, который создается в системе на основе одобренного брифа и выбранных рекламных площадок.
Все расчеты проводит маркетолог на основании брифа и тарифов выбранных площадок. После выполнения непосредственно расчетов, данные вносятся в специальные поля документа Рекламная кампания, который отправляется на согласование руководителю.
Руководитель проверяет расчет бюджета. Если выявляются ошибки и неточности, к документу Рекламная кампания добавляются замечания по бюджету и отправляются маркетологу внутри системы.
Если замечаний не выявлено, бюджет одобряется, маркетолог получает соответствующее подтверждение и переходит к запуску рекламы.
На этом этапе также важно предусмотреть в системе возможность видеть предыдущие варианты бюджета и замечания к ним.
Непосредственная работа по этому этапу проводится на выбранных рекламных площадках. В системе маркетолог после получения одобрения бюджета нажимает кнопку «Запустить рекламную кампанию», т.е. меняет статус кампании соответствующим образом.
Работа выполняется маркетологом на рекламных площадках. Все это время статус кампании активен, т.е. руководитель видит, что кампания – в работе.
По результатам рекламной кампании маркетолог обязательно собирает статистику, которую вносит в соответствующий документ в системе. Документ «Статистика» должен быть привязан к текущей Рекламной кампании в системе.
На этом процесс завершен.
Процесс оказания услуги начинается с прихода клиента в компанию для оказания услуги и завершается моментом оплаты услуги клиентом.
В процессе участвуют 3 исполнителя:
Администратор. Это сотрудник, который встречает клиента и направляет его к доктору.
Доктор. Специалист, который непосредственно оказывает услугу.
Касса. Сотрудник, который принимает оплату и оформляет финансовые документы.
На этом этапе администратор взаимодействует с клиентом и уточняет, пришел человек за услугой по предварительной записи или нет. Даже если клиент пришел без записи, услуга по возможности должна быть оказана.
Возможны два варианта:
Посетитель не по записи. Администратор выполняет Запись клиента. На этом процесс завершается и начинается заново.
Посетитель по записи. В этом случае клиент сообщает администратору номер записи либо администратор указывает ее на основе только что завершенного процесса записи.
На этом этапе система должна на основе введенного номера определить и открыть для администратора Запись. Рекомендуется реализовать возможность считать запись с мобильного телефона клиента по штрих-коду. Т.е. в процессе записи клиент получает на телефон уведомление не только в текстовом виде, но и со штрих-кодом. В результате при посещении администратор сможет максимально быстро и безошибочно открыть нужную Запись.
На основании уже заполненных полей система автоматически определяет, нужно ли дополнять данные и уведомляет об этом администратора.
Если данные дополнить нужно, администратор задает соответствующие вопросы и дополняет:
Карточку клиента,
Карточку питомца.
Далее клиенту выдаются раздаточные материалы. После чего клиент направляется к доктору на прием. Если данные уже все заполнены, клиент отправляется к доктору сразу.
Доктор принимает клиента по записи. В системе в момент начала приема доктор фиксирует, что прием состоялся. После нажатия соответствующей кнопки система начинает отсчет реального времени приема.
Этот этап выполняет доктор, в системе непосредственно оказание услуги не отражается. Эти операции выполняются непосредственно специалистом вне системы.
После непосредственного оказания услуги доктор в системе заполняет форму «Оказание услуги», в котором отображает, какие услуги были оказаны, вносит необходимые сведения для карточки питомца и т.д. После того, как проделаны необходимые действия в рамках приема, доктор завершает прием в системе.
После того, как доктор внес все необходимые сведения в документ «Оказание услуги», формируется пакет документов для клиента, которые можно распечатать пакетом. Доктор отправляет документы на печать и передает клиенту документы для расчетов в кассе, а также информацию о состоянии питомца, выполненных процедурах, рекомендации и т.д. Клиент направляется в кассу.
В этот раз процедуру получения номера записи, в том числе, в случае реализации, через штрих-код, выполняет сотрудник кассы. На основании этого номера открывается запись с уже заполненными услугами, после чего автоматически формируется сумма и необходимые финансовые документы.
Кассир выполняет наличный или безналичный расчет с клиентом, распечатывает финансовые документы, в том числе, для клиента.
После того, как оплата завершена, система автоматически формирует sms-сообщение и/или email и отправляет его клиенту с просьбой оценить качество работы.
На этом процесс завершен.
Этот процесс описывает ситуацию, когда клиент пришел по записи получать животное из стационара. В отдельных случаях животное клиент получает из клиники, для них этот процесс также подходит. Но так как чаще всего речь идет о стационаре, здесь также будет использоваться именно этот термин.
Если животное передают от специалиста к специалисту внутри организации, в системе это никак не отмечается. Факт смены доктора отслеживается по записям об оказанных услугах.
В бизнес-процессе участвуют:
Администратор
Доктор
Кассир
Процесс начинается с момента, когда клиент приходит забирать животное. К этому моменту само животное должно быть готово к передаче, а также должны быть актуализированы все соответствующие записи, в том числе, финансовые.
Первое, что должен проверить администратор, по записи пришел клиент или нет.
Если клиент пришел не по записи, его обязательно администратор должен записать и сделать соответствующую отметку в системе. После чего сразу осуществляется переход к проверке задолженности.
Если клиент пришел по записи, администратор вводит номер записи в систему, определяет нужную запись, и также переходит к проверке задолженности.
В этом процессе также будет полезно использование штрих-кодов, которые система будет отправлять при записи на телефон клиента. Такой подход ускорит процесс нахождения записи и снизит вероятность ошибок, связанных с человеческим фактором.
Здесь возможны два варианта:
Заложенности нет. Администратор переходит к проверке наличия переплаты.
Задолженность есть. Администратор выдает клиенту финансовые документы и отправляет его в Кассу.
Во втором случае Кассир принимает оплату, фиксирует эту информацию в системе, после чего клиент возвращается к администратору уже на этап «Распечатать документы Выдача животного».
Если задолженности нет, администратор должен проверить наличие переплаты. При ее выявлении он предлагает вернуть клиенту деньги.
Если Клиент согласен получить сумму переплаты, ему выдается расходный кассовый ордер, после чего он отправляется в Кассу, где получает неиспользованный аванс.
Если клиент предпочитает оставить сумму переплаты в счет будущих посещений, то сразу можно переходить к следующему пункту.
После решения всех финансовых вопросов администратор распечатывает клиенту пакет документов «Выдача животного».
Администратор передает клиенту пакет документов «Выдача животного» и направляет клиента к доктору, который занимается животным в данный период времени.
Животное выдает клиенту доктор на основании переданных ему данных в системе о том, что клиент получил пакет документы «Выдача животного». После выдачи доктор также делает соответствующую пометку в карточке.
После того, как доктор подтвердил в системе выдачу животного, автоматически формируется email или sms-сообщение с просьбой оценить качество работы по данному процессу.
Записи
Клиенты
Питомцы
Расходно-кассовый ордер и документ «Возврат аванса»
Пакет документов «Выдача животного»
Шаблоны для отправки сообщений с предложением оценить работу либо интеграция со сторонней системой для отправки соответствующего email.
В последнем случае рекомендуется использовать SendPulse или Mailchimp.
В документах большая часть полей должна заполняться автоматически на основании предыдущих записей в системе. Все документы распечатывает администратор. Кассир получает и выдает деньги, может выдать чек, который распечатывается автоматически. Доктор выдает только животное.
Потому в рамках этого бизнес-процесса доступ к печати документов необходим только администратору.
Рамиль Кинзябулатов — бизнес-консультант с большим практическим опытом работы в России и в зарубежье (США, Италия, Германия). Автор многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса.
Заполните форму, и наш менеджер Рузалина свяжется с вами и поможет найти ответ
