Customer Support and Product Integrations: An Interview with Craig Stoss of Shopify

Customer support teams are on the frontlines of customer interaction, and often have the best insight into what customers want and need. Craig Stoss is a support lead at Shopify, and he was previously a director of support at Arctic Wolf Networks. He shared his insights on customer support's experience with SaaS product integrations, and how organizations can best build and communicate product integrations to keep their customers happy.

How important would you say product integrations are to customers of SaaS products?

To me, integration is absolutely vital in this world. We all center our businesses around software, whether Salesforce or a data visualization tool like Tableau. And in order for that to work, it has to be integrated together with all our other tools.

In customer support, for example, we need to have our tools integrated with other departments so when a customer talks to us, we have a holistic overview of their interaction with our company. Customers see themselves as interacting with one company, not a bunch of different individual people. It is critical we execute on that by ensuring information flows across all departments.

From the perspective of my department, seamlessly sharing application and usage data within an organization empowers us to act proactively to benefit customers. If the data the company already has can identify systemic problems, customer support can be proactive and solve problems without bothering the customer. Or when a customer does call in, we can speak informatively and shrink resolution time.

Do SaaS customers frequently reach out to support teams to request more product integrations?

One of the biggest issues support faces is when an integration does not satisfy the use cases the customer has.

‍

It’s very easy to say “my software integrates with software X.” Customers hear this from sales, and they get excited. But then they get upset when they go to use it and discover it does not integrate the way they need it to. This directly impacts support, as they tend to be the entry point for complaints like this.

‍

Marketing and sales have to communicate what exactly integrations can do, and be forthcoming about it. Instead of just saying ‘we integrate with X,’ say ‘we can drive this particular type of use case by connecting A with B,’ for example.

Related Content: Building Product Integrations with the Most Business Impact

Are there other pain points around integrations for customers?

There are often problems with how the API works. Part of it is companies will test small data tests when designing their API, and then it falls apart at scale. I used to work for a company that sold internationally, and we discovered, after a release, that some API commands didn't handle none-Latin character sets, for example umlauts in German, or double-byte characters in Asian languages. A huge miss that caused a lot of issues with our international customers.

Another problem is a bad user experience from an integration that is too broad and generic. When you present the user a huge number of configurations to choose from, and they only want one small piece of it, it is overwhelming.

API versioning has also caused problems, and this is something companies have started to be better at solving. At a prior company that did not use API versioning well, I saw a case where an integration was built to rely on a bug in the API, and when the bug was fixed, the integration immediately broke. Versioning could have easily resolved that instead of spiking support cases when an integration started to fail literally overnight.

At Shopify, you have hundreds of product integrations, some of which meet higher standards of performance and security to qualify for the Shopify App Store. As a general matter, do you think a model of having integrations that are certified, as well as ones that have passed less rigorous standards, is a good model?

There’s a certain level of due diligence in place for companies that are highly sought after like Zendesk and Salesforce, and they often set the de facto industry standards.

Companies should definitely conduct due diligence but it breaks down when the process of review becomes too onerous for smaller companies, and they cannot get to market. It is good to strike a balance between becoming restrictive and protective.

Data security is incredibly important. Users will, and do, quickly tell you if an integration is useless or broken. But a security problem isn't always as immediately obvious.

As someone who has coded integrations in the past, I like when you can monkey around without having to sign up as a developer or pay for a license, and anything you do is restricted to yourself. And then any sort of problems you create do not affect others.

Shopify, for example, allows you to create integrations on your own store for testing, but then to offer it to other customers through the Shopify App Store, it has to go through an approval process.

Do larger platforms still get customers requesting integrations?

Yes, and this tells them something about what customers are looking for and need. There’s a business opportunity for big fish in particular integrations, too. They sometimes buy integration partners, for example, and if they integrate into the next big thing early, there is a competitive advantage there.

Are bad or poorly designed integrations a pain point for support?

Absolutely, as a general matter. Support is customer facing. When a customer calls in and wants an integration use case you don’t offer, the best support can generally do is to feed that request to product and management. Getting that heard and acted on are frustrations within support.

That customer feedback should have a standard and reviewed route into the right people. There has to be a process in place for support to submit the feedback, and have it be acted on in some way, even if it is denied. And support can then be functional in feeding that information back to the customer.

The initial conversations around that are hard to have, especially if sales told them they could integrate with the product. Misalignment of expectations are always the toughest conversations to have. It is hard to reset expectations once things have gone wrong.

‍

In my experience, integrations are a huge area of miscommunication and misunderstanding. The people writing the integration don’t necessarily know the tool they are building into that well, support will refer to component parts in the wrong terminology, and a developer can even build accidental limitations into the integration. This can create a poor experience.

