Asking for feedback after a user invites a teammate

Why an invite is a signal worth reading

A user who invites a teammate has decided the product is worth sharing. That decision costs them some social capital, because they now have to explain the tool to someone else and defend the choice if it goes badly. Very few users invite people to a product they are not already using well. The invite is a quiet vote of confidence, and it happens at a moment when the user has a clear view of what the product should do for a team.

It is also a moment of friction. A second person arrives with no context, different permissions and possibly a different idea of how the work should flow. The first person now sees problems they did not notice when they worked alone. Both the vote of confidence and the friction are worth capturing.

When should the prompt appear?

Show the prompt after the invite is sent successfully, not on the invite screen itself. The user should see the confirmation first, then a single line below it. Ask only after the first invite. A prompt on every invite will feel like a tax on sharing, and people will stop inviting others to avoid it.

Wait until the invite is sent, not until the teammate accepts. Acceptance can take days, and by then the user has moved on. The feedback is about the act of sharing, so the moment of sharing is the right moment to ask.

What should the prompt say?

Keep the copy short and specific. The user has just done something, so name the action: "You invited a teammate. What would make it easier to work together here?" Put a text field under the question and an optional button labeled "Share an idea." Do not ask for a star rating, and do not ask whether the invite was easy. Those questions measure the invite flow when you want to know what the team needs.

Make the field optional, and let the user dismiss it with a single click. The person is still in the middle of their work. A prompt that blocks them will make the invite feel like a chore.

How do you record the invite count?

Your app knows how many people have been invited, and the widget does not. Pass the count and the role of the invitee to setMetadata before the form opens. A first invite and a fifth invite are different situations, and the metadata makes that visible when you read the reports later.

function afterInviteSent(invite) {
  if (!window.EscutaProduto) return;

  window.EscutaProduto.setMetadata({
    event: "team_invite",
    inviteNumber: invite.totalSentByUser,
    inviteeRole: invite.role,
  });
  window.EscutaProduto.open({ kind: "idea" });
}

Set the identify call for the inviting user, as the widget docs describe, so the report carries their account id and plan. Do not put the invitee's email address in metadata. The invite already contains it, and the metadata should describe the situation, not the person.

What collaboration friction should you look for?

Read the answers for four kinds of friction. The first is permissions: people who cannot see what a teammate can see, or cannot change a shared item. The second is sharing: links that expire, exports that leave out other people's work, or an unclear way to bring someone in from an outside company. The third is notifications: teammates who get too many messages, or none at all. The fourth is ownership: nobody knows who is responsible for a shared item after the person who created it leaves.

Watch the teammate's own reports too, once they sign in. A new member who writes that they cannot find a shared item has told you the invite flow did not explain the workspace well enough. Keep their reports apart from the inviter's by reading the account id and role in metadata, because the two groups need different fixes. Tag these by reading, not by a fixed list. Escuta Produto does not have tags, so put the friction type in an internal note on each report, or copy the answers into a spreadsheet with a column for the type. Count distinct accounts for each type. If many accounts describe the same notification problem, that is a clear fix with a clear reason.

How to act on the answers

Friction in permissions and sharing usually needs product work, but the fix can be small, such as a clearer role name or a message that explains what a viewer can do. Notification friction often needs a setting, not a redesign. Ownership friction is the hardest, because it touches the data model, so write it up with the examples from the reports before you plan any change.

Reply to the people who gave a clear answer. Name what you changed, or say that it is in the plan. The status workflow guide covers how to move these items through the statuses, and the onboarding feedback guide shows how the first invite fits into the early weeks of an account.

Doing the invite prompt with Escuta Produto

Create the product and copy its public key, then add the widget to the team settings page. Open it from the invite confirmation with the open call and the idea type, as the example shows. Each report arrives with the invite count and role in its metadata, and the user's account id if you identified them.

Check the setup with a test account. Invite one address, confirm the prompt appears once, and confirm the item shows the invite number in its metadata. The widget docs list the open and metadata calls, and the feedback after first success article explains why the first meaningful action is the right time to ask a single question.