totally hacked off with kayako's email system

[netgroup]

tested and tested and tested again and again (almost a year of using this product now - build 3.4.10 at present) and we've decided email and kayako don't work together. We are moving to login and web based only support.

Oh pop3 and piping we can get working, but for some reason which we can't replicate) when some clients reply to a support ticket staff response via email, instead of replying to the system support email address (an active email queue address) they reply to the staff notification email address, thereby totally bypassing kayako completely.

Now, like I say, when we submit support tickets as tests, and reply as staff, then reply to those staff email responses via email, it works perfectly......as expected.

But every now and the (about 1 in 5) customer replies come back to the staff mailbox directly.

Conclusion is that some email clients can't interpret the reply email in the headers, so we are stopping all email replies and reverting to forcing customers to login to submit replies via the ticket thread in their browser.

What's the point in spending so long at setting up email piping or pop 3 etc, for it to be unreliable and unworkable?

[Digital Mayhem]

ours is reliable and workable.. we have never experienced this issue.

[netgroup]

Originally Posted by XeSolutions

ours is reliable and workable.. we have never experienced this issue.

Have you any idea then how it is (and what have we done wrong) that causes some of our customers to see our staff members private email addresses in staff replies sent from kayako rather than the support email queue address?

Any help appreciated.

[skaye]

Originally Posted by netgroup

Conclusion is that some email clients can't interpret the reply email in the headers, so we are stopping all email replies and reverting to forcing customers to login to submit replies via the ticket thread in their browser.

Shouldn't you be able to do some investigation on your theory and see if what you're experiencing is a configuration issue or a bug? I mean, you have a perfectly good theory, so when you get an email that's gone the wrong way and you suspect its their mail client, why not ask them which mail client they used to respond with. Think about it, you're suggesting that 80% works fine, so maybe the 20% are people using Thunderbird or something else. If you could find the root cause and present it as a bug then it could get fixed and your time spent setting it up wouldn't be wasted.

Just my $0.02 worth.

[netgroup]

If I could be that certain, believe me, I would tell.

As I say, we can't replicate the problem here so I turned to the community as a last resort and when you hear from people like XeSolutions that they have never had a problem, what hope have we got?

All customers have used OE, yet it works for us.

We've tested thunderbird and several webmail clients, and all work as they should, for us.

So if no-one else is having the problem - maybe its my setup?

Baffled.

[skaye]

I'll start by saying I have absolutely no idea what's causing the problem, but from reading what you've said then maybe you need to look up the chain a bit.

If all clients are using OE (same version I presume) then perhaps whatever POP3 or IMAP server they are connecting to is having the problem. Maybe some of them are using Spam filtering systems like MessageLabs or Postini that can sometimes be too clever by half.

Before you start looking at your config (remember it works 80% of the time) you should eliminate the other side as a possible root cause.

Happy hunting.

[netgroup]

Thanks for the feedback.

The point is though, if its not in the kayako system where the problem lies, there's not much chance of me being able to do anything about it if it's third party email clients and spam software/servers that are messing things up.

The object of my post is to find out if other people are experiencing the same issues.

Here's the bottom line:

1. If I or my staff reply via the browser in e-support, approximately 80-90% of customers receive the proper reply email in their email response. It's the 10-20% that don't that causes serious customer dissatisfaction and lost productivity on our part.

2. If I or my staff reply via the pda/ interface 100% of emails sent out from kayako include the staff's personal email address. VERY BAD!

3. If I or my staff reply via the kayako mobile software, again 100% or emails sent out from kayako include the staff's personal email address and not the kayako email queue for the dept they have contacted. VERY BAD!

At this moment in time, I'm convinced that my config setup is 100% correct and that point 1 above, is being caused by third party software - which I nor other kayako users can control.

Points 2 and 3 are bugs which have never worked in the pda system and which I had hoped would have been fixed in the kayako mobile system but aren't.

That's my perception of things at present and if anyone disagrees, please let me know as I'm drawing blanks everywhere else I look.

If anyone else has the same experiences, then please post them here so that kayako can see that more than 1 person here has an issue that needs addressing.

Happy New Year Folks!

[keliix06]

I can say 100% when using 3.04.10 and replying via /pda as staff, replies to that email are sent back to the staff email address.

Haven't noticed the bug when not using /pda