Launch Feedback and gather requests internally

New Feedback customers often choose to launch and use Feedback internally because it allows them to familiarize themselves with the process before launching it to customers. For information on granting Visitor access to Feedback, see Grant Feedback access to customers.

Within Pendo Feedback, your teams can create requests, and vote on and prioritize existing requests, on behalf of customers and prospects. For inspiration, see this customer success story from PetDesk.

You can also use our Salesforce and Zendesk integrations to keep your customer-facing teams in the software they already use, where they can submit requests on behalf of customers, or add votes to requests that already exist. 

The process for launching Feedback and gathering requests internally is as follows:

  1. Install Pendo
  2. Configure Product Settings
  3. Introduce Feedback internally
  4. Create requests (on behalf of customers and prospects)
  5. Update votes and priorities

Step 1. Install Pendo

Install Pendo following the instructions in the Developer’s Guide to installing Pendo and the Developer’s Guide to installing Feedback.

The Pendo install script (commonly referred to as “the snippet”) ensures that the data we manage in Feedback is accurate, even if you never plan to expose Feedback to your end-users.

To ensure you don’t expose Feedback to customers, follow the instructions for configuring your Product Settings, below.

Step 2. Configure Product Settings

To ensure that Feedback is hidden from your customers, navigate to Feedback Settings > Product Settings, and configure the following:

  • In Visitor View, leave the default set to Portal, with no button or link to give your Visitors access. This allows us to collect the data we need while Feedback remains invisible to your end-users.
  • In Manage Team, ensure that your colleagues can’t edit Vendor Settings. For more information see Manage Team: Roles and Permissions in Feedback.
  • In Email and Whitelabel, select Disable notification emails to visitors

If you do want to send notification emails to your customers with request status updates without giving them access to the Feedback interface, you can deselect Disable notification emails to visitors and select Auto-login links in visitor emails instead. This removes the link in notification emails that would otherwise provide access to Pendo Feedback.

For more information about Product Settings, see Settings for Pendo Feedback.

Step 3. Introduce Feedback internally

Inviting your internal teams to Feedback involves communicating the benefits and showing them how submit feedback to your Product team. Customer-facing teams might need more guidance because they can use Feedback on behalf of your customers and prospects, and not just for their own requests.

Introduce Feedback to your organization

We recommend setting up a meeting or presentation where you motivate your colleagues to use Feedback based on the benefits for both the company and the individuals using it.

  • Focus on the benefits rather than the technical details. Examples include a better idea of how to develop the product, reduced support tickets, and greater alignment across the company.
  • Highlight the ability to create private requests and comments. Internal users can select the checkbox at the bottom of the request form next to Hide this from customers.
  • Point your colleagues to resources for getting started, such as a Guidelines document if you've created one.
  • Don't ignore tough questions. If you don't know the answer, you can find out and get back to them. 

You can also send an internal engagement email reiterating these points. For more information, see Engagement emails in the Notification emails in Feedback article.

Introduce Feedback to your customer-facing teams

Give your customer-facing teams guidance on how to respond to customers based on your engagement strategy. You can do one or both of the following:

  • Manage Feedback on behalf of customers (high-touch). If you want to keep the discussion as part of your own-going customer relationships or if you're not ready to grant Feedback access to customers, customer-facing teams can submit requests on their behalf.
  • Encourage customers to self-serve (low-touch). For information on how to grant your customers access to Feedback see, Grant Feedback access to customers.

Step 4. Create requests

When customers or prospects provide feedback over the phone or email, Pendo Feedback allows your customer-facing teams to add this feedback to a request, which your Product team can then use to make data-driven decisions about the product. For guidance on what to include in a request and how to tag it, see What makes a good request in this article.

To create a request on behalf of a customer or prospect:

1. Select Suggest from the top of the left-side navigation. This opens the request form.

2. Select you in Requested by you to change the requestor. This opens a search box. 

Submit_RequestedByYou.png

3. Enter and select the customer or prospect's name from the list.

The names in this list can come from multiple sources depending on your setup. Customer data can come from your Pendo snippet or your Salesforce integration.

