Автоматизация бизнес-процессов телефонного маркетинга

Дипломная работа - Маркетинг

Другие дипломы по предмету Маркетинг



Данная библиотека предоставляет кроcс-платформенный программный интерфейс для работы с файлами в форматах MS Office без необхожимости в установке MS Office.

.4 Архитектура системы планирования звонков

Сущностями являются:

  • Оператор. Характеризуется идентификатором, логином, фамилией, именем и отчеством. Все эти данные могут храниться отдельно от системы планировщика и использоваться этой базой данных через LDAP-серверы. В этом случае таблица не используется, а важной для системы информацией является только идентификатор Оператора.
  • Клиент. Главная таблица базы данных планировщика. Содержит информацию о клиенте, получаемую в ходе Контактов. Изначально в таблице хранятся исключительно телефонные номера, в процессе обзвона данные пополняются. Клиент характеризуется: идентификатором; оператором, с которым совершался контакт; фамилией, именем и отчеством; телефонным номером; состоянием (открыт/закрыт), который указывает о целесообразности дальнейших контактов с клиентами; контактной информацией, которая включает в себя адреса, дополнительные телефонные номера и прочие данные, которые сообщил о себе клиент; комментарии, содержащие прочую информацию.
  • Контакт. Таблица контактов, реализующая связь многие-ко-многим между Операторами и Клиентами. Каждый контакт характеризуется: идентификаторами Клиента и Оператора, между которыми он был произведён; статусом (согласно Таблица 4), который был получен в результате текущего контакта; временем, на которое был запланирован данный контакт и времем в который этот контакт реально состоялся.
  • На Рис. 9 представлена упрощённая диаграмма классов системы планирования звонков. Архитектура системы состоит из трёх уровней:
  • Уровень доступа к базе данных. К нему относятся классы: Operator, Contact и Client, отображающие сущности базы данных. Содержат поля, соответствующие атрибутам таблиц базы данных и методы доступа к этим полям. Класс DataBaseManager - класс, являющийся точкой доступа к базе данных. Предоставляет метод getEntityManagerFactory - для получения фабрики объектов EntityManager (объектов, обеспечивающих соединение с базой данных); и метод setClientDatabase реализующий обновление всей базы данных клиентов, то есть заполнение её новыми номерами.
  • Уровень бизнес-логики. К нему относится: Shelduler - класс планировщика. Инкапсулирует логику работы планировщика. Представляет метод getNextClient для получения карточки клиента, с которым оператор будет производить контакт в ближайшее время; и метод processClientData, обеспечивающий обработку данных о клиенте, после контакта с оператором. Кроме этого обладает полями: attemptsNumber - количество попыток дозвониться до клиента; busyTimeShift - время, через которое нужно перезвонить, если телефон клиента занят; noanswerTimeShift - время, через которое нужно перезвонить, если телефон клиента не отвечает.
  • Уровень интерфейса пользователя. На данном уровне находятся client.jsp - страница jsp, реализующая интерфейс карточки клиента (интерфейс оператора); configuration.jsp - страница jsp, реализующая интерфейс настройки планировщика и базы данных (интерфейс супервайзера); reports.jsp - страница jsp, реализующая интерфейс диспетчера отчетов. Для каждого из этих jsp файлов существуют классы-сервлеты, реализующие обработку поступающих от jsp данных.
  • В начальный момент, после авторизации в системе Оператора отправляет запрос серверу-планировщику о выдаче ему свободной карточки клиента. В типовом случае на ближайшее время для данного оператора нет запланированных звонков, и планировщик формирует новый Контакт. Контакт планируется на текущее время плюс некоторое зарезервированное время (как правило 15 минут), назначает созданный контакт данному Оператору и заносит его в базу данных, тем самым закрепляя данный контакт за выбранным оператором. После чего Контакт выдаётся Оператору в виде страницы client.jsp.
  • Затем оператор осуществляет звонок клиенту и в процессе общения получает информацию о клиенте. После чего вводит ей в карточку (client.jsp) и отправляет на сервер, где информация заносится в базу данных, а объект контакта уничтожается.

  • В случае если на данный момент запланирован контакт с определённым клиентом диаграмма последовательности отличается незначительно - контакт не создаётся заново, а используется существующий.
  • Для выдачи контакта используется метод getNextClient класса планировщика на Рис. 11 представлена блок-схема алгоритма работы данного метода: для текущего оператора выполняется запрос к базе данных на выборку контактов, запланированных для данного оператора и запланированное время которых меньше текущего (т.е. просроченных контактов). В случае если такой контакт существует, он выдаётся оператору. В противном случае из списка открытых Клиентов, с которыми не запланировано контактов, либо контакт был запланирован но не состоялся, выбирается клиент, и для этого клиента формируется новый контакт, который назначается на данного оператора, заносится в базу данных и отправляется оператору.
  • Для обработки данных полученных от клиента используется метод processClientData планировщика, блок-схема которого представлена на Рис. 12. Метод получает как аргумент объект типа contact с данными, которые оператор заполнил в форму в процессе общения с клиентом. В случае если был установлен статус отказ от предложения, заказ или неверная информация то карточка считается закрытой, о чём устанавливается соответсвующий атрибут у объекта Клиент. Поступивший контакт счит?/p>