# Friction Map — AI-Assisted Support Review

**Scope:** AI-eligible support work from ticket open through learning loop  
**Evidence discipline:** Labels distinguish a product hypothesis from a measured fact

> All examples are synthetic. This is the research structure I would use, not a claim that interviews occurred.

## Dual-sided journey

| Stage | Agent job | Agent friction | Customer risk | Evidence status | Product response | Measure |
|---|---|---|---|---|---|---|
| Triage | Understand intent and account state | Context split across tools | Wrong problem answered | Inferred | Bring eligible account facts into composer | Reopen, edit, context-open rate |
| Generate | Get a useful first draft | Fluency obscures uncertainty | Persuasive error | Observed pattern to validate in audit | Claim states, not one draft-level score | Unsupported claim rate |
| Verify | Confirm consequential claims | Knowledge search and source comparison are separate workflows | Unsupported financial/privacy promise | Inferred | Evidence beside each claim | Source open; time to verification |
| Decide | Edit, send, or escalate | Ownership and threshold are unclear | Delay or incorrect resolution | Inferred | One risk-aware action | Override, escalation, handle time |
| Communicate | Send a clear response | Policy language may be accurate but unusable | Confusion; repeat contact | Unknown | Preserve agent editability and tone control | CSAT, repeat contact |
| Learn | Correct model or knowledge gap | Edits disappear into logs | Same failure repeats | Observed system gap to validate | Structured override and missing-source loop | Recurrence; evidence coverage |

## Core frictions

### 1. Automation bias

**Behavior:** Agents review fluent drafts less critically than rough ones.  
**Risk:** Confidence becomes a visual substitute for evidence.  
**Design response:** Show claim support and risk before the aggregate confidence value.

### 2. Verification switching cost

**Behavior:** Evidence lives in a knowledge base, CRM, billing tool, or policy document outside the composer.  
**Risk:** Correct checking loses to queue pressure.  
**Design response:** Put source title, section, owner, and freshness beside the claim.

### 3. Escalation ambiguity

**Behavior:** An agent sees risk but does not know who owns the exception.  
**Risk:** The agent sends, transfers blindly, or leaves the customer waiting.  
**Design response:** One recommended destination with context attached.

### 4. “Confidence” overreach

**Behavior:** A numeric score is interpreted as probability the answer is correct.  
**Risk:** The product implies more certainty than calibration supports.  
**Design response:** Risk and evidence can force a gate regardless of confidence.

### 5. Missing learning loop

**Behavior:** Agent edits are logged but not classified.  
**Risk:** Retrieval, policy, and generation problems look identical.  
**Design response:** Capture a small structured correction reason without making it punitive.

## Severity and leverage

| Friction | Frequency | Harm | Workflow cost | Priority | Why |
|---|---:|---:|---:|---|---|
| Unsupported high-risk claim | Medium | Very high | Medium | P0 | Financial/privacy harm |
| Conflicting sources | Low–medium | High | High | P0 | Model cannot resolve policy ownership |
| Missing evidence for low-risk how-to | Medium | Low | Medium | P2 | Improve retrieval; avoid universal gate |
| Unclear escalation owner | Medium | High | High | P1 | Correct caution still fails operationally |
| Unstructured agent correction | High | Medium | Low | P1 | Blocks systematic improvement |

## Research plan

| Question | Method | Decision |
|---|---|---|
| Which claims do agents verify today? | Workflow observation + clickstream | Gate scope |
| Does fluency reduce scrutiny? | Blind draft-quality review | UI hierarchy |
| What makes evidence trustworthy? | Evidence-card concept test | Source metadata |
| When is escalation worth the delay? | Error-cost + operations workshop | Risk policy |
| Does repeated gating cause deskilling? | Longitudinal unaided-quality audit | Exposure policy |

## Design principle

The goal is not to remove friction. It is to **spend friction where the cost of a wrong answer exceeds the cost of a slower one**.