How do we use Kayako – Part I

How do we use Kayako - Part I

This post lists our requirements for a support system and will be followed up (in our next post) by configuration instructions implementing them in a system of our choice – Kayako.
You may ask us ‘Why Kayako?’ We tried some other systems – open source OTRS, OSTicket and commercial HelpSpot. Below you can find some reasons why these systems were rejected by us.

- no prebuilt list of customers
- sharing is global and is not per portal at this time. So we can not turn on sharing (seeing all tickets for a company) for a client and turn it off for Nerrvana.
- did not like UI
- too complex
- no portals
- no sharing. Each user can see only their own tickets
- no time tracking
- no portals

What are our requirements?

1. We have clients (companies) we design web applications for and we need a support system. Using emails for support is not a viable option for us anymore. We deal with helpdesk support staff in these companies when we talk about support. Do they raise a ticket using their own support system in principle? How well their support department is managed? Do they require to create a ticket or search their internal system before escalating something to us? We do not know. But nobody can stop us from optimising the time we spent on support.

We more often have situations when Brad asks us exactly the same question we answered for Joy a week ago. Or even when Joy asks us about particular problem X, which Brad already raised and she has no clue that some replies already have been sent to Brad. We are doing our best to pick up common questions and move them to ‘How To’, a forum clients can access but despite of it lots of time is spent to find all the emails we sent to Brad and send it to Joy. It is often not enough to find the last email as it might not contain the whole story and if you do so you will have more questions from Joy anyway. Support system on our side with shared access to tickets for client’s staff allows us to find a ticket and forward it or point to a ‘How To’ article and close it.

In some projects an active development phase is completed and support work kicks in as a primary activity. We fix bugs, complete some change requests and answer questions. When you actively develop and support using email it is too hard to figure out how much time goes to support. Very important to know, it is (in yoda voice).

I do not think I will surprise you by telling you a fact that development speed is directly related to how much goes to support. At least in a small team like ours. If we code fast there is no time to maintain documentation up-to-date which causes more questions and more time for support. In this situation we need to figure out ourselves how much support the system we designed requires and what are the best terms for us to negotiate for a future support & maintenance agreement. It could be a fixed amount per month, or by hours actually spent or a combination of them. X amount a month for 20 hours of support with Y amount per hour for anything above 20 hours. So we continue to use dotProject as an internal project management system, phpBB as a place to discuss projects from dotProject as well as a place to discuss projects with clients and replace support by email with Kayako.

2. We created a system (Nerrvana) we are going to launch this year and we would like to have a decent support system accompanying it. Our clients do not even need to interact with the support system UI, but we will. It will allow us as developers to be organised and solve clients’ problems quickly.

Now let’s go from background info into details.

With point 1 (clients’ work) – all is simple and clear. We create in Kayako companies-clients and pre-create all staff members from their helpdesk departments. If changes will need to be made i.e. new person started – head of support will request us using Kayako as well. Kayako has an option to make a company shared which means all users can see and update all company tickets. They log in to custom portal for example and see and update all tickets. It is by company, not a global setting. This is exactly what we want for our clients. Joy will see what we responded to Brad if she works on his ticket. One Kayako install allows you to have many portals and email queues associated with them. You create email, associate it with a queue and create a portal. If you have two clients you will have:

Email and portal
Email and portal

Tickets can be created from inside the portal or by simply emailing it to an associated email. New tickets created either way generate an auto-response containing a ticket ID allocated. By keeping it in subject you will update the ticket by simply replying to it.

Let’s look at requirements for point 2 (own product). Our portal will be on We read ‘Why your company should have a single email address’ and think it makes sense first of all for our clients and decided to go this way. Therefore all places where we will provide email including support will use Each and every email will go to Kayako queue for processing. We are going to send only one auto-generated email (may be only while we are sleeping and can’t reply quickly) as it is important, from our point of view, for a sender to know that their email was delivered. Besides it will be from and it won’t be ‘please do not reply’ but a ‘please feel free to reply’ email. If Kayako does not have sender’s email in database it will create a new account automatically. So an important difference in Kayako configuration for our product will be an instruction to accept all incoming mail for In point 1 (for our contract work with clients) we accept requests only from pre-created by us emails.

The second major difference in configuring Kayako for own product will be enabling and using Kayako API. By using it we can allow our clients to raise support requests from inside our product UI. We can check if Kayako account already exists (we do not create accounts in Kayako when client registers), create it first if necessary and finally create a ticket. Kayako uses MySQL and we store account info in PostgreSQL. After ticket was created via API we can add a private note to it at the same time also via API. It will contain UI page reference where request was created and all supporting info. In our case this will be a test run execution where we can add necessary SQL statements and links to logs to speed up resolution for one of us who will work on this case.

We are also planning to create client’s profile page with information about registration date, account type, short history of activity, business hours and make it accessible from inside Kayako. This will allow us to see if a request came from a new user who can’t launch their first test (our system allows to launch Selenium tests on different platforms) or from a longtime client who might know our system as good as we do (well, almost). To summarize – all such handy info can be added to ticket via API from inside our application.

Finally a few notes about mail server configuration for Kayako. Kayako allows to use GMail account with enabled IMAP but we decided to use our own mail server (sendmail). This decision is based on our belief that Gmail uses multilevel Spam filtering approach and even if we will disable the Spam folder in GMail there is a chance that we won’t see some mail as it might be filtered out by low-level filters. For now we are not even planning to add Spam filter to it (normally SpamAssassin). We do want to have full control around what we receive especially since we use a single email for everything. Even if we will be forced to turn on the Spam filter on sendmail someone will glance over it before deleting emails. For the record, Kayako is also able to detect Spam and has a special folder inside UI.

Cheers for now. Kayako is installed and our next post will be about making it all work in Kayako (expect lots of screen shots).

Print this post | Home

One comment

  1. Arialds Trankals says:

    Greetings from Riga,

    ThankYou very much for this brilliant article which I was looking for! I hope – the next part will be even more eciting to me !

    To be short – I installed Yesterday a new KAYAKO instance having just one clear statement for me – when we are going to publsih an public ONLINE module, having some financial background – there shoud be a well organised user support available. And – there is no needs to creata a bicycle – trying to develop something for these purposes inside of ONLINE module. So – my decision was – KAYAKO and deep integration.

    After this decision and a day spent trying to understand the data organization concepts ( organosation, departments, usergroups, teams, visibility etc ) – I’m happy now to see – my ideas are present within You requirements. And probabbly the proper answeres to my questions are waiting to be read :) .

    Thank You – going to read next part :)