For some strange reason I had this impression that if you are shopping around for a software application, and found one with a really elegant, modern user interface chances are very good that the engineering behind the system will also be bestowed with the same level of attention to detail and quality.

Boy am I wrong. Kayako is a ticketing system that seemed great on the surface. Their main web site, as well as the Kayako application itself seem modern, well designed and Web 2.0 based - all atributes I liked a lot. Their support is responsive and that tells me a lot too about the effort these people must have put into designing and supporting this system.

However the devil is in the details. Once I started using the system, I picked up three problems. One I will discuss on a future date, the other two are quite horrible.

1. There is a facility to support emailing of new ticket requests and responses to the system, and it does that by polling an IMAP mailbox account you define. However, even though you as administrator can define this mailbox, you cannot get the system to actually POLL this mailbox except by logging a support ticket and asking them to add a polling cron task. That sucks. How many people will know to do that and not just sit there wondering why it does not work? Wasting hours of time troubleshooting connection details?
2. Continuing with the way emailing is implemented, whenever something happens on a ticket the system will submit an email notification based on the configuration you defined, to various recipients. The problem is this:

   

   
   When I tried to update the status of a ticket to closed, the system (correctly so) tried to send out an email notification to the ticket owner. However for some reason their network experienced some temporary error and could not connect to the port, even though it was open. So I got that error.

The problem with the way they deal with email is that it seems to be synchronous and not asynchronous. Whenever a computer program is supposed to process a potentially long running task, or a task that might encounter transient failures, it is critical that the task be scheduled for asynchronous processing - assuming the results of that processing is not required immediately. This has two benefits:

1. By decoupling the potentially long running / error prone task from the main user interface, the user does not have to wait for the process to complete. This makes the user interface much more responsive.
2. By decoupling it, transient errors can be retried in the background for a set number of times and potentially avoid a fatal error like above.

Remember, nobody cares in this system if email is delayed by 5 minutes - email is inherently asynchronous and non reliable so it makes no difference. However, now I have a ticket in closed status and the ticket owner has not been notified. So now I have to manually send out an email to inform them of the ticket status change. Not good.

Even worse, the cron task that polls the IMAP account for new submissions suffer from the same problem. It reads the IMAP folder, deletes the emails from the IMAP folder, then tries to submit email notifications. If the SMTP calls fail, you will never receive those emails. This includes user registration details such as system assigned passwords. Whoops!

I just wish life was more transparent. I want to believe what I appear to be observing. Now I have to dial down my level of trust by 10 clicks. Not nice.