Хотя ничто не может быть идеальным, всегда кажется, что все ненавидят (или, по крайней мере, недовольны) их систему продажи билетов. Если бы у вас было «идеальное» решение, что бы оно включало? Я предлагаю идею.
Для меня это было бы:
-Веб-клиент с отформатированной мобильной версией (как минимум для браузеров iPhone / Android / Pre webkit)
-... или собственное мобильное приложение, которое подключается к базе данных
-Веб-клиент (да)
- Что-то вроде «модульной системы», чтобы можно было убрать сложности для тех, кому они не нужны. Мол, он может быть настолько мощным, насколько вы хотите. Если вам не нужна функция, уберите ее.
Это то, что у меня есть прямо сейчас ... Я хотел бы услышать, о чем вы думаете.
Есть много решений. Одно из решений, с которым я знаком, - от Каяко. Конечно, это не бесплатно, но, похоже, предлагает то, о чем вы просите.
С сайта Kayako:
Программное обеспечение службы поддержки Kayako готово к работе и очень простое в настройке, для него не требуется ничего, кроме обычного веб-сервера. С помощью автоматического установщика можно приступить к работе за считанные минуты.
Опять же, они, вероятно, не лучший, но я считаю их продукты надежными.
Вы должны быть более конкретными в отношении целей этой системы продажи билетов. Есть как минимум два типа:
Система отслеживания инцидентов
Системы отслеживания ошибок:
OTRS и RT имеют большой послужной список, написаны на Perl и довольно просты в настройке. Они оба уродливые, но мне потребовалось всего пара часов, чтобы исправить OTRS и заставить его выглядеть достойно, но зато я неплохо разбираюсь в CSS.
OTRS очень хорошо поддерживается, пакеты коммерческой поддержки вполне доступны, компания, стоящая за ним, кажется весьма отзывчивой. Они также интегрировали все виды стандартных модных бинго-совместимых функций, таких как ITIL и тому подобное.
Мы рассмотрели несколько предложений службы поддержки по продаже билетов, в том числе одно, которое было в значительной степени адаптировано для нас.
Я был главным двигателем изменений, потому что мне нравятся билетные менеджеры - у меня память сита, а с хорошей системой продажи билетов мне не нужно помнить. Система делает. Но из-за проблем с различными системами мои коллеги неохотно использовали их.
Я усвоил две ключевые вещи:
Первый, Руководство ДОЛЖНО использовать инструмент и ПРИСОЕДИНЯТЬСЯ к его использованию во ВСЕХ случаях. Эти вещи управляются сверху вниз. Любой вид управления задачами будет мешать выполнению задач, и если технические специалисты вынуждены делать клиентов счастливыми, они воспользуются практически любым доступным им ярлыком.
Во-вторых, Это должно быть просто. Руководству нравится иметь этапы, фазы, утверждения, категоризации, метрики, интеграции с историями активов и все такое (извините) дерьмо. Но все это мешает.
Открытие нового билета должно быть тривиальным делом. Не щелкнуть-щелкнуть-тип-тип-щелкнуть-щелкнуть-выбрать-перетащить-щелкнуть-щелкнуть-тип-тип-тип-тип-щелкнуть. Системы, которые позволяют клиентам открывать билеты по электронной почте, выигрывают для меня, особенно когда электронные письма можно анализировать для предварительного заполнения некоторых элементов управления, таких как категории или очереди.
Обновление тикета должно быть тривиальным. Здесь инструменты на основе электронной почты терпят неудачу, потому что большинству пользователей, кажется, нравится топ-пост-и-цитировать-все-[плохое слово-удалено] -то. Это затрудняет чтение историй.
Смена владельца / оператора должна быть тривиальной задачей.
Закрытие заявки должно быть тривиальным делом, но следует поощрять технических специалистов описывать, как она была закрыта в интересах создания базы знаний.
Итог: правильные поступки должны быть тривиальными, иначе этому будет сопротивление.
Некоторые особенности, которые я хотел бы увидеть:
Идеальное решение для продажи билетов - это не решение для предприятий.
Где-то там может быть отличная реализация ServiceCenter, ServiceDesk, Remedy и т. Д. ... но я ее еще не видел.
Я обнаружил веб-систему службы поддержки под названием HelpSpot на форуме Joel on Software, который мне показался фантастическим. Мы устроили тест-драйв на работе, но для нас не хватило предприимчивости. (Для больших компаний платить кому-то 150 долларов в час за установку программного обеспечения - все равно что предлагать козлов богам вулканов.)
Как правило, единственное идеальное решение - это свернуть самостоятельно. Под капотом они довольно просты ... на самом деле, я думаю, что проект PHP-Symfony пытается создать общий плагин, который вы можете просто изменить оттуда.
Проблема сводится к тому, что важно для вашей организации: в предыдущей организации, для которой я разработал один из них, тремя важными вещами были жизненный цикл запроса (SOX-ish), межведомственное отслеживание запросов (для управленческих кулаков) и отслеживание времени (потому что разные отделы выставляли друг другу счета за время.) Нашим единственным решением было накатить собственные, и на это ушло меньше месяца.
Программное обеспечение было написано в 2001 году, когда я был стажером в колледже, и оно работает до сих пор ... с множеством модификаций и взломов, которые сделали его еще БОЛЬШЕ эксклюзивным для организации.
На данный момент я использую JIRA для разработчиков программного обеспечения, а мы используем RT для службы поддержки, потому что у нас было слишком много инцидентов, когда JIRA недостаточно четко определяла, кому она отправляла электронное письмо, из-за безумно сложной системы привилегий / прав / ролей.
BMC Remedy + ITSM + SRM установлен на нем