# Build trust before a key action

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-trust/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-trust/index.md
- **Module:** Retention
- **Time:** 75 minutes for the first analysis

Before registration, verification, or a transaction, users often stop because of one specific doubt—not because the button is weak. Answer that doubt at the moment of decision.

## Outcome

A one-doubt card with the user question, a verified answer, placement in the interface, an owner, and a validation metric.

## Trust comes from a clear answer, not a promise

A trust moment is a short explanation next to an important action: why the data is needed, what happens after the tap, how long the process takes, and where to go if something breaks. It must be backed by how the product actually behaves.

## What you will need

- **One screen:** Pick a step with a visible drop-off: registration, document upload, transaction confirmation, or the first deposit.
- **Live questions:** 10–20 support requests, reviews, or cancellation reasons tied to that exact step.
- **Answer verification:** A support representative and the process owner who can confirm the timing, conditions, and a safe help channel.

## Terms in plain language

- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.

## When to use it

Users reach an important action but postpone or cancel it, and support keeps answering the same question about conditions, data, or status.

## Where to find the real doubt

Do not guess the user's fear from a mockup. Connect the drop in the data with the user's words and the actual rules of the process.

- **Drop-offs at the step**
  - **Source:** In the funnel, compare screen opens, taps on the primary button, successful completions, and technical errors.
  - **If access is unavailable:** Without analytics, do ten walkthroughs and ask three new users to say out loud why they are — or are not — ready to continue.
- **Support and cancellations**
  - **Source:** Group the questions: why the data is needed, is it safe, how long it takes, what the conditions are, and what to do on error.
  - **If access is unavailable:** If tags are not set up, manually review the last 20 messages about the chosen step.
- **The real process**
  - **Source:** Verify the answer with the operations team, support, and a legal specialist wherever conditions or personal data are involved.
  - **If access is unavailable:** If the team cannot back a promise, do not publish it — fix the process first or state an honest limitation.

## Remove one main doubt

1. **Pick one critical screen.** Start with a step where the drop-off is visible and the action requires trust. Do not try to rewrite the whole journey at once.
   - **Where to do it:** The registration, verification, or key-transaction funnel.
   - **Example:** Document upload screen: 1,000 opens, 540 successful submissions, 90 technical errors.
2. **Collect the users' words.** Write down recurring questions without the team's internal phrasing. Each question should sound the way a user asks it.
   - **Where to do it:** Support requests, reviews, cancellations, and walkthrough observations.
   - **Example:** “Who will see the document?”, “How long do I wait?”, “Can I finish later?”
3. **Choose the main doubt.** Weigh frequency, impact on completion, and the risk to trust. Take one question the team can answer honestly.
   - **Where to do it:** In the first row of the doubt map.
   - **Example:** The main question: “what happens to the document after I send it?”
4. **Put the answer next to the action.** Show the timing, the next step, the conditions, or help before the tap — not in a distant help section.
   - **Where to do it:** Above the field, under the CTA, or on the confirmation screen — wherever the question arises.
   - **Example:** Under the button: “Verification usually takes up to 10 minutes. The status will appear on this screen.”
5. **Verify the promise and the effect.** Make sure the product does what the text says. After the release, compare step completion and requests about that doubt.
   - **Where to do it:** On a test account and in the report after 14 days.
   - **Example:** The status really updates, and “how long do I wait” requests dropped from 34 to 12 a week.

## Practical examples

- **Doubt: what happens to the document:** Above the upload, the team explains the purpose of the check; next to the button — the usual time of up to 10 minutes; after submission — a visible status and a help channel. All four promises are verified against the real process.
- **Doubt: did the transaction complete?:** Instead of a generic “Processing,” the screen shows the stage, the expected time, and a safe action in case of delay. The check: step completion and the number of status requests after 14 days.

## Finished artifact: A doubt map for one screen

Do not add a generic “You can trust us” block. Give a short, verifiable answer to a specific question at the point of decision.

| User question | Verified answer | Where to show it | Check |
| --- | --- | --- | --- |
| Why is the document needed? | To verify identity; the data is protected | Above the upload field | Agreed with the process owner |
| How long will it take? | Usually up to 10 minutes | Next to the CTA | Verified over 30 days |
| What happens next? | We show the status and send a notification | Below the button | The status really updates |
| What if an error occurs? | You can continue later or contact support | On the error screen | The channel responds |
| Are there any restrictions? | The terms are available before confirming | A link next to the action | The text is readable without searching |

First change: explain the review time and the next step right on the document upload screen. Owner — product + support. Check: step completion and status-related requests after 14 days.

## Trust checklist

If an answer cannot be backed by the process or data, it must not be used as reassuring copy.

- [ ] One screen and one specific doubt are chosen.
- [ ] The doubt is confirmed by users' words or cancellation reasons.
- [ ] The answer contains a fact: the why, the timing, the next step, the conditions, or help.
- [ ] The text sits next to the action and can be read without opening the help section.
- [ ] The promise is verified by the process owner and tied to an outcome metric.

## How to know the trust moment helps

- **Step completion:** Conversion of the chosen action grew without extra pressure on the user.
- **Clarity:** Requests and cancellations about the doubt the new text answers went down.
- **Promise reality:** After the release, the timing, statuses, and help channel match what is written.

## Key rule

Do not mask anxiety with a brighter button: give an honest, verifiable answer where the user makes the decision.

---

- [HTML version](https://playbook.affpartners.io/en/practices/retention-trust/index.html)
- [All practices](https://playbook.affpartners.io/en/)