РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ ПОДАЧИ КЛИЕНТСКИХ ЗАЯВОК НА ПРЕДПРИЯТИИ

Введение

Информационный сайт предприятия обычно решает задачу первичного ознакомления клиента с товарами: показывает категории, карточки, цены и контактные данные. Однако после просмотра каталога клиенту всё равно необходимо перейти к следующему действию – оставить заявку на выбранные позиции. Если отдельного механизма подачи заявки нет, обращение уходит в телефонный звонок, электронную почту, мессенджер или обычную форму обратной связи. В таком виде сотруднику приходится заново уточнять состав обращения и вручную переносить данные в рабочие документы.

Для рассматриваемого проекта важно, что сайт уже имел товарную часть. Поэтому задача заключалась не в создании сайта с нуля, а в добавлении программного модуля, который связывает существующий каталог с подачей клиентской заявки. В рамках модуля пользователь должен выбрать товары, добавить их в корзину, указать количество, заполнить контактные данные и отправить обращение. Администратор должен увидеть поступившую заявку, проверить товары, изменить статус и при необходимости оставить служебную заметку.

При выборе подхода учитывались существующие решения для приема обращений: CRM-формы, клиентские порталы, сервис-деск-системы и конструкторы сайтов [1, 2, 5]. Они полезны для разных задач, но в данной работе требовалась более прикладная реализация внутри уже готового сайта. Поэтому основной акцент сделан не на сравнении внешних платформ, а на разработке собственного модуля, встроенного в текущую структуру веб-проекта.

Цель статьи – описать разработку программного модуля подачи клиентских заявок на предприятии, включая пользовательскую часть, оформление заявки, хранение данных, личный кабинет и административную обработку обращений.

Разработка пользовательского сценария

Работа пользователя построена как последовательный маршрут внутри сайта. Сначала клиент открывает каталог, выбирает нужную категорию или использует поиск. В карточке товара он уточняет описание, цену и количество, после чего добавляет позицию в корзину. Затем пользователь проверяет список выбранных товаров и переходит к оформлению заявки. Такой сценарий понятен для клиента, потому что он похож на обычную работу с интернет-витриной, но итогом становится не оплата заказа, а заявка на обработку.

На рисунке 1 показана страница каталога. В левой части расположен блок категорий и поиска, а основная область содержит карточки товаров. Каждая карточка включает название, цену, краткое описание, поле количества и кнопку добавления в корзину. За счет этого пользователь может сформировать предварительный набор товаров без лишних переходов между страницами.

Рисунок 1. Страница каталога товаров

Если пользователю требуется больше информации, он открывает карточку товара. На этой странице выводится изображение, название, цена, артикул, описание и элементы добавления в корзину. В рамках разработки важно было сохранить простую логику: карточка товара не оформляет заявку напрямую, а передает выбранную позицию в корзину, где пользователь может проверить общий состав обращения.

Рисунок 2. Страница карточки товара

Реализация корзины и оформления заявки

Корзина выполняет роль промежуточного состояния между каталогом и заявкой. Пока пользователь не нажал кнопку оформления, выбранные товары можно изменить: увеличить или уменьшить количество, удалить позицию или полностью очистить корзину. Это снижает вероятность ошибочной отправки и позволяет клиенту проверить состав обращения до передачи данных администратору.

На рисунке 3 представлен пример корзины. В таблице видны товарные позиции, цена, количество и сумма по каждой строке. Внизу страницы отображается итоговая сумма, а также кнопка перехода к оформлению. Такой экран помогает пользователю увидеть итоговый состав заявки до заполнения контактных данных.

Рисунок 3. Страница корзины с выбранными товарами

После перехода к оформлению пользователь заполняет форму. В ней указываются имя или название компании, телефон, адрес электронной почты и комментарий. Справа отображается краткий состав заказа, что позволяет не возвращаться в корзину для проверки выбранных позиций. В результате клиент видит и контактную форму, и состав заявки на одном экране.

На рисунке 4 показана страница оформления заявки. С точки зрения серверной логики именно на этом этапе временный набор товаров превращается в постоянную запись. Сервер получает данные формы, проверяет наличие товаров в корзине, создает запись заявки и сохраняет позиции. После успешного оформления корзина очищается, а заявка становится доступной пользователю в личном кабинете.

Рисунок 4. Страница оформления клиентской заявки

Сохранение заявки и взаимодействие с базой данных

Для хранения данных в проекте используется SQLite. Такой вариант подходит для учебного веб-проекта и небольшого информационного сайта, так как база хранится в одном файле и не требует отдельного серверного процесса [8]. Серверная часть реализована на PHP, который обрабатывает формы, работает с сессиями и обращается к базе данных [7]. Интерфейсные страницы построены на HTML и CSS [3, 4], а отдельные интерактивные действия поддерживаются JavaScript.

При отправке заявки сохраняются две группы данных. Первая группа – общие сведения обращения: номер заявки, пользователь, электронная почта, контактное имя, телефон, комментарий, статус и дата создания. Вторая группа – товарные позиции, выбранные пользователем. Такое разделение нужно потому, что одна заявка может включать несколько товаров. Поэтому сначала создается запись самой заявки, а затем для каждого товара добавляется отдельная строка состава.

В программной реализации общая часть заявки сначала сохраняется как отдельная запись. После этого сервер получает идентификатор созданного обращения и использует его для привязки товарных позиций к этой заявке.

