vzeman
17th March 2007, 12:57 AM
In this article I want to answer the question why we started development of SupportCenter in situation, when there are tens of other Helpdesk softwares on the market.
The answer is pretty simple: There is really no helpdesk software, which cares about user interface of support Agents and offers them superfast, intuitive and easy to use user interface.
here is online demo link:
http://demo.qualityunit.com/supportcenter
u:admin@qualityunit.com p:admin
Current experiences with other Helpdesks:
For more than 2.5 years we offer mail support to our customers for our other products and we need to answer hundreds of tickets per day.
In the past years we used Cerberus Helpdesk.
We had to stop using it, because it blocked our work and slowed down the support process.
In the following section I will explain what we learned and reused in our new Support Center.
I point out the 5 main features, that we need internally in good Helpdesk application and I will show you our results on small comparision of our old Helpdesk (Cerberus) software and GMail.
-------------------------------------------------------------------------
Experience #1 - show agent only the information that is needed to resolve customer's problem in the fastest possible way
Bad example:
Every support system on the market tries to fill application with hundreds of functions (often not needed for a daily work) and display them all at to the users.
We think that this is the best way to draw attention of support staff from real work and slow down the process.
e.g. Cerberus in ticket detail displays so much text, links and sections, that agent needs few seconds to find an information he needs. The same problem with too much information on one page is also on Helpdesk from Kayako.
Good example:
Shining star of all web applications is Google. Google's Gmail has very clean and easy to use User Interface.
Everything is at the right place and in right time...
Their design proves that they really think about every tiny link, how to display it in an useful way and in the right time.
Experience #2 - transmit to support staff's browser just information that is needed for fastest problem resolution, nothing more
Bad example:
A lot of functions on one page also means that you have to transmit a lot of data through the network and generation of final page on the server takes much longer.
When we used Cerberus, it often happend that final ticket detail had more than 1 MB of HTML code. Because of this caused, we had to wait for page nearly one minute.
Good example:
GMail transmits just data that are relevant in time. Therefore responses are fast without any bigger delays.
Experience #3 - transmit only clean data and render HTML directly on client.
Bad example:
Most of current Helpdesk applications based on "old" web technologies generate HTML code on server and this is transmitted to the client's browser with every request.
The result is that maybe 10-20 times more data than actually needed is transmitted, server is overpowered by HTML rendering pages.
Rendering means that server needs to handle not just data processing, but also waste time rendering HTML templates, user interface logic and similar tasks.
All this causes performance losses, because computation of all data is centered to only one point.
In our old system we often saw page expirations, because number of tickets in database and number of computations on one page on server caused timeouts.
Good example:
Speed of GMail is very good. This is caused mainly by fact, that Google's servers are handling just clean data and rendering of data to final HTML page is done at client's side.
This also means that they are able to handle much more users in same time.
Result #4 - implement just functions that are needed for support staff in right time
Bad example:
A lot of functions in application like Cerberus mean big and complicated code, and more bugs, that in return cause that some functions don't work.
We always had a problem with Cerberus seaching and indexing, we were not able to find tickets by text search, although they were in the database..
Also, most of functions displayed on each and every page are never or only rarely needed, but still they have to be rendered by the server, transmitted over the network and
displayed, which takes precious working space.
Good example:
In GMail you have just simple functions, therefore there is smaller chance for bugs.
Also, on one page you see only functions that you need daily. All other functions are accessible by one click.
Experience #5: Price and Quality
Bad example:
We bought relatively expensive Helpdesk software and we thought that it will mean high quality and increase of efficiency for our support.
Unfortunately, we had to fight with many issues, that slow down support users, or even make it difficult to work with the system.
When we found and reported bugs, we received recomendation that we should buy next release of software, where the bugs are fixed, for another price.
Cerberus Helpdesk is not bad software, but it's not good enough for us for all the reasons mentioned sooner.
Good example:
GMail is free. But the bugs there are very rare, it's unique event when some bug is found.
Ok, Gmail is paid from other Google's earnings, but it shows that even for acceptable or low price you can deliver high quality software
-----------------------------------------------------------------------------------
Conclusion:
SupportCenter has following main features:
- it is based on client/server architecture and page rendering (part of load) is distributed from server to clients
- we try to keep user interface of support agents as simple, intuitive and easy to use as possible - optimized for the efficient support process
- user's see only the functions that are needed in situations they handle
- we transmit only clean data between client and server
- whole user interface is fast with immediate responses from server
- server computes just data and not HTML layout
- trafic between server and client is very low (even on slow network the speed is acceptable)
- we implement just Helpdesk functions and not hundreds of functions that have nothing to do with helpdesk functionality
- we believe that less is more - we think more about every icon, link, button, text, table and all unneccessary elements are not included
:lol:
The answer is pretty simple: There is really no helpdesk software, which cares about user interface of support Agents and offers them superfast, intuitive and easy to use user interface.
here is online demo link:
http://demo.qualityunit.com/supportcenter
u:admin@qualityunit.com p:admin
Current experiences with other Helpdesks:
For more than 2.5 years we offer mail support to our customers for our other products and we need to answer hundreds of tickets per day.
In the past years we used Cerberus Helpdesk.
We had to stop using it, because it blocked our work and slowed down the support process.
In the following section I will explain what we learned and reused in our new Support Center.
I point out the 5 main features, that we need internally in good Helpdesk application and I will show you our results on small comparision of our old Helpdesk (Cerberus) software and GMail.
-------------------------------------------------------------------------
Experience #1 - show agent only the information that is needed to resolve customer's problem in the fastest possible way
Bad example:
Every support system on the market tries to fill application with hundreds of functions (often not needed for a daily work) and display them all at to the users.
We think that this is the best way to draw attention of support staff from real work and slow down the process.
e.g. Cerberus in ticket detail displays so much text, links and sections, that agent needs few seconds to find an information he needs. The same problem with too much information on one page is also on Helpdesk from Kayako.
Good example:
Shining star of all web applications is Google. Google's Gmail has very clean and easy to use User Interface.
Everything is at the right place and in right time...
Their design proves that they really think about every tiny link, how to display it in an useful way and in the right time.
Experience #2 - transmit to support staff's browser just information that is needed for fastest problem resolution, nothing more
Bad example:
A lot of functions on one page also means that you have to transmit a lot of data through the network and generation of final page on the server takes much longer.
When we used Cerberus, it often happend that final ticket detail had more than 1 MB of HTML code. Because of this caused, we had to wait for page nearly one minute.
Good example:
GMail transmits just data that are relevant in time. Therefore responses are fast without any bigger delays.
Experience #3 - transmit only clean data and render HTML directly on client.
Bad example:
Most of current Helpdesk applications based on "old" web technologies generate HTML code on server and this is transmitted to the client's browser with every request.
The result is that maybe 10-20 times more data than actually needed is transmitted, server is overpowered by HTML rendering pages.
Rendering means that server needs to handle not just data processing, but also waste time rendering HTML templates, user interface logic and similar tasks.
All this causes performance losses, because computation of all data is centered to only one point.
In our old system we often saw page expirations, because number of tickets in database and number of computations on one page on server caused timeouts.
Good example:
Speed of GMail is very good. This is caused mainly by fact, that Google's servers are handling just clean data and rendering of data to final HTML page is done at client's side.
This also means that they are able to handle much more users in same time.
Result #4 - implement just functions that are needed for support staff in right time
Bad example:
A lot of functions in application like Cerberus mean big and complicated code, and more bugs, that in return cause that some functions don't work.
We always had a problem with Cerberus seaching and indexing, we were not able to find tickets by text search, although they were in the database..
Also, most of functions displayed on each and every page are never or only rarely needed, but still they have to be rendered by the server, transmitted over the network and
displayed, which takes precious working space.
Good example:
In GMail you have just simple functions, therefore there is smaller chance for bugs.
Also, on one page you see only functions that you need daily. All other functions are accessible by one click.
Experience #5: Price and Quality
Bad example:
We bought relatively expensive Helpdesk software and we thought that it will mean high quality and increase of efficiency for our support.
Unfortunately, we had to fight with many issues, that slow down support users, or even make it difficult to work with the system.
When we found and reported bugs, we received recomendation that we should buy next release of software, where the bugs are fixed, for another price.
Cerberus Helpdesk is not bad software, but it's not good enough for us for all the reasons mentioned sooner.
Good example:
GMail is free. But the bugs there are very rare, it's unique event when some bug is found.
Ok, Gmail is paid from other Google's earnings, but it shows that even for acceptable or low price you can deliver high quality software
-----------------------------------------------------------------------------------
Conclusion:
SupportCenter has following main features:
- it is based on client/server architecture and page rendering (part of load) is distributed from server to clients
- we try to keep user interface of support agents as simple, intuitive and easy to use as possible - optimized for the efficient support process
- user's see only the functions that are needed in situations they handle
- we transmit only clean data between client and server
- whole user interface is fast with immediate responses from server
- server computes just data and not HTML layout
- trafic between server and client is very low (even on slow network the speed is acceptable)
- we implement just Helpdesk functions and not hundreds of functions that have nothing to do with helpdesk functionality
- we believe that less is more - we think more about every icon, link, button, text, table and all unneccessary elements are not included
:lol: