Customers are demanding more integrations out-of-the-box in every vertical of SaaS. But offering a bad product integration is usually worse than no integration. User stories can help ensure integrations add real value to the customer.
Integrations can fail in three fundamental ways: 1) they are hard to set up, install, and manage 2) they do not sync data or return errors or 3) they do not accomplish what the user needs to do.
When any of these happen, customers will have a frustrating experience. They may respond like this (reviews left on SaaS product integrations):
So how do you prevent this from happening? Before you even start building (or approving) an integration, you should map out integration user stories.
Related content: What Are Integration Partnerships? All Your FAQs Answered
To do this, you should gather input from sales, marketing, product, and customer success on how customers are using the product and what their other systems are. Beyond asking your customers, you can use data enrichment tools to find out what tech your target users are already using.
Once you have a good sense of your users' tech stack and workflow, ask your customers if your mapping is correct and if there are other ways they would like to connect systems.
.png)
The basic form of a user story is “As a [role], I need to [task] in order to accomplish [goal]” and there is no reason to deviate from this model for integrations.
Once this big picture is established, you will need to get more granular in how these integrations will be used. Remember that your customers might not always know how they would like to use systems together, and it is your job to figure out what business logic will best meet your users' objectives.
Sometimes these configurations will be quite simple. For example, a story might start, “As a marketer, I need my different lists from my CRM to sync with my audiences in my email marketing automation so I can track all my communications from my CRM.”
Flushing this out in more detail, you should specify that your marketing users want to be able to bi-directionally sync their different “lists” of contacts with “First Name, Last Name, Email” from your CRM with their different “audiences” with the same fields in their email marketing platform. This configuration is relatively simple.
In other cases, depending on your app and your partner’s app, what some of your customers want will be much more complicated.
The goal should be to identify the configurations your customers need so you can build a UI where your customers can self-serve AND your users can accomplish what they need to.
Related content: Designing and Scoping User-Facing SaaS Integrations With ShipBob
Depending on your app, you may have different users. For example, a CRM might have a marketing user, a sales user, a business dev user, and a developer user. An Applicant Tracking System might have a recruiter user, a HR executive user, a hiring manager user, and a benefits admin user.
It is important you identify all the major users of your product so you understand the different integrations and configurations that are needed.
Most likely, your product and marketing teams already have these user personas developed. You should also touch base with your tech partners to see if there is an additional user persona that they might bring to the table.
Once you have all the user personas, write out the different ways each user would want to use the integrations and why. Just like before launching any new key product feature, you will have to talk to your product, sales, customer success, and product marketing people to try to establish these stories.
Most likely, they will evolve post-launch as you get more customer feedback.
First write out all the high level stories in the form of “As a [role], I need to [task] in order to accomplish [goal.]”
Once these higher level stories are established, you should write out “acceptance criteria” for each one. Acceptance criteria simply spell out what needs to happen to make sure the user can accomplish their goal.
Let's say I spend most of time working inside my CRM, but I use an email marketing platform to send out special promotions to prospects and customers.
As a result, I have segments of contacts in my email marketing platform that I also have in grouped in my CRM. I want these lists to remain identical even as I add contacts to both systems.
I also want to be able to track performance of emails sent from the email marketing platform from inside my CRM as the CRM is where I track my results from all my email campaigns.
In this case, the acceptance criteria is the list of things that need to happen to make all that possible. For example, I need to be able to regularly sync contacts entered into either system and have them de-duped. I need my email marketing platform's audiences synced with my CRM lists, removing any duplicates.
I also need to have emails sent in the email marketing platform logged in the CRM, and their reporting metrics logged at the audience level in the CRM.
Writing out what needs to occur to meet a user's objectives will help inform the integration design.
Integrations are limited by the design of your API and your partners' APIs. You might not be able to deliver every item. But thoroughly understanding what users are looking to happen can ensure you have the best possible integration design.
Here are elements to look out for in drafting acceptance criteria:
Once you have established your user personas, stories, and acceptance criteria, you should work closely with engineering to ensure that the integration design meets as many of the criteria as possible. If you want to see a sample integration user story and acceptance criteria, download a sample here.
