English

custom-support
product
user-experience

Why it’s so hard: Things learned from a bad customer support experience

A recent experience with a company worth billions of dollars showed a negative example of how even a common and fundamental user requirement can be mishandled.

Gao

Founder

7/1/20234 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

As a company that offers cloud services with a product-led growth (PLG) approach, we deeply understand the importance of providing a smooth self-serve experience to users, especially in a mature market or area. However, a recent experience with a company worth billions of dollars showed a negative example of how even a common and fundamental user requirement can be mishandled.

Background

The requirement was straightforward: we were using an email platform called S and needed to enable HTTPS for our email tracking links.

In 2023, I assumed that using HTTPS was a basic feature, considering that 83.2% of all websites default to the HTTPS protocol. Thanks to industry leaders like Let's Encrypt, obtaining and maintaining trusted SSL/TLS certificates is usually not a blocker, and many products can automatically manage them for you.

In the case of email platform S, before enabling HTTPS, the following prerequisites needed to be met:

Step 1. Enable Link Tracking.

Step 2. Set up a valid branded link in the platform, which involves using a custom domain for link tracking.

Step 3. Set up a valid SSL certificate for that domain.

If you're not familiar with these techniques and terms, don't worry. Just remember that there are three steps involved. According to their documentation, once these steps are completed, you need to contact the support team to enable HTTPS.

A frustrating start: Useless chats

In an effort to be a good customer, I came prepared and initiated an online chat session with the support team. Here's how the conversation began (G represents me, and S represents the support team for platform S; content may be edited for brevity):

🤔️ G: I've set up the proxies and DNS records for SSL link tracking in Cloudflare. Can you help me enable the SSL feature? My branded links are foo.io and bar.io.

🧑‍💻 S: Thank you for reaching S support.

🧑‍💻 S: Please refer to the steps to enable Link Tracking: …

🤔️ G: I've already done that. I can confirm it works.

🧑‍💻 S: Please refer to the steps to set up the branded link via Cloudflare: …

🤔️ G: I've already done that, too. I can confirm it works. The only issue is that the links are not using HTTPS. The documentation instructs me to contact support.

🤔️ G: Here's the link I referred to. There's another documentation suggesting the same thing.

🧑‍💻 S: Please refer to the steps to enable Link Tracking and HTTP

🧑‍💻 S: …

🤔️ G: I couldn't find the settings you provided. Here's a screenshot.

🧑‍💻 S: To make sure that it is not a browser issue, can you please use Google Chrome, clear the cache and cookies on Chrome and also try incognito?

🤔️ G: I'm using the latest version of Chrome. Let me try clearing the cache and cookies.

🤔️ G: (After trying) Still no luck.

🧑‍💻 S: Will it be okay with you if I transform this chat session into a ticket?

🤔️ G: Sure.

Several things immediately struck me:

During the live chat, the support engineer didn't understand the real context. The process felt more like "keyword extraction”.
The online support engineer didn't seem trained to handle this particular case.
The online support engineer was referring to an outdated manual that applied to a non-existing (or removed) user interface.
They didn't know which browser I was using (which should be easy to determine from the User-Agent, although not 100% accurate, it would still save time).
Resources were wasted.

“They are not communicating”

The next day, the conversation continued via emails:

🧑‍💻 S: I apologize for the confusion created in our chat session. The UI may have been updated, here’s the steps for enabling HTTPS link tracking:

🧑‍💻 S: (Steps about enabling click tracking only)

🧑‍💻 S: (Three different documentation links to the same topic, which I had already read and followed)

🤔️ G: I've followed all the steps above, and I'm now at the step that says, "Once you have followed the configuration guide for either of these services, please contact S Support to enable SSL click and open tracking for you.”

And after another day:

🧑‍💻 S: I could not confirm your CNAME has been configured as it’s a requirement to complete Step 2.

🤔️ G: The CNAME records were working; otherwise, the Link Branding wouldn't have been verified. The issue is that I followed your documentation, completed both Step 2 and Step 3, but Step 3 removes the CNAME record added in Step 2.

🧑‍💻 S: Please refer to this blog post, I think it might help.

Thankfully, this time a new link appeared. However, to my surprise, the blog post described almost the same steps, and once again, I was stuck at "Contact S Support.”

So, in an almost desperate mood, I sent an email:

🤔️ G: I’m pretty sure I’ve completed all the steps. In every link you sent me, I got stuck at the last step.

Within an hour, I received a response:

🧑‍💻 S: Thank you for your request to enable HTTPS link branding.

🧑‍💻 S: Please be reminded that you need to…

🧑‍💻 S: This case is being given to senior support agents…

And within another hour:

🧑‍💻 S (senior engineer): I confirm that SSL has been enabled for the requested account as it passed our testing as well. All the links moving further send trough that account will be overwritten in https instead of http.

As I received the response, the ticket has been directly closed. Fin. From this exchange, I learned a few things:

The documentation was chaotic, with several guidelines discussing the same topic in different ways. This chaos also extended to the customer support training, causing confusion and inconsistencies.
The support engineer from the S platform treated the customer as if they were unprepared and didn't bother reading the documentation at the start of the session.
While the senior engineer had the ability to quickly enable HTTPS link branding, the junior engineer did not. There was also a significant gap in how to handle this specific situation between them.
More resources were wasted.

Closing notes

This case alerted us to how a bad user experience can waste resources and lead to customer churn. To summarize:

Enable self-service options as much as possible. This is crucial for freeing up resources to build a better product.
Human customer support is inevitable, but relying solely on "keyword extraction" for support engineers is not an efficient approach. Language models like LLMs are proving to be more effective in this regard.
Maintain a single source of truth for documentation. Don't mix things up, as it will confuse both your customers and teams.
Keep all staff members updated on product changes. Treat it as a necessary step in product development.
Identify users who submit support tickets because they didn't read the documentation or have exhausted all other options.

While it took nearly three days to enable HTTPS link tracking on the S platform, I would like to express my gratitude to our team at Logto. The team made it possible that users can set up their custom domains with Logto-managed TLS certificates within just five minutes.

I hope this article has provided some valuable insights. Subscribe to us if you're interested in more topics about product, security, or identity!

Background#

A frustrating start: Useless chats#

“They are not communicating”#

Closing notes#

Background#

A frustrating start: Useless chats#

“They are not communicating”#

Closing notes#

Background

A frustrating start: Useless chats

“They are not communicating”

Closing notes

Background

A frustrating start: Useless chats

“They are not communicating”

Closing notes