In my second post about Kayako, I would like to show what we managed to achieve. We posted our list of requirements for a help desk system in the previous post. I must admit that the setup took a lot of time we discovered a few bugs in Kayako along the way. Some of them were quite serious. The rest can be classified as defects as it looked like some functionality which was added on top of the existing system and implementation was not well thought through by Kayako.
Almost all errors were fixed by Kayako developers soon enough. However, we had one error which took us two weeks to fix. We exchanged emails with Kayako until they agreed to provide us with their open source code. From that point we tracked the bug within an hour. After setting up Kayako, as we have been making web applications for quite a long time now, our hands itched to make our own simple help desk system. If you are like us, you will understand, or at least will agree with us upon closer acquaintance with Kayako.
In the process of setting up Kayako I wrote as much as 126 posts in their forum. Almost all of them were answered by a wonderful man, a forum guru – Gary, who, incidentally, is not a Kayako employee. Gary had no avatar on the forum and I, being impressed by his experience and desire to help, offered him an avatar, which he gladly accepted.
We were able to achieve our goal. We have one support system that is used for everything we do.
1. Working with clients
Each client has his own Kayako portal.
Fig. 1 Client’s Kayako Help Desk portal
As you can see an unauthorized user can only access the login page. Moreover, the portal is closed with htaccess directly from Kayako (they have such an option). Users of such client’s portals are created by us in advance. The number of users is small and constant for each client. We created special mailboxes CLIENT_A@support.deepshiftlabs.com, served by GMail. Kayako will not accept mail from unregistered users in these portals. The number of such portals is not limited by the Kayako license. Limitations – all the portals will be on the same URL – http://support.deepshiftlabs.com. The only difference is in the parameter / index.php?/CLIENT_A. Ideally we would like to be able to create portals, as http://CLIENT_A.deepshiftlabs.com and suggest Kayako to find ways to license this scheme.
2. Integration with our web service
We have a web service – Nerrvana.
Fig. 2 Our web service help desk portal
Here and below, links from screen shots lead to real pages of our Kayako installation. For some reason Kayako developers decided that one portal user will never visit another one and they decided to keep a reference to a portal template in a cookie. This means that by visiting our portals it will seem that they have broken styles. If you would knew how it hurt during Kayako customisation, especially before we realized that the problem is not in our settings, but in the cookie you need to wipe every time before visiting a new Kayako portal, for example, from Firebug. Another way would be to use different browsers during the configuration phase.
Here you see a portal with all the options available – news, sign up, create a new ticket. In here we do not use GMail and handle incoming emails ourselves. We do not even use a spam filter and Kayako reads incoming emails using IMAP. The highlight of this portal is that it is fully integrated with Nerrvana. To begin with, we have implemented a way for Nerrvana users to create help desk tickets without leaving Nerrvana’s UI.
Fig. 3 Integration with Kayako in Nerrvana
Kayako’s API allows us to create a new ticket, and using API, add to the ticket all the necessary information about the problem that would help to resolve it faster.
But not everything is as it should be, and the problem was to synchronise user passwords. Why do we need this synchronisation? We want to provide excellent user experience. What could be more convenient than having a single password in Nerrvana and in Help Desk? To understand the problem we faced let’s consider a few scenarios.
The potential client (let’s call him “A”) emails the issue to firstname.lastname@example.org. Kayako creates a ticket and a new account. Further, “A” registers in Nerrvana (we assume he uses the same email) and different password. Well, we can change it in Kayako through the API. But what if “A” will go to the Kayako portal and will change the password there?
Fig. 4 Kayako change password form
We cannot disable changing a password in Kayako because the portal is used not only by customers but also by potential customers who do not have Nerrvana account. In addition all portal visitors have access to “Forgot Password” in Kayako, which again allows you to change your password. That is we can synchronise the password changes with Kayako, but not vice versa.
Fig. 5 Kayako password recovery form
I described the problem in Kayako’s forum, hoping that we are not the first who ran into it and luckily, received the answer that satisfied us. It remained only to sign an NDA and get the code of two Kayako classes participating in resetting and changing a password. After that, we created a secret Nerrvana page, which we call after Kayako has finished the password changing operation. This page checks whether this user is also a Nerrvana user and if so – changes the password in Nerrvana.
As a result we have the following working scheme:
- User registers in Nerrvana and does not have Kayako account yet. Nerrvana creates an account as well as an account in Kayako via API, but without sending an e-mail from Kayako. Our email already contains instructions on accessing the Help Desk. Why bombard a new client with two e-mails? Kayako’s API has an option to supress registration email when an account is created via API.
- User registers in Nerrvana while having a previously created Kayako account. Nerrvana creates an account and changes his password in Kayako through the API to match his Nerrvana password.
- The potential client asks a question while not having a Kayako account. Kayako creates his account and sends him his user name and password by e-mail.
- The potential client asks a question while having a Kayako account. Nothing happens. Kayako simply creates a new ticket.
- The user changes the password in Nerrvana or resets forgotten one. We change the password via the API in Kayako too.
- Nerrvana’s user changes or resets password in Kayako. We use our secret script which we injected into Kayako’s code to change his password in Nerrvana.
3. Using Kayako to support software users buy, download and install
We created the first web application in the Startyco set – Answers, which you can buy, download and install. Again, we use the Kayako portal to support our customers.
Fig. 6 Kayako portal to support downloadable web application
(gradient in the header looks pretty ugly on a screenshot)
When you buy our application, we register the purchase in a special small (just 5 tables) database. We record the license granted, its type (trial or permanent and which domain it is issued for), client details. If the account does not exist yet in Kayako, we create it. Accounts can be created before purchase if a potential customer sent an email to us asking some questions. We use the Kayako database to authenticate clients on the site of our product – answers.starty.co, and tables in our own small database to determine purchases and new product upgrades available for download.
There are two possible scenarios. The first – a customer asked a few questions, Kayako created an account automatically and sent an email with account details. We answered his questions, and now, if a customer buys a product he will be able additionally login to answers.starty.co with his Kayako account. On purchase we simply add data we need to our small database I mentioned. The second – a customer buys the product or downloads a demo version. If account was not found in Kayako we create it through the API and at the same time record user information in our database.
When you create a new user via Kayako’s API, you can specify whether to send him an email with account details or not. A password is required for viewing and creating tickets from the web interface in Kayako. In this case, unlike Nerrvana, sending an email is appropriate. A user loads the product and at the same time receives an email from Kayako with access details to our help desk system. In Nerrvana we instruct Kayako via API not to send our own email to the newly registered user, because we want him to have only one email from Nerrvana with all info needed. So if you sell a downloadable product (not a web service) you can simply add your own tables into your database, register new customers directly in Kayako and add additional information in your own database.
Finally, in case if someone wanders into a default portal (the one with no parameters after URL), we have completely changed it by putting more buttons on it, redirecting to the portals of Nerrvana and Startyco. By the way, look at favicons of a client, Nerrvana, Startyco and default portals on screenshots above – we changed them too.
Fig.7 Default Help Desk URL has no portals but links to them
In my next post I try to give step by step setup instructions for the portals we use. Hopefully this will save you some time.
img class=”aligncenter” style=”-ms-interpolation-mode: bicubic;” title=”Client’s Kayako Help Desk portal” src=”http://www.deepshiftlabs.com/dev_blog/wp-content/uploads/2012/03/client_Kayako.png” alt=”Client’s Kayako Help Desk portal” /