Do I need multi-product?

The examples below are based on actual use cases we’ve seen with our own customers using multi-product.

They’re designed to show you how you might use multi-product, and more importantly, if you need it.

Hopefully you’ll fit into one of these four brackets. Please note that when we say “products” you might call them “modules” or “categories”. Tomahto, tomayto and all that. 

The quiz below is designed to help you figure out which example applies to your situation. You can then find the examples further down.



Example 1 - For Customers & Employees

Saasy Lassy are a large organization that sell three products to their customers under one brand name. These products can work independently from one another, and as a result, some of their customers only use one, some use two, and some use all three.


When it comes to using Receptive for their feedback management, they are able to use our multi-product feature to effectively compartmentalize these products, treating each as its own product.

This means that customers will only see feedback related to the products they use, avoiding any confusion.

For example, Bob only uses two out of the three products. When he logs into Receptive to give feedback, he can only submit requests for those two products that he uses.


He will only be able to browse and prioritize requests relating to the products he uses. He will see no sign of the one product which he doesn’t use.

From an internal perspective, Saasy Lassy have “product owners” in charge of a particular product, and each product has its own product team.

By using multi-product with Receptive, each product owner and product team can use filters on their Receptive dashboard and reports to only the show the products they are interested in at that particular time.

This means they don’t need to concern themselves with irrelevant feedback requests and data, and can focus on only the data that matters to them.


Example 2 - Just for Employees

SaaSquatch is an organization with a few different products. Their customers are aware of all of these products, and have access to all of them.


When it comes to feedback management, SaaSquatch are able to let their customers view feedback for all of their products.

For example, Jane can log into Receptive and submit a request for any product.


After that, she can browse requests for all the other products, and prioritize accordingly. She has access to each and every product.

Internally, SaaSquatch is structured in a way whereby each product has a “Product Leader” who is effectively in charge of developing that particular product.

By using multi-product, each product is treated as a distinct entity from the perspective of the Product Leaders. The leaders are able to filter the data and view only the feedback relevant to the product they’re in charge of.

Multi-product enables different internal employees to access the data most relevant to them, while simultaneously allowing customers to view all of the feedback.


Example 3 - Just for Customers

SaaShimi have several products, all under the same brand name. These products are not necessarily connected, and as a result a customer might only have one, or a combination, of the products.


Receptive’s multi-product feature enables SaaShimi to limit how their customers submit feedback and prioritize requests.

For example, Andy has bought two out of SaaShimi’s five products. When he logs into Receptive to submit a request, he can choose which of those two products the feedback is for.

When he browses other requests, he will only see the requests submitted for those two products. He won’t be able to see feedback for the products which he hasn’t bought.

Internally, it’s a little more fluid. The Product Managers and teams are not assigned to a particular product, or they move around from day to day.

Instead, they will develop each of the products side-by-side. They need access to all of the data across all of the products, and so they don’t need to use multi-product internally.

In this case, multi-product enables SaaShimi to limit how their customers use Receptive but doesn’t affect how internal teams view and use the data.


Example 4 - Different Products, Different Brands

SaaSCorp is a large corporation which owns several different companies. SaaSOne and SaaSTwo are just a couple of those companies. Both of those companies offer different products under their different brand names.


When it comes to feedback, there’s no cross-over between SaaSOne and SaaSTwo. They are separate entities each with multiple products.

While this may seem like a job for multi-product, the truth is that two or more instances of Receptive will be required for this to work. SaaSOne and SaaSTwo must each purchase their own instance.


When SaaSOne gather feedback on their range of products, they will be using multi-product in the same way as SaaSquatch in Example 1, helping customers and employees find the most relevant data to them.

SaaSTwo will be gathering feedback in the same way, but only employees will benefit from multi-product. Their customers will be able to see all the feedback across their multiple products.

It makes no sense for SaaSOne’s customers or employees to view or submit feedback for SaaSTwo’s products. They’re entirely different things.

That’s why this is not a use case for multi-product and instead requires two instances of Receptive.

If you're going to be buying more than one instance, you should rerun the quiz at the top with each brand in mind.


If you have any questions, please get in touch.

Have more questions? Submit a request


Please sign in to leave a comment.