How should I configure modules in Receptive?

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

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

Hopefully you’ll fit into one of these four brackets. Please note that when we say “modules” you might call them “products” or “add-ons”. 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 modules to their customers under one brand name. These modules 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-module feature to effectively compartmentalize these modules, treating each as its own product.

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

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


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

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

By using multi-module with Receptive, each module owner and product team can use filters on their Receptive dashboard and reports to only the show the modules 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.

Find out more about how to set up your modules in Receptive.  

Example 2 - Just for Employees

SaaSquatch is an organization with a few different modules. Their customers are aware of all of these module, 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 modules.

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


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

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

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

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

Find out more about how to set up your modules in Receptive.   

Example 3 - Just for Customers

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


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

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

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

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

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

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

Find out more about how to set up your modules in Receptive.   

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 modules 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 modules.

While this may seem like a job for multi-module, 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 modules, they will be using multi-module 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-module. Their customers will be able to see all the feedback across their multiple modules.

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

That’s why this is not a use case for multi-module 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.

Find out more about how to set up your modules in Receptive.  

If you have any questions, please get in touch.

Have more questions? Submit a request


Please sign in to leave a comment.