посоветуйте скрипты(программу) для хостинговой слу

Господа, посоветуйте скрипты(программу) для хостинговой службы тех.поддержки.



Пожелания следующие:

1. Каждый запрос клиента регистрится в этой системе, запросу присваивается ид и с ним работается.

а. самим клиентом через веб (возможно емайл?)

б. тех поддержкой

2. Желательна поддержка регистрации времени, которое уходит на решение проблемы.
3. Встроенная система создания FAQ.



Либо поделитесь опытом разработки такой систему (подводные камни, приятные фичи и т.д.)

[Helga]

То что вы описываете - это своего рода CRM, только специализированный. Некий опыт есть: недешевая вещь.
Хотя все в мире относительно

[Ivan S Karpoukhin]

Лучше PerlDesk http://www.perldesk.com из бесплатных ничего не видел. Но нет там пока руссификации. Переведи и начни руссификатор продавать.. Или раздавать..

[web_pr]

Мы сейчас ведем похожую разработку.
Посоветуйте, как хранить информацию: в файлах или в БД (mySQL).

Конечно удобней в БД. Но ведь есль упадет БД, по парализуется работа всей службы поддержки - а это не есть хорошо...

[Nest]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата (jinishiu @ 05 Сен. 2002, 05:34)</td></tr><tr><td id="QUOTE">Господа, посоветуйте скрипты(программу) для хостинговой службы тех.поддержки.
[/QUOTE]<span id='postcolor'>
Насколько я понял интересует т.н. TTS (Trouble Ticket System)
Готовых решений куча, но особенно хотелось бы отметить WebRT aka Request Tracker
Вкратце:
Запросы от пользователей поступают по e-mail или из формы на некоем сайте, группируются в т.н. &quot;очереди&quot;
Дальнейшее общение с пользователем ведется по почте. (к сожалению пустить пользователя в веб - интерфейс просто нельзя).
Техподдержка работает с запросами через почту или через веб-интерфейс (что предпочтительней)
Учет времени, сроки, ответственные, групповая обработка запроса, связи между запросами, связанные с запросом URL (например ссылки на документацию и т.п.), ключевые слова, поиск, да и много чего еще.
Написано на modperl+SQL, внутренняя архитектура - полностью объектная.
Код очень понятный и крайне легко модифицируемый, так что подзаточить под себя нет никаких проблем.
OpenSource, non-commercial, есть платная поддержка.

Резюмируя: лучше я пока ничего не видел.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">Либо поделитесь опытом разработки такой систему (подводные камни, приятные фичи и т.д.)[/QUOTE]<span id='postcolor'>
Подводный камень один - много писать. Проще взять что-то готовое и заточить под себя.

[Nest]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата (web_pr @ 06 Сен. 2002, 00:21)</td></tr><tr><td id="QUOTE">Мы сейчас ведем похожую разработку.
Посоветуйте, как хранить информацию: в файлах или в БД (mySQL).
[/QUOTE]<span id='postcolor'>
Я бы порекомендовал хранить тело запроса в файлах, служебную информацию - в БД.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">
Конечно удобней в БД.
[/QUOTE]<span id='postcolor'>
Это смотря для чего. Например для нормального полнотекстового поиска по архиву удобнее вовсе даже и в файлах.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">Но ведь есль упадет БД, по парализуется работа всей службы поддержки - а это не есть хорошо... [/QUOTE]<span id='postcolor'>
А БД упадет навсегда?
ИМХО поднять упавший mysql или Postgres (или иной) сервер можно весьма быстро.
Или вы имеете в виду, что в результате сбоя может быть утеряна информация в БД?
Но и в файлах она точно так-же может быть утеряна, кроме того, кто мешает хранить updatelog от БД?
А если этот лог будет вестись на другом сервере, то шансы потерять БД почти нулевые.
Да и насколько я знаю реплицирование БД и FS , содержащих ценную информацию, просто правило хорошего тона.

[web_pr]

Я просто решил устроить маленький опрос
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Исходный код </td></tr><tr><td id="CODE">
Текущие результаты:
mySQL 100%
файлы 0%
[/QUOTE]<span id='postcolor'>

[GOSTHOST.RU]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата (web_pr @ 06 Сен. 2002, 08:35)</td></tr><tr><td id="QUOTE">Я просто решил устроить маленький опрос
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Исходный код </td></tr><tr><td id="CODE">
Текущие результаты:
mySQL 100%
файлы 0%
[/QUOTE]<span id='postcolor'>[/QUOTE]<span id='postcolor'>
хех, наверное меня мало кто поддержит, но я против SQL и тому подобных баз...
С моей точки зрения, в 100% случаев при разработке новой базы лучше делать ее собственной, как тут выразились, в файле.
Собственная структура, собственные файлы базы, собственная обработка - все собственное :о)

[web_pr]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">Собственная структура, собственные файлы базы, собственная обработка - все собственное[/QUOTE]<span id='postcolor'>

Это хорошо для простеньких проектов.

А реализовать выструю выборку из файла да еще и с условиями - не так уж и просто...

[GOSTHOST.RU]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">Это хорошо для простеньких проектов.

А реализовать выструю выборку из файла да еще и с условиями - не так уж и просто...[/QUOTE]<span id='postcolor'>
не спорю, повозиться придется, но при прочих равных условиях собственная база будет работать в разы быстрее чем SQL...