Why You Need Integration User Stories

Customers are demanding more integrations out-of-the-box in every vertical of SaaS. User stories can help ensure integrations add real value to the customer. Learn what they are and how to write them for product integrations.
Written by
Elizabeth Garcia, Product Marketing Manager
Published on
July 14, 2023

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.

What are User Stories?

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

Construct Your User Personas

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.

Writing out Each User's Story

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.

Writing Acceptance Criteria

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:

  • Timing - when does the user need the data to be synced between systems? If someone is being notified in Slack, for example, of an important error or customer support ticket, they may need the information in real time for it to be effective. If a user is moving invoices from a billing to accounting software, daily syncs might suffice.
  • Data volume - how much data do users need to be synced? This can be an issue as APIs have limits in terms of how much data you can pull or push in a certain interval.
  • Field mapping - what are the fields in different systems and how do they relate? For example, one app might only have a 'name' field while another might have 'first name' and 'last name.' Or one might have 'groups' for people who enrolled in a class while others will have 'current class students' and 'all class students' for those currently enrolled and those who were ever enrolled (even those who dropped out). Users need to pass this information between systems in the most elegant and useful way possible.
  • User UX - how does your user set up, update, sync, view usage, troubleshoot, and disconnect the integration? All of this has to be accounted for in your integration design.

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.

Latest

From the Blog

Check out our latest content on technology partnerships, integration and APIs. Access research, resources, and advice from industry experts.

Native vs Third Party Integrations for B2B SaaS Customers: Examining the Benefits and Drawbacks

Discover the benefits of native and third-party integrations for B2B SaaS. Learn how they add value to a B2B SaaS business and what to consider when implementing them.

Rethinking SaaS Product Management: Product-First vs. Ecosystem-First Mindset

To meet customer demands and maximize partnerships, product teams need an ecosystem-first approach. This blog explores how ecosystem roadmaps differ from traditional ones and offers tips for implementation.