You've built integrations between your B2B SaaS product and other apps your customers use. Everything is going well. Your customers are happy, and you've checked the boxes for multiple items on your roadmap. You can rest now; there's nothing more to – wait, did somebody say "support"?
Yes, even first-class software requires support. And the more integration customers you have, the more critical support becomes. The key is figuring out how to provide excellent support without having it overwhelm your resources.
We'll use this post to examine what makes up a good integration support strategy, but first, let's look at the basics.
What is integration support?
Integration support is the day-to-day service your customer support or success teams provide to your customers as they select, activate, enable, authenticate, run, monitor, and otherwise use your integrations.
Integration support is necessary because it is not possible to build integrations with every function fully exposed to customers who completely understand them. To address this, integration support bridges the gap between your customers' understanding and capabilities.
Integration support is also called integration management, as it focuses on how your teams manage integrations for the benefit of your customers.
And, while there is overlap between maintenance and support (a maintenance issue can trigger a support issue, and vice versa), integration maintenance is work that your technical teams, such as engineering and DevOps, do behind the scenes to keep the integration running smoothly. Integration maintenance includes code updates, upgrades, security patches, and backups.
Challenges of supporting B2B SaaS integrations
As with anything, integration support comes with its challenges. Here's a short list of those challenges:
- Scaling – Setting up efficient processes and keeping them efficient is essential to scaling your support. Unless you're okay with being a services company instead of a software company, you can't expand your services team by one person every time you sign on another ten customers.
- Auth – Getting and staying authenticated is critical for integrations. But it's often not easy, with APIs having timeouts (which could be just a few minutes), many different types of auth being used beyond OAuth, and your customers struggling with credentials.
- Logging – Black boxes are great in stories. But integrations exist in the real world. Tracking what is going on with extensive logging makes the difference between support teams that need to get engineering on the phone every time there is an issue and support teams that can provide the support your customers expect.
- Monitoring/Alerting – In addition to logging, integrations need to call out when things go wrong (or when they go right).
- Error Handling – Integrations are going to run into problems. Even if you could build an integration with no internal errors, you'll still need to handle the situations where the third party changes the API, adjusts auth, or modifies something else.
- Documentation – We'd all like to have SaaS apps that are so easy to use that no one ever needs to ask questions. For all but the simplest systems, that's not realistic.
- Self-service – Everything in the above list benefits from self-service. Anything you can successfully guide your customers to do themselves lessens the work needed from your support team and company. But self-service is often the last thing product and dev teams consider when building integrations. Instead, the focus is usually, "Just get it to work; we'll worry about the other stuff later."
Key goals of an integration support strategy
Integration support is often reactive. You are taking care of integrations and customers that are already in place. However, keeping support in mind as you build and deploy the integration can make all the difference for your support team.
In truth, 90% of support is getting things right before the customer calls with questions or concerns.
Productize your integrations to scale customer support
Until recently, building SaaS integrations meant coding them one at a time, customized to the specific customer who had requested them. As a result, many customer support/customer success teams have been overwhelmed with the need to support dozens/hundreds/thousands of integrations that are 95% the same. Unfortunately, that 5% difference leads to a need for separate documentation and support processes that don't easily scale.
How do you avoid this common issue? By building integrations to handle the 5% delta in customer requirements via custom configuration. Every customer has the same integration (making the overall support much simpler), but each customer can configure parameters to suit them. Some customers want a single-direction data sync; others want a two-way sync. That's fine. Set up the configuration so customers can pick the sync method that works for them. Some customers may want Slack notifications as the integration runs, but others only want to know if the integration ran successfully. Again, include the notifications in the configuration and let everyone pick what they will.
Then, provide your customers with a marketplace, where your integrations are clearly defined and documented.
Let your customers view, sort, select, configure, and even activate those integrations without any assistance from your onboarding or support teams.
When you productize integrations, your devs only need to manage one set of code for each integration, your support team doesn't need to keep track of scores of almost-the-same variants, and customers are empowered to select and configure the integrations that make sense for them.
Build for the data and documentation your support team needs
Supporting integrations is hard work. By design, an integration is connecting two or more disparate systems. Each system has its own rules and quirks. And third parties reserve the right to change anything at any time, no matter how many integrations are based on the current setup.
But if your support team has access to the integration, integration support data (errors, alerts, and logs), and good documentation, that changes the equation in a big way. Unfortunately, integrations don't naturally arrive complete with support data and documentation.
You need to ensure that your dev team is not only building the integration to move data from system A to system B, but that development includes capturing error conditions and generating valuable errors. Receiving an error that says, "Remote server XYZ is unavailable," is far more helpful than "Process ABC123 terminated unexpectedly."
When logging, you must be careful to capture enough information to be helpful but not so much that you run into PII and security policy issues. To do this, you'll need to work through the type and level of data your support team will need to troubleshoot integration issues successfully. If every integration issue is immediately routed to devs for resolution because your non-devs don't know what steps to take, your integration logs probably aren't detailed or accessible enough.
Making it so you can add custom monitors and alerts to your integrations might take things to another level of complexity. However, doing so provides data that's essential for keeping interested parties current with an integration's status and providing starting points for troubleshooting integration issues.
And finally, remember documentation. You want to build the integration so that it's intuitive. But there will always be those users (whether internal support staff or customers) who need a bit of extra handholding or additional explanation. If you don't plan documentation when building the integration, it's far harder to bolt it on later.
Let customers do as much as possible with their own integrations
We've discussed letting customers work with your integrations via a marketplace, but that's only the start. Everything that customers can successfully handle themselves means less work for your support and dev teams.
Beyond the marketplace (and selecting and activating integrations), how about providing your customers with support data for their integrations? Give them a dashboard to access integration logs, set up monitors and alerts, troubleshoot, and even replay integrations that aren't working correctly.
For the ultimate customer self-service, you could even provide them with the ability to build their own integrations with your product, either by using a template or starting from scratch. This is particularly attractive in those scenarios where customers would like custom, one-off integrations with your product, but you don't see the broader value in having your team build those integrations. But, for those customers who want to, you should empower them to build and support whatever integrations they require, while not adding to the workload for your support team.
Prismatic can help with integration support
As a market-leading embedded iPaaS, Prismatic can provide your dev and support teams with the tools and processes necessary to address all your integration support requirements.
From managing the infrastructure providing needed support data, and empowering your customers via the marketplace and embedded designer, we are focused on helping B2B SaaS companies maximize their integration potential.
"It's been a game changer to give our customer success team and our technical support team access into Prismatic so they can look at logs and provide better customer support."
Schedule a demo. Let us show you how Prismatic can make your integration support far more efficient and smoother than you thought possible.
