# Problem Brief

**Illustrative sample for portfolio use**  
Generalized scenario based on a merchant payouts workflow.

## Document profile

| Field | Value |
|---|---|
| Framework node | Signal & Discovery |
| Document role | Clarify the problem before solution shaping |
| Working title | Merchant payout status visibility |
| Owner | Product Owner |
| Last updated | 2026-04-07 |
| Status | Discovery-ready |

## 1. Signal summary

Merchants can submit a payout request successfully, but after submission they have limited visibility into what is happening next.  
Support tickets increase when the payout remains in a pending or manual-review state for longer than expected. Internal teams can inspect the state, but merchants do not receive enough structured feedback inside the product.

## 2. Problem statement

The current workflow confirms payout submission but does not explain progress, waiting states, or likely next steps in a way that reduces uncertainty for merchants. This creates avoidable support load, lower trust in the payout flow, and weak operational transparency.

## 3. Who is affected

| Role / group | Effect |
|---|---|
| Merchant operations users | Unclear whether the payout is delayed, blocked, or still processing normally |
| Support team | Repeated status questions that should not require manual handling |
| Risk / compliance operations | More ad hoc requests for case checks and context explanation |
| Product team | Limited visibility into where user uncertainty is created |

## 4. Observable friction

- Support receives repeated questions of the type: “Has the payout failed or is it still being checked?”
- Merchants cannot distinguish between normal processing time and an exception state.
- Manual review cases feel silent from the merchant side.
- Status language is too technical internally and too thin externally.
- There is no consistent explanation of what the merchant should do next.

## 5. Desired outcome

The product should communicate payout progress more clearly so that merchants can understand:
- whether the payout is still processing
- whether it is waiting for an internal check
- whether any action is required from them
- when they should expect another update

## 6. Scope boundary for discovery

**In scope**
- current payout journey after successful submission
- visible status labels and supporting copy
- internal reasons for the most common waiting states
- operational handoff points that affect merchant clarity

**Out of scope**
- redesign of the full payouts area
- changes to payout risk rules
- SLA commitment changes
- external email notification redesign

## 7. Known constraints

- Existing payout engine statuses should remain the source of truth.
- Operations needs to avoid exposing sensitive internal review logic.
- Copy must work for both normal processing and review-based cases.
- Initial change should fit into a limited delivery slice.

## 8. Unknowns to resolve

1. Which waiting states create the largest support volume?
2. Which internal statuses can be safely grouped into merchant-facing states?
3. Does the current delay perception differ by payout type or merchant segment?
4. Is in-product clarity enough, or is asynchronous notification also needed later?

## 9. Discovery recommendation

Proceed with a focused discovery slice that:
- maps current payout states and internal transitions
- clusters support requests by uncertainty type
- defines a first merchant-facing status model
- identifies the smallest viable clarity improvement for release one

## 10. Working assumptions

- A meaningful share of support demand comes from status uncertainty rather than true payout failure.
- Better status communication can reduce support volume without changing payout operations.
- The first release does not need to solve every edge case to be useful.

## 11. Suggested next artifacts

- Decision Brief
- Shaped Brief
- Outcome Review