# Decision Brief

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

## Document profile

| Field | Value |
|---|---|
| Framework node | Decision & Priority |
| Document role | Compare options and recommend a path |
| Working title | Merchant payout status visibility |
| Owner | Product Owner |
| Last updated | 2026-04-07 |
| Status | Decision pending |

## 1. Decision to make

Choose the most appropriate first release for improving merchant visibility during payout processing and manual review.

## 2. Context

Discovery confirmed that the current payout journey creates avoidable uncertainty after submission.  
The main issue is not lack of internal status data, but weak merchant-facing translation of that data into understandable states.

The first release should improve clarity without creating a large dependency on new notification systems or major payouts-area redesign.

## 3. Options considered

| Option | Summary | Delivery effort | User clarity | Operational risk |
|---|---|---:|---:|---:|
| A. Merchant-facing status model in product | Add a small set of clear external statuses with supporting copy inside the payouts view | Medium | High | Low |
| B. Email notifications for every payout transition | Add asynchronous updates outside the product | High | Medium | Medium |
| C. Full payouts-area redesign | Rework the broader payout experience and detail surface | High | High | High |

## 4. Decision criteria

- improves clarity in the highest-volume uncertainty moments
- uses existing internal status logic as much as possible
- can be delivered in a narrow, low-risk slice
- does not expose sensitive operational logic
- creates a usable baseline for later notification work

## 5. Assessment

### Option A — Merchant-facing status model in product
**Strengths**
- Directly addresses the current clarity gap
- Keeps implementation close to the existing payout flow
- Reduces support pressure without promising instant notifications
- Provides a base layer that later channels can reuse

**Weaknesses**
- Still requires users to return to the product to check progress
- May not remove all support contacts for longer-running cases

### Option B — Email notifications for every payout transition
**Strengths**
- Proactive communication
- Useful for merchants who are not in the product at the time

**Weaknesses**
- Higher delivery and operational dependency
- Copy, timing, and exception handling complexity increase quickly
- Risk of inconsistent state communication across channels

### Option C — Full payouts-area redesign
**Strengths**
- Highest theoretical clarity ceiling
- Opportunity to improve the wider payout experience

**Weaknesses**
- Too broad for the validated problem scope
- Slower time to value
- Higher coordination cost and release risk

## 6. Recommendation

**Recommend Option A: merchant-facing status model in product for release one.**

This option gives the highest ratio of clarity improvement to delivery complexity.  
It also preserves a clean path for later expansion into notifications if the first release proves that clarity improves and support demand decreases.

## 7. Trade-offs accepted

- The first release improves clarity, not channel coverage.
- We accept that some merchants will still prefer asynchronous updates later.
- We prioritize understandable states over perfect granularity.

## 8. Dependencies and risks

| Dependency / risk | Note |
|---|---|
| Status mapping agreement | Internal operations and product must agree on safe external labels |
| Copy precision | Language must be useful without exposing internal controls |
| Edge-case handling | A small number of uncommon paths may remain under a generic fallback state |
| Measurement | Support tag quality must be sufficient to observe post-release effect |

## 9. Follow-up if approved

- create Shaped Brief for release one
- define external status set and display rules
- align copy with support and operations
- define baseline metrics for support contacts and payout-state visibility

## 10. Related artifacts

- Problem Brief
- Shaped Brief
- Outcome Review