Limitations of customer users

There are crucial differences between team users and customer users, and inviting internal teams in as customers can lead to some limitations.

Value for Every Team in Your Company

One of the reasons Receptive works so well is that it provides value for your whole organization.

Product managers can look at priorities and decide what to build, Success managers can see which customers are getting what they want, Sales can see what you have planned and share that with prospects.

If you add your team members as customers, they can't access any of the core functionality of Receptive. They won't be able to access the reports, and they won't have any visibility on metrics, engagement, or customer insights.

This effectively means your organization won't be getting as much value from Receptive as it could be.

Incorrect Reporting Data

Part of what makes Receptive so unique is that you can always differentiate between feedback from your various stakeholders (teams, customers, and prospects).

All of these groups are likely to have different priorities, and these are easilydistinguished in your Customer SmartList, Prospect SmartList and Internal SmartList.

If you add team members into Receptive as customers, then your Product team will just have a jumbled mess that they can't possibly analyze. They'll lose all of the insights that CS and Sales teams can provide because they won't be able to tag requests.

Not only that, but if you're letting team members vote on behalf of customers then you don't actually know what your customers' priorities are.

Ultimately, you'll reduce the impact of Receptive on your product decisions, and will give your Product team more manual work to do.

Submitting Feedback for Customers and Prospects

A key feature of Receptive is that it enables your customer-facing teams (Support, Sales, etc.) to submit feedback on behalf of your customers and prospects.

This means all of the feedback is kept in one place and is especially useful if you use Receptive internally-only. It streamlines the process and ensures all your feedback is kept in one centralized database.

If your team members are using Receptive as customers, then they'll be submitting feedback from a range of different people but only as themselves. This will skew your data significantly as each team member will essentially be an aggregate of many different customers or prospects.

If, however, they use Receptive as team users, they can submit feedback on a customer or prospect's behalf and so your data will be accurate and far more useful to you.

Tagging Requests

Team users are able to add tags to requests. This is a great way of keeping your feedback organized and makes it much easier to analyze when it comes to reporting.

If your team members are using Receptive as customer users, they won't be able to add tags. This will make it much harder to analyze your data, and it will end up being a lot more work for your Product team.

Private Requests

Another great feature that team users have access to is the ability to submit (and see) private requests. These are great for making internal requests or project ideas that you don't want to share with your customers.

If your team members are using Receptive as customer users, they won't have any visibility of these private requests, or be able to submit requests as private. This means they'll lose out on a lot of internal communication.

Summary

It might be that your internal teams are your customers, in which case adding teams as customers can work quite well.

But, if you're inviting external customers and team members in, or you want your customer or prospect facing teams to get the most value from Receptive, then you should be aware of the limitations of the customer view.