How to collect feedback on internal tools

Employees are customers too

Internal tools have customers, even though they are your coworkers. The people who file expenses, deploy services or update a shared spreadsheet know exactly what slows them down. Their feedback is cheap to collect and often more specific than a customer's, because they can walk over and ask a follow-up question.

The problem is that internal feedback tends to disappear. It arrives in a direct message, gets forgotten, and the tool stays the same for another year. A feedback inbox with a clear owner per tool fixes most of that.

One product per internal tool

Create one product for each tool in the dashboard. Name it after the tool, such as "Expenses" or "Deploy dashboard", so the inbox list reads like a map of your internal systems.

Separate products give you three things at no extra cost. Each product has its own public key, its own allowed origins and its own notification webhook. The filters by status and type are per product as well, so the expenses team reads only expense feedback. Splitting products is the closest thing to routing that the tool offers, and it matches how internal teams already own their systems.

Avoid one shared product for everything. A single inbox for twenty tools means every team reads every message, and nobody feels responsible for the item that belongs to them.

Identify people by work email

Load the widget inside the tool's authenticated layout, after your company login has finished. Then identify the employee with their work email, name, id and team. Team and role become metadata, which helps the owning team see who is asking:

window.EscutaProduto = window.EscutaProduto || { q: [] };
(window.EscutaProduto.q ||= []).push([
  "identify",
  [{ email: user.workEmail, name: user.name, id: user.id, team: user.team, role: user.role }],
]);

When the email is known, the form hides the email field, so people do not type it again. Call identify again if a person changes team, so later reports carry the right value.

Use the same identify call in every tool that belongs to your company, adjusting only the product key. People then keep one habit across tools, and the owning team still sees the right context.

Keep the widget behind your login

The widget appears wherever you load it, so put the script inside pages that require a company login. Do not add it to a public page of an internal tool, such as a login screen or a status page that anyone can open. Set the allowed origins to the internal domain as well, so the widget cannot be copied to another site.

The hosted feedback page is a different matter. It is public, so anyone with the link can submit a message. Use it for a link inside the company wiki or a help article, and do not treat it as a restricted channel. If a tool must never accept outside input, do not share its hosted link at all.

Route feedback to the owning team

Each product has its own notification webhook. Create one Slack or Discord channel per team, and point the product at that channel. A new item posts the type, the product name, the rating, the sender and a 500-character excerpt, along with a dashboard link. The owning team sees the report in its own channel and opens the inbox from there.

Keep the channels quiet. An internal tool with a few hundred users might receive a handful of messages a week, which is a good level for a channel. If a tool gets far more, read the messages in the weekly review instead of turning every item into an alert. The article on Slack channels for product feedback covers the trade-offs in more detail.

Triage with statuses and internal notes

The owning team decides what happens to each item. Use the five statuses to show progress: new, planned, in progress, done and closed. Use the private internal notes on each item for decisions and context, such as "duplicate of the March request" or "waiting on the finance system change".

Tools change hands. When a team hands a tool to another group, change the product's notification webhook to the new owner's channel the same day, and add an internal note on the product's first item explaining the handover. Otherwise alerts keep posting to a channel nobody reads, and the new owners never learn that feedback exists.

Escuta Produto has no tags, so keep labels out of the inbox. If your team wants to group reports by area, use the internal notes or a short metadata key, such as area, and export the product to a spreadsheet when you need a summary for a quarterly review.

Set up Escuta Produto for your internal tools

Create a product for each tool and copy its public key into that tool's authenticated layout. Add the company domain to the allowed origins. Identify an employee, send a test bug and an idea, and check that the item shows the work email and team. Then connect the team's Slack or Discord channel as the product's webhook.

The widget reference lists the options, and the notifications guide covers the webhook setup. For the customer side of the same idea, collecting feedback in a SaaS product shows how to identify logged-in users in an app that customers pay for. If your internal tool calls a server, the REST API reference explains how to send feedback from a backend job as well.