## TL;DR
Promise the workaround, never the fix. You can guarantee what the customer can do today; you cannot guarantee what engineering ships and when. The safe sentence is: "Here is what works right now, and I will check on the real fix by [date]." Every broken promise in support history started with an agent dating someone else's work.

## The query

```text
workaround vs fix: what support can promise
```

## Use this when

- Customers press you for a fix timeline
- Agents keep promising ship dates
- You are writing policy on commitments
- A workaround exists but customers want the real fix

## Not for

- Writing the engineering escalation
- Outage or incident communication
- Deciding which bugs get fixed
- Refund or compensation decisions

## Steps

### 1. Lead with the workaround, framed as the solution for today

Present it confidently, not apologetically: "Here is how to get your export working right now." A workaround delivered well resolves the ticket; a workaround delivered sheepishly invites an argument about the real fix.

Expected output: the customer has something that works today.

### 2. Verify the workaround actually works before promising it

Test it yourself or confirm it with a customer who used it. A promised workaround that fails is worse than no workaround, because now you have broken two promises.

Expected output: every offered workaround is verified, not theoretical.

### 3. Separate what you control from what you dont

Say it out loud: "I can promise this workaround and my follow-up. The fix timeline is engineering's call and I wont guess at it." Customers respect the honesty more than agents expect.

Expected output: the customer understands exactly which promises are yours.

### 4. Date your check-in, not the fix

"I will check on the fix and update you by Friday" is a promise you can keep. "It will be fixed by Friday" is a promise you cant. The difference is everything.

Expected output: a follow-up date on every ticket waiting on a fix.

### 5. When there is no workaround, say so fast

Dont stall hoping one appears. "There is no workaround right now, here is what I am doing about it" lets the customer plan around reality instead of waiting on hope.

Expected output: customers with no workaround know it immediately, with a plan attached.

## Variant phrasings

### what can support promise about bug fixes

Steps 3 and 4. Your promises are the workaround and the check-in.

### how to offer a workaround without overpromising

Steps 1 and 2. Confidence plus verification.

### should support give ETAs for bug fixes

No, unless engineering gave you one in writing. Date the check-in instead.

## Why it happens

Agents promise fix dates because the customer is upset and a date ends the conversation. It works for about a day. Then the date passes, the fix hasnt shipped, and the customer is now angry about the broken promise instead of the bug. The workaround-plus-check-in pattern ends the conversation without creating a second problem.

## Edge cases

- Engineering gave you a date: you can relay it, but attribute it. "Engineering is targeting Thursday" is honest; "it will be fixed Thursday" is yours now.
- The workaround is painful: acknowledge it. "I know this is clunky" keeps trust while the real fix cooks.
- The customer rejects the workaround: note the rejection, keep the ticket open on the fix, and keep your check-in dates. Dont argue them into it.
- No workaround and no fix in sight: escalate the priority of the ticket itself, and tell the customer you did. Visibility is the consolation.
- The workaround stops working: treat it as a new incident on the ticket. Update everyone waiting on it proactively.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JAe61BlCi_y_AOCLEAYvZQ