‍

I recently had a situation using an integration with Slack that wouldn’t work in private channels. It did what we wanted, but not where we needed it to. The development team had built an accidental limitation into the integration which eliminated a common use case. If you don’t know how the third party tool is used, you can miss things that would be obvious to your customer.

Related Content: The Pros and Cons of Offering Your SaaS Customers Native Integrations vs Third Party Integrations

Any other common pain point is that within Support, the training focuses on the company you work for. So being able to support a different product, without full knowledge of the product, or even the market space of the integrated product can be difficult. One company I worked for integrated into multiple applications in the same space. A customer called in on one of those product integrations, but the language was so similar to another integration, support inadvertently sent diagnostics for the wrong tool. The customer was upset at wasting time, and the support person was confused because the language and tools were very similar. It is a major problem caused by a lack of training for all product integrations.

What processes would you recommend companies put in place to address these challenges?

If you are the software being integrated into, I would recommend doing due diligence on the integration, making sure it is secure and meets standards. I would require partners to document and explain the use cases. Then I would make sure that customer-facing teams know that that software is part of the store, and what particular value it brings.

If I was building into a bigger partner, I would implement similar things and add more extensive internal training to ensure that the customer-facing teams understand the integration, and will be able to talk intelligently about it, and provide support.

I would also make sure there was an internal license available to use the other software. In the past, I have worked at places where there were no internal licenses so if a customer called in, we didn’t have a customer-like environment to test and understand what was going on. Appropriate test environments are a must.

And finally, when building a new integration, allow your product and development team to speak with potential consumers of the integration. Ask questions lile: How do they use the tool? What is the right terminology? What use cases are most vital to a successful integration? What configurable options should there be?

Do you think the company that builds the integration should own the support?

That’s the default. I think there is a lot of value in Partnering with a capital "P," though.

One model I have seen in the past is white labeling - a company integrates with a software but it is branded so that the customer doesn’t even know there is a third party. In that case, the third party that created the tool gives basic instructions and troubleshooting so the integration partner can provide the first line of defense. If the first line cannot handle the problem, the creator provides additional support behind the scenes.

I also recommend that support leaders have a monthly call with key partners, and just chat and make sure that things are going okay. Communication is vital. Is ticket load acceptable? What feedback are customers providing? etc.

‍

No matter what your model is, you never want to tell a customer “it is not our problem.” I realized this in one of the most poignant moments in my career. One of our customers was having serious performance issues, and my partner at Oracle told me it was coming from them. I told the customer that it was Oracle’s problem. She said, “I don’t give a sh*t, you told me you integrate with Oracle so it’s your problem.”

‍

She was right. You don’t ever want to say it’s not your fault. That’s the maintenance part of the SaaS model. They are paying you to solve the problems.

What else should product and engineering teams consider when setting up their integrations?

A common pitfall I see is requiring the customer go through a complex setup where they have to enter a lot of data, and mapping of things. Integrations should be easy to install and configure. If they’re not, that’s going to cause more load on your support.

Related Content: SaaS Integrations 101: Advice and Best Practices From a Sr.Engineer

Another issue is logging and error tracking. Once, I was working at a company where the phone system had added a new field automatically to their API. It came to my attention two days later that this had been causing it to silently error out as the change had become mandatory on the Zendesk side. Not only wasn't I notified by the phone provider of the change, but there was no way for me to know from the integration itself. That to me is a big failure of the integration that it wasn’t set up to notify me or at minimum send me an error when we lost data. In SaaS, these updates are happening regularly. There has to be better logging or error reporting for integrations.  

Does offering more and better product integrations help with customer satisfaction and retention?

Absolutely. In the SaaS world, before the behemoths like Salesforce and Zendesk arose, most SaaS companies started out doing one thing really well. Many SaaS companies are still like this. In order for that company to work in an ecosystem of tools, they have to play well with others.

In support, you want the best ticketing, knowledge, chat, and QA tools, and you want those to work together. At least three times in my career, integration has been a make or break purchase decision. When I was looking for a phone tool, for example, I went to market saying it HAD to be integrated into Zendesk, because Zendesk is a cornerstone to what we do. Another time,I was looking for a knowledge tool, and it had to integrate with Salesforce because that was our hub of support. There are dozens of chat tools but if it doesn’t integrate into a key pillar, it won’t get my business, no matter how good it is.

If you aren’t integrating with these pillar solutions, you will miss a lot of business.

Being able to work the way I want is important, so if your product makes my use cases easier in the workflow I prefer, I will be more satisfied and renew.

It's true on the other side as well. If the cornerstone apps like Zendesk or Salesforce didn't enable integrations to be easy to create and accessible to their customers, they may not have the success they do today.