Prospects are typically created manually, unless you're using Salesforce Opportunities to track prospect demand. If a prospect isn't listed, you can create them by selecting Add customer or prospect... and filling out the form.

Submit_RequestedBy.png

4. Add the details of the request to the form. For guidance, see What makes a good request in this article.

After submitting the form, you are the "creator" of the request, but your vote isn't added. Instead, the user that you created the request for will have their vote listed in the Request activity box of the request details page.

Step 5. Update votes and priorities

As well as creating new requests, customer-facing teams can update existing requests on behalf of customers and prospects. This includes adding their votes to existing requests and updating their priorities on their behalf.

Add a customer's vote to an existing request

When you create a request on behalf of a customer, their vote is automatically added. You can add votes from other customers if you receive the same or similar feedback from them, rather than creating a duplicate request. To add a customer to an existing request:

1. Open the relevant request. You can find requests in the Browse page, which you can access from the left-side navigation. For more information, see Manage requests in the Browse page.

2. Select Add visitor at the bottom of the Request actions section in the right-side of the request.

3. Enter and select the customer or prospect's name from the list.

Request_AddVisitor.png

Update a customer's priorities

If a customer has made or is subscribed to more than one request, you can update their priorities on their behalf. This is good for account-managed SaaS businesses and companies that have a lot of customer contact over the phone. To update a customer's priorities:

1. Search for the customer and navigate to the customer's profile page.

2. Select Edit in the top-right corner of the profile panel.

VisitorProfile_Edit.png

3. Select the Priorities tab to the left.

4. Make changes to the sliders. This updates the customer's priorities on their profile page.

User_Priorities.png

What makes a good request

A good request explains what it is you're asking for, as well as the underlying reasons for the request. This section provides advice on what to include in a request so that it can be used by your Product team to make decisions.

General guidelines

  • Try to focus on the problem and not the solution. The solution is the Product team's job.
  • Clarify why the request is needed and how the product doesn't meet user needs today.
  • Be specific and provide context. How was the product or feature being used when the gap was noticed?
  • Create one request per idea. Separate different ideas that relate to different aspects of the product into different requests.
  • Add any use cases and how you're currently overcoming the problem. 
  • If you have context about your use case that could be helpful but not specific to the request, add it in the comments section.

Content

Title: This should be clear and to the point. Avoid vague language and jargon because the title needs to be instantly understandable.

Description: This should contain all the information that the Product team needs to make a decision. Focus on the problem you experienced rather than possible solutions, any context that is necessary for understanding, examples and use cases, and how you currently solve the problem.

Files: Upload screenshots to add clarity or communicate something that is hard to put into the description. Screenshots should be clear and high resolution.

Product Areas: If your feedback is relevant to a particular Product Area, assign your request to that Product Ares in the request form

Tags: Add tags to help organize the feedback. For guidance, see Tags in this article.

Effort: If you're in a position to accurately estimate the effort your request will require, then you can add it using the Effort slider. If you're unsure, leave it for the Product team or Engineers to decide.

Visibility: If you're making a private request, then change the visibility of your request before you submit it.

For information on how to create the request form, see Request form setup and customization.

Tags

With tags, your customer-facing teams can provide additional information that the Product team can utilize, from identifying how various requests relate to an overall pain point, to knowing which pain points could lead to upsells. For more information on tags, see Tagging in Feedback.

Your internal users don't need to know every tag, but let your customer-facing teams know what kinds of information you'd like them to start tagging so that the Product team can investigate these items.

Tip: To make it easy for customer-facing teams to find tags, create a private test request that includes the tags you've decided so that they'll be available to select.

Some examples of tags and tag categories that your customer-facing teams could use include:

Category Tags
Problem or pain point
  • Problem:Ticket management
  • Problem:Complex system issue
Expansion potential
  • Expansion:100-499
  • Expansion:500-999
  • Expansion:1000+
Customer success
  • CS:Quick Win (for example, if a request may be a small tweak to an existing feature)
  • CS:Strategic (if your customer success teams notice a theme or project that ties to a CS strategic goal)
Risk
  • Risk:Customer value (if a request is stopping customers from getting value from your product)
  • Risk:Potential bug (if a feature isn't performing as the customer expected)