[chucky123]

The problem isn't live chat. The problem is incorrectly implemented live chat.

I run a small saas and I can't count the number of times someone messaged an inquiry and I immediately got in touch with them. They were astounded by the quick response time, which is simply not possible with contact forms.

[onion2k]

They were astounded by the quick response time, which is simply not possible with contact forms.

I'm intrigued. Why isn't it possible with a contact form? The mechanism for routing a message to you could be literally identical whether it's a chat box or a form. You could get the exact same notification on your system. It'd take you the same amount of time to respond. The only difference I can see is that what you reply with would go to the chat window in their browser instead of their inbox. Perceptually they may see that as faster I guess but it isn't really.

However...

I run a small saas and I can't count the number of times someone messaged an inquiry and I immediately got in touch with them.

What you presumably don't see, or at least ignore, is the number of times people didn't get an immediate response from you and were annoyed by it, or were annoyed by the chat option being there in the first place, or who didn't even see the chat option, or whose browser failed to load it, or... well... lots of things.

Your claim that users like it is simple survivorship bias - you're only focusing on the positive outcomes.

[mschuster91]

> I'm intrigued. Why isn't it possible with a contact form?

- E-mail always has a round-trip latency attached, even the best systems will have at least a minute, and you have to do insane amounts of work to keep up with "deliverability" as automated anti-spam systems can and will detect high frequency of incoming emails and downgrade your score, not to mention you have to deal with bullshit like contacting providers that downgraded or outright black-holed you.

- Uploading or sending attachments is a hit-and-miss, there still are providers limiting attachment size to 1MB (looking at you web.de) or with overzealous "security software".

- People will readily ignore the "do not reply below this line" and reply inline, which software like JIRA SD won't recognize or garble up.

- On mobile, people will have to switch between apps, which more often than not even on flagship devices leads to Android killing off the apps between switching for "memory efficiency" and 10+ seconds of load time after each switch.

On-site chat has none of these problems.

[onion2k]

Email certainly has its flaws, but none of that has any material impact on how quickly chucky123 can reply to a contact form rather than a chat window. A contact form on a website just sends a POST request to a server, and then that server notifies chucky123. The process could be identical to using chat in that respect (it often isn't, but we're talking about a specific instance rather than the general case.)

If chucky123 replies to the notification immediately via chat or via email the user should get pretty much the same experience. Suggesting this is a benefit of chat doesn't make much sense on a technical level. It isn't. It's just a benefit of replying to contact requests quickly.

[denton-scratch]

> "do not reply below this line"

If you're going to use email for customer interactions, then respect the conventions of email. I will reply below whatever line I choose. If your software doesn't support that, then answer the phone.

[chucky123]

On point. Plus the fact that chat has conventions that closely related to how we talk naturally vs etiquette based emails means that you can drop a whole bunch of charade and just talk to your users naturally.

[wruza]

Another factor is not everyone is a hacker who reads their email after sending a form or understands how all this works in the first place. Most people have {e|g}mail because it’s that sign-in thing that their hacker relative set up for them.

Another big chunk of people doesn’t get that they can tap on a chat button, that’s why it flashes and pops up automatically or after a timeout of inactivity, which means a user is probably confused.

I wish there were levels of accessibility in the web tech. So you could specify not only whether a user can see or hear at all, but also select from few levels of computer knowledge, from beginner to confident to 30 years of software development, so everyone could get a reasonable experience.

[SamuelAdams]

Actually I wonder if this could be a growth area for Slack. E-commerce chat.

I had to chat with Verizon reps yesterday to set up my phone. They asked for my device ID or some other configuration numbers. I sarcastically put in 11023 <a lot of zeroes> 47781 (number is fake for this example).

And what appeared in the chat was 11023 47781. The chat app truncated anything between <>. Probably an attempt at XSS protection. But not the behavior I was expecting.

So if a company doesn’t have the capacity to do chat well, why not outsource it to a company that can? Make the integration easy, style the pop up to each company that uses it. Boom, new revenue stream.

[troupe]

If I'm browsing an SaaS and see a chat box that says someone is online. I'm much more likely to ask a question to the chat where I would otherwise just leave without trying to contact support in another way.