Каждая позиция состава связывается с заявкой через поле order_id. Благодаря этому администратор может открыть одно обращение и увидеть все товары, которые относятся именно к нему, без смешивания данных с другими заявками.

В позициях заявки дополнительно сохраняются название, артикул и цена товара на момент оформления. Это сделано для того, чтобы последующие изменения каталога не искажали старые заявки. Например, если администратор позже изменит цену или описание товара, ранее отправленное обращение сохранит исходные данные, с которыми работал клиент.

Личный кабинет пользователя

После отправки заявки пользователь должен иметь возможность проверить, что обращение действительно зарегистрировано. Для этого реализован личный кабинет. В нем отображаются только заявки текущего пользователя: номер, дата создания, статус и состав выбранных товаров. Такой подход делает процесс обработки более прозрачным, потому что клиент видит не только факт отправки, но и текущее состояние обращения.

На рисунке 5 показан раздел «Мои заказы». В нем заявка отображается в виде строки с номером, датой, статусом и перечнем товаров. Пользователь не получает доступ к чужим заявкам, так как выборка выполняется по идентификатору текущей учетной записи.

Рисунок 5. Личный кабинет пользователя с историей заявок

Для получения истории сервер обращается к таблице заявок с фильтрацией по текущему пользователю. После этого для каждой найденной заявки отдельно загружается состав из связанных товарных позиций. Такой способ удобен для вывода истории, потому что общие данные заявки и список товаров можно показывать раздельно.

Административная обработка заявок

Административная часть предназначена для сотрудников, которые обрабатывают поступившие обращения. В ней отображается общий список заявок, контактные данные клиента, состав выбранных товаров и текущий статус. В отличие от пользовательского кабинета, администратор работает не только со своими заявками, а со всеми обращениями, поступившими через сайт.

На рисунке 6 представлен раздел управления заявками. Администратор может просмотреть номер, дату, контактные данные, товары и изменить статус. Для обработки используются статусы «новый», «в обработке», «отгружен», «выполнен» и «отменен». Это позволяет отделить новые обращения от уже обработанных и сделать работу с заявками более управляемой.

Рисунок 6. Административная панель управления заявками

Статус меняется через серверный запрос. После сохранения новое значение записывается в базе данных, а пользователь видит обновленное состояние заявки в личном кабинете. При необходимости администратор также может сохранить служебную заметку, которая относится к конкретному обращению.

Отдельно реализована служебная заметка администратора. Она используется для внутреннего комментария по заявке и хранится отдельно от комментария клиента. Это важно, потому что пользовательский комментарий описывает пожелания клиента, а заметка администратора может содержать рабочую информацию: результат звонка, уточнение по наличию или примечание по дальнейшей обработке.

На рисунке 7 показано окно добавления заметки. Администратор открывает его из списка заявок, вводит текст и сохраняет изменения без перехода на отдельную страницу. Такое решение ускоряет обработку обращений и делает интерфейс удобнее для сотрудника.

Рисунок 7. Окно добавления заметки администратора

Дополнительно предусмотрен раздел управления уведомлениями. В нем администратор задает адреса электронной почты, на которые должны отправляться сообщения о новых заявках. Адреса хранятся отдельно, поэтому их можно менять без правки исходного кода. На рисунке 8 представлен соответствующий раздел административной панели.

Рисунок 8. Раздел управления уведомлениями

Разграничение доступа и практический результат

В модуле предусмотрено разделение пользователей по ролям. Обычный клиент получает доступ к каталогу, корзине, оформлению заявки и собственному личному кабинету. Администратор дополнительно видит панель управления. Проверка прав должна выполняться на серверной стороне, так как одного скрытия ссылок в интерфейсе недостаточно. Ошибки авторизации и контроля доступа относятся к распространенным рискам веб-приложений [6].

Практический результат разработки состоит в том, что сайт перестает быть только витриной товаров. Пользователь проходит полный маршрут внутри одного веб-интерфейса: выбирает товар, формирует корзину, отправляет заявку и отслеживает ее состояние. Для предприятия результат выражается в том, что входящие обращения становятся структурированными: каждая заявка имеет номер, дату, контактные данные, состав, количество товаров и статус.

В отличие от свободного сообщения по электронной почте, такая заявка меньше зависит от человеческого фактора. Клиент не должен вручную перечислять артикулы в письме, а сотрудник не должен собирать состав обращения из разных каналов. Модуль сохраняет данные в едином виде и делает дальнейшую обработку удобнее для администратора.

Заключение

Разработанный программный модуль подачи клиентских заявок предназначен для расширения существующего информационного сайта предприятия. Его особенность заключается в соединении товарного каталога с механизмом оформления обращения. Пользователь формирует заявку из конкретных позиций, а администратор получает структурированную запись для дальнейшей обработки.

В статье описаны основные элементы разработки: пользовательский маршрут от каталога до оформления заявки, работа корзины, сохранение общей информации и товарных позиций, личный кабинет, административная панель, изменение статусов, служебные заметки и управление уведомлениями. Такой набор функций позволяет заменить разрозненные обращения через почту или мессенджеры единым электронным журналом заявок.

Полученное решение может использоваться как основа для дальнейшего развития. В перспективе модуль может быть дополнен расширенной фильтрацией, экспортом заявок, более подробной аналитикой и интеграцией с внешними CRM-системами. При этом текущая реализация уже решает основную задачу: обеспечивает подачу клиентской заявки через сайт и сохраняет ее в структурированном виде.