Как мы написали helpdesk
Есть продукты, которые можно взять и использовать, но с небольшой модификацией «под себя». Так вот система заявок или helpdesk как раз к таким вещам не относится. Точнее, мы для себя не нашли подходящий продукт и решили сделать сами.
Изначально, у нас были исходные от которых отталкивались и позже выдвигались требования: Чуть больше 2000 пользователей, которые не будут участвовать в системе заявок, но статистику обращения которых нужно фиксировать
Около 30 человек персонала, которые делятся на 3–4 отдела, в котором по начальнику и все они имеют доступ к хелпдеску
Система только для внутреннего корпоративного использования
Извещение по email/sms
Отчётность и статистика
База пользователей (идеально взять с ActiveDirectory, хотя бы частично)
Если у Вас такие же исходные, возможно Вам эта статья и система помогут.Позиция меня, как разработчика основывалась на сегменте готовых opensource продуктов, поддерживающих php & mysql. Изначально были рассмотрены: OsTicket, который достаточно прост, но в тоже время много функционален, что в свою очередь является минусом (много лишнего «выпиливать и прятать», а то что необходимо — дописывать). А так же более серйозное решение — OTRS, которое имеет встроенный инструмент работы с LDAP. В нём особенно понравилась форма создания заявки, в которой при вводе ID клиента подтягивалась вся информация о нём. И поэтому захотелось «золотой середины». Общий вывод таков, что под конкретные требования не подходит не один из них, но у последнего ввиду интерфейса хотя бы можно игнорировать часть требований. Имея небольшой опыт разработки php/jquery-проектов, я решился написать свою систему.
Основными задачами были: учёт всех заявок, отчётность и контроль со стороны руководства, в какой стадии находится та или иная задача. К примеру, начальник отдела мог с вечера определить задачи на следующий день для своих подчинённых, выбрав для них приоритет. А подчинённые, прийдя на работу, могли сразу видеть список задач и в течении определённого времени их выполнять.
Как такового чёткого технического задания у нас не было. Поэтому мы примерно определили структуру системы и её модулей.
Как видно из модели, хотелось так же использовать систему «личных сообщений» пользователей. Но в будущем эта затея отпала, зато вместо неё мы решили добавить:
Комментарии на странице заявки, для того что бы можно было обсуждать заявку или отписываться по её выполнению
Разделить заявки на 3 категории: Входящие, Исходящие, Архив (в который заявки автоматически попадают по истечению какого-то времени, при статусе «выполнено»)
Центр знаний (раздел, в котором можно было бы найти ответы на интересующие вопросы, решить проблему не создавая заявку. Тут могут быть инструкции, руководства, документация)
Блокнот (для хранения личных заметок и записей, с возможностью делиться ссылкой на них)
Логирование всех действий пользователей
Немало времени и работы уделялось процессу создания заявки. Как я уже писал выше, понравился подход в OTRS. Поэтому, что бы при звонке клиента можно было идентифицировать его, узнав о его предыдущих заявках и числу обращений, необходимо было наполнить базу клиентов. У нас часть информации о клиентах хранилась в Active Directory, другая часть — в телефонном справочнике формата doc. В AD были только: ФИО, логин, email и группа (подразделение). В справочнике doc были: ФИО, тел, кабинет. Вместе они дополняли друг друга. В этих двух источниках, единицы информации могли и не совпадать. К примеру, в LDAP находилось около 2000 записей, а в справочнике — 1200. Из них совпало ~1000. Ну и этого было достаточно.
Наполнение базы клиентовПроцесс определился в несколько этапов: Импорт из AD был путём PHP. Стандартно подключались в LDAP, вытягивали нужную информацию.
Импорт из doc-справочника был куда интереснее. Сначала перенесли нужные данные таблиц в xls, отформатировали и сохранили в CSV.
Далее импорт в MySQL-таблицу делал php-скрипт, который в цикле перебирал LDAP-записи и sql-записи и сравнивал ФИО (это единственное, что у них было общее).
В итоге имеем сборную таблицу с более 1000 записями информации о клиентах компании. При создании заявки мы можем ввести телефон, ФИО или логин, что бы узнать информацию о клиенте, его количеству обращений и последних заявках.Кодинг
Это не первый проект, в котором я выбрал такую организацию файлов. Возможно это можно назвать «шаблоном проектирования», поправьте, если ошибаюсь.
Для меня, такая организация «общения» файлов показалась более логичной и простой. Всё расположено там, где ему место. Файл actions.php в основном состоит из блоков-действий, вроде «создать заявку», «блокировать заявку», «добавить клиента» и т.д. К нему посылается POST-запрос с определённым именем, который и вызывает нужную часть кода. Что касается описания событий на странице, то за это отвечает core.js.
Движение заявки
О движении самой заявки, стоит рассказать детальнее. Как правило выделяют из всего персонала 1–2 человека-оператора или дежурных, которые и принимают заявки: 80% в телефонном режиме, 20% на месте. Мы всегда придерживались мнения, что важно решить проблему ещё до создания заявки. И если эта проблема/задача не в компетенции сотрудника, то он её направляет на профильный отдел или конкретному человеку. Если получатель заявки выбран отдел, то такую заявку увидят все, кто входит в этот отдел (и конечно начальник отдела). Если же выбран конкретный человек, то такую заявку увидит этот человек и его начальник. Остальным же пользователям отдела заявка будет не видна.
Идея заключается в том, что бы заявка не оставалась без внимания и её статус выполнения всегда мог наблюдать начальник отдела.В процессе разработки было решено делать 3-х уровневую систему прав пользователей.
Суть заключается в том, что главный Администратор видит заявки всех отделов и всех пользователей. Координатор состоит в определённом отделе (-ах) и видит заявки всех пользователей именно этого отдела (-ов). Пользователь видит только те заявки, которые направлены в его отдел (всем) или конкретно ему. Заявки другим пользователям со своего отдела он не видит.
Спустя время, мы столкнулись с коллизией: пользователи физически входили в один отдел, но фактически работа была смежной с другими отделами. И им необходимо было видеть заявки других отделов, но с разными правами. Так родилась идея «вертикально-горизонтальной» ориентации прав доступа. По вертикали — это были права пользователя: админ/координатор/пользователь. А по горизонтали — это список тех отделов, в которые он мог входить с общими правами. Логической точкой пересечения этих прямых и были общие права доступа в систему.
При тестировании мы увидели, что не очень заметно, когда появилась новая заявка. К примеру, у человека на одном мониторе может быть открыт в браузере хелпдеск, но при появлении новой заявки он ничего не увидит. Не хорошо. И тогда мы решили сделать, как в популярной социальной сети всплывающие сообщения. Срабатывают они по разным действиям, вот так: 
Для работы всплывающих сообщений мы на определённых страницах посылаем каждые 2 секунды ajax-запрос в 208 байт, который спрашивает у скрипта на сервере: «есть ли что-то новое для пользователя?» и если есть, то клиент получает json-ответ. Конечно, для полной «красоты», это делается через сокеты. Но пока мы к этому не пришли. Так же добавили эффект мерцания title-страницы и заголовок вкладки явно кричал: «тут что-то обновилось, обрати внимание».Совсем недавно у нас внедрили jabber-месенджер. Поэтому мы сразу подключили helpdesk к нему и теперь извещения о новых заявках приходят и в джабер. Часть сотрудников не находится на своих рабочих местах, а работают с клиентами (устанавливают софт, обслуживают технику). Поэтому к ним особое внимание по извещению о новых заявках. Самый оптимальный и простой способ это sms-извещение. Нашли удобный сервис и через его API интегрировали нашу систему.
Интеграция Важным моментом было получение доступа к системе заявок, существующих пользователей IT-подразделения. Мы создали белый список login/email. Суть его заключалась в следующем: человек при входе через web кликает на ссылку «первый вход», и вводит только свой ldap-логин. На его доменную почту приходит письмо с созданным паролем и ссылкой, на которую он переходит и получает полноценный доступ к системе. Таким образом снялась задача с администратора системы каждому выдавать учётные записи.Что у нас вышло? Многоуровневая система прав пользователей JQuery-ориентированая структура интерфейса Возможность регистрации в системе из «белого списка» e-mail адресов Извещение о новых заявках по e-mail, sms, и другим системам Пользовательские настройки Поддержка языков: Украинский, Русский, Английский Всплывающие сообщения о событиях с заявками (как в VK) Центр знаний — раздел для файлов документации, инструкций и хелпов со структурой прав Блокнот — личный блокнот пользователя с возможностью делиться ссылкой Статистика заявок «Умное» создание заявок по номеру, ФИО, логину клиента Приоритеты заявок Комментарии и чат в заявке Полное логирование всех действий всеми пользователями заявки И другое… Заключение. На сколько удобно и оправдано было написание такой системы покажет время. А пока мы стараемся не превращать её в «монстра», но в тоже время добавить некоторые возможности: добавление загрузки файлов к заявке, статистика и другие вещи. Моё личное критичное мнение заключается в том, что система вполне рабочая, но с кодом ещё необходимо поработать. Мне будет очень приятно услышать Вашу критику и замечания, а так же увидеть Ваш вклад в развитие проекта.Github: link.
