# Service recovery workflow

FICTIONAL WORKFLOW · EDDA FOR BUSINESS

Candidate configured workflow, not a client result or a live connection. Actions, access and success criteria must be scoped and proved for each company.

## Trigger
A recurring service issue meets an approaching renewal.

## Company context
A repair ticket alone does not tell the whole story. Relationship history and renewal timing make it a reason to act.

## Operating loop
1. **Connect.** Link the recurring fault, relationship concern and renewal window. Flag a risk for review, not a predicted departure.

2. **Act within the rules.** Open Maya’s recovery task, attach the relevant history and set the agreed deadline. Keep the account owner informed.

3. **Follow through.** Check for a repair plan and remind the owner. If the deadline passes without one, escalate to Sam with the unresolved facts.

4. **People decide.** Sam approves a recovery call and asks Maya for a revised plan. The case stays open until completion and the customer response are recorded. No availability or concession is assumed.

## Intended business consequence
The team can address the relationship risk earlier. Routine coordination has a home, leaving leaders more room for decisions that need them.

## Fictional source excerpts
### Service desk
Monday, 09:12. Harbour Studio has reported the same cooling fault again. The earlier repair is recorded as complete; the new case is open.

### Account and renewal record
Harbour Studio: renewal review next month. Sam owns the relationship. The last call raised concern about repeated disruption. No decision to leave has been recorded.

### Recovery playbook
For a recurring fault ahead of renewal, open a recovery task for Maya in Facilities, with a plan due at 16:00. Remind her before the deadline; escalate an overdue plan to Sam. Customer messages and commercial concessions require approval.