Desktop comparison to other Live Chats

I've been a Kayako user for about 4 and a half years. I had to switch to another live chat vendor because the chat in v3 didn't consistently enough. I am still on v3 for the ticket side of things.

I'd love to switch back when I upgrade to v4 so it's all integrated again.

Is there anyone using Kayako desktop in an environment with 10 or more concurrent users? Does it work reliably? Missed chats from the technology not working are unacceptable. I have a hard enough time to get the humans to answer.

A quick glance in the forum here says there aren't that many problems, but nobody mentions anything about their load.

Thanks for any replies!
Mark

Compared to Kayako Live Chat 3.x, in the new one I really need these, but they are not there:
1) Time elapsed since chat started. Now I have time stamp for each line, which I really don't need, but I don't have the total time of the chat anywhere.
2) Sometimes I chat with 2-3 customers at once. In the old version, I could have separate chat windows for each chat. Now it is not there, only tabs.
I have a LARGE monitor, so having separate windows was a big help.

Is it possible for these features to be added in the future? Any time frame for it?
Do I need to create a Feature Request for these?
Thanks!

I tried it out. v4 chat uses a tremendous amount of resources with just 4-6 concurrent users.
There are some intermittent bugs too like repeating lines of text that we haven't been able to track down.

+1

Jamie,

Sorry for being a stick in the mud, but my impression is that the KD team isn't very responsive. I've been struggling to get to the point where we can deploy chat at all on our system due to major limitations/defects including:

1. "Push uploaded image" results in two pushes (one good one, and one "bad" URL with just the filename). There are two JIRA incidents for this, and neither have been fixed.
2. Pop-up chat window doesn't get passed the user's authentication for logged in users, so chat departments cannot be restricted to certain user groups. This is a major defect. We can't deploy chat without this being fixed. While I can produce a workaround for this by passing cookie information, I don't want to write too much custom code solutions just to get basic functionality. Our company has different teams supporting different groups of users. We MUST be able to restrict user group access to chat departments and not just restrict the display of the chat button.
3. Major memory leak in KD. This has been reported for a while, and there doesn't seem to be a resolution on the horizon. Our staff must re-cycle KD on a regular basis to keep it from eating their machines.

Since we haven't gone to production with chat, the other issues reported such as duplicate entries aren't something we've seen very much. However, these other reports aren't improving my confidence. When I look at JIRA, I don't see some of the obvious defects that have been reported (i.e. where's the JIRA for the memory leak?).

Part of the problem is that the support team doesn't seem to be familiar with KD at all. I engaged them to ask how click-to-call worked, and the answer they gave (after two-levels of support were engaged) was completely wrong. They didn't have a clue what the feature does or what the customer/staff experience during a click-to-call engagement looks like. When the support guys don't understand the product, issues get "translated" to incorrect defect descriptions, and then they never get fixed. The push uploaded images issue is a classic example of that (the issue got translated to "the URL displays the local path to the file", which isn't what is happening and as a result the proposed fix doesn't fix the problem).

I know your company is working hard to try to fill out the Kayako V4 product. It would be nice if more effort were being put into Engage, and ever nicer if there were a real effort to get Fusion to work as a coordinated product rather than two products that live side-by-side.

Leif

Jamie,
I sent in a ticket a few months ago. I used the super secret protocol spy and sent in the log that clearly said "failure" on a bunch of lines and the support people told me it was acting properly.

While we are "at it" , let's include other chat issues/functions on this thread. Here's my list.

1) The pop-up alert info is useless if your client base is spread across time zones since it only lists Country rather than City/Region. Country is useless if you have customers across multiple time zones.
2) Time zone should also be displayed in main list view as a column entry; same reason as above.
3) Alert only rings once for each round-robin pop-up; needs an option to ring like a phone (continuously or every X seconds).
4) When you click on the alert it should go directly to that chat window (which it does) and show a History tab at bottom (which it doesn't); clicking on History tab should display the last chat log for the visitor with option to view other chat logs in newest to oldest order (title by original question; click to view contents).
5) Instant chat histories for returning visitors should be displayed in main KD list view similar to above (History tab next to Footprints); could link based whether the visitor has logged in or by their IP address (registered or not).
6) Custom text fields added to the pre-chat form should support browser auto-fill based on last visit (just like Full Name and Email work now).
7) Chat should support a notification option just like new ticket notification works (emulates SMS by entering text address for the chat operator's phone).
8) Chat should should have a mobile app option just like tickets do now (independent of KD).
9) You should be able to turn a chat log or selected portion into a KB article in two clicks (save as draft as default).
10) Time logs for chat sessions should be a standard report (by company/organization or IP address).
11) Map view should include time zone overlay along with day/night shading for quick reference.
12) KB search results exposed to chat visitor during chat request or at least exposed to the staff operator or one click away (search keywords in question).
13) Should be a close chat option in reply box icon strip as well (X); shouldn’t have to go to top menu bar when you are already working at bottom of screen.
14) Chat toolbar should include emoticons option and support text string to emoticon; Example, should display as .
15) Typing monitor ("xxx is typing") in KD should be placed elsewhere so it does not cause the chat log in progress to jump around; placing to right of chat toolbar icons makes the most sense (easy to see).
16) Chat tab icons should visibly alert you to visitor replies such as change icon color or blink; otherwise you can't tell who to respond to next when multiple chat sessions are active.
17) You can't locate a KB article quickly in KD and send a URL link to that article in chat. Instead you have to open up another browser window, login to your helpdesk (if private a KB), locate the article, copy and paste the URL from the browser window, then move back to chat to paste and push the URL. How crazy is that? This should work in 2-3 clicks including auto-search the KB based on visitor's question keywords (or chat operator entry), select appropriate KB article, then click a button to populate Push URL box.

Anything else?
I realize some of these are feature adds, but some are simple tweaks (few lines of code), and many are must-haves.

What I'd give for an auto-accept chat feature....

We can configure the way the chat timestamp displays for the agent, but not for the client.
It uses 24HH:MM no matter what setting I've used.

Skill based routing is a GIANT pain. If I want the chat to go to Agent A, then Agent B, then Agent C, then finally anyone in that dept, I have to define 3 skills, assign all of them to Agent A, 2 of them to Agent B, one of them to Agent C, then create my chatnow buttons to have all 3 skills. And the skills don't work in the invitation at all, so we've had to write our own invite .

A bigger feature request would be to chat in separate windows again. The tabs allow my agents to hide the chats while working on something else.

I have a laundry list like masterctrl1 written down. Those are the first ones that come to mind.
Mark

You want your KD operators to engage without accepting first?
I suppose that's okay if maximum chat limit is set low in KD and the operator is glued to their screen while "online"
Otherwise it's handy to view the question first in case another operator is more capable of replying through round robin alert to next available operator.
Which reminds me -- chat assignment rules need to be improved in Admin CP as well.
You should be able to disable the round-robin default.
Here's a list of suggested setup options based on what other chat services offer.
A - To All Operators = Chat alerts will be passed to all online operators. [THIS SHOULD BE THE DEFAULT]
B - Random = Chat alerts will be passed to the randomly selected operator.
C - Load Balanced Random = Chat alerts will be passed to the less loaded randomly selected operator.
D - Round-Robin = Chat alerts will be passed to the next operator, selected in a round-robin order.
E - Load Balanced Round-Robin = Chat alerts will be passed to the next less loaded operator, selected in a round-robin order. [THIS IS WHAT KAYAKO DOES NOW]

Just adding the A option would be sufficient for our purposes and I am sure others would like it to work this way too.
Another setup option could be _Auto-accept, that should probably be a KD setup option rather than Admin CP.

A is impossible with the current chat implementation. It would require an entire rearchitecture (let alone rewrite) of the chat engine. The desktop clients refresh every few seconds, so multiple people could accept the chat in that window of time and it would have no idea who actually accepted it first. Then it would have to notify everyone else that they didn't get the chat after they've accepted it.
Mark

Okay, but isn't A a common option with other chat services?
Is this one of the reasons you are using a different chat now?

I've only seen it on phone systems not chat. I don't remember seeing it on any of the big chat providers we demoed a few months ago.

I don't think simultaneous alert to all qualifytng available operators is hard to pull off code-wise.
The A-E list above is from a popular chat provider and A is the default.
As soon as the chat is accepted by an operator, the alert disappears. If another operator tries to select the same chat while the alert is displayed, it disappears and nothing happens.

duplicate post

A bigger feature request would be to chat in separate windows again. ----> +1 for this.

More feature adds:

• Chat replies from operator should cause client side form to float to top or at least cause the browser icon to flash in the taskbar.
• Autogroup chat tabs based on IP address (same organization).

More feature adds:

• Auto-clear chats that have ended after X seconds (user-defined X, 0 = manual clear).
• When a chat ends, show a slash over the tab icon, so it is obvious the chat has ended.

What are the symptoms or easiest way to test for the memory leak?

We see the duplicate line issue almost daily and I don't think the spy log will list anything useful since the problem occurs on the client side (you have to be viewing visitor's desktop to see it).

The biggest flaw I see with Kayako is that Fusion exists only as marketing scheme. Engage + Resolve are separate tools that don't really talk to one another.
Until Kayako connects the dots, the combined solution is awkward to use and downright frustrating when you see the potential to do so much more is clearly possible.