# Complaint Ownership and Closure Page: https://alidemirbas.com.tr/en/lab/journeys/issue-ownership-and-closure Complaint opened → assign owner → resolve → confirm closure ## Purpose Assign a new complaint to the right owner and follow it through resolution and, where required, customer confirmation. Goal: Escalation & Exception · Category: Feedback & Communication ## Steps - **Trigger**: Actionable issue created - **Action**: Capture the issue type, severity, related entity, SLA and source. Duplicates against the same underlying problem are reconciled here rather than worked twice - **Decision**: Is the correct owner known? - Known: Assign the owner and record the assignment, appended - who held an issue and when is part of its resolution history - Unknown: Work created → routing → assignment - **Action**: Assign the owner and record the assignment, appended - who held an issue and when is part of its resolution history - **Handoff**: Work created → routing → assignment - an issue with no determinable owner - **Wait**: until the operational fix for the issue is recorded complete - timeout after The wait is the SLA threshold for this severity; a miss escalates one level, never to the customer. (configure complaint.sla_threshold) - **Decision**: Does closure require the person to confirm? - Confirmation required: Is there a permitted route to ask them? - Not required: Close the issue, preserving the full resolution history: what was wrong, who owned it, what was done, when, and that the person confirmed it - **Action**: Escalate one level: notify, then involve the team or manager, then reassign into a priority queue. Nothing customer-facing is sent because of this - an internal delay is our problem, not new information for them - **Decision**: Is there a permitted route to ask them? - A route exists: Ask whether the specific issue they raised is now resolved, against the fix that was actually performed. Waiting for a confirmation nobody was asked for is not a confirmation state, it is a timeout dressed as one - No route: Close under the bounded closure rule, recording explicitly that the fix completed and the person never confirmed. Confirmed and unconfirmed closures are different facts and are never written the same way - and, where closure was unconfirmed because no permitted route to the reporter existed, that reason is recorded as itself rather than as silence - **Action**: Close the issue, preserving the full resolution history: what was wrong, who owned it, what was done, when, and that the person confirmed it - **Decision**: Are the escalation levels exhausted? - Levels remain: until the operational fix for the issue is recorded complete - Exhausted: Human in the loop lifecycle - **Action**: Ask whether the specific issue they raised is now resolved, against the fix that was actually performed. Waiting for a confirmation nobody was asked for is not a confirmation state, it is a timeout dressed as one - **Action**: Close under the bounded closure rule, recording explicitly that the fix completed and the person never confirmed. Confirmed and unconfirmed closures are different facts and are never written the same way - and, where closure was unconfirmed because no permitted route to the reporter existed, that reason is recorded as itself rather than as silence - **Exit**: Resolved and confirmed - the same problem recurring is a new issue, linked to this one rather than reopening it - **Handoff**: Human in the loop lifecycle - an issue outliving its escalation ladder - **Wait**: until the person confirms the issue is resolved, or the person says the issue is not resolved - timeout after The person is given a bounded window to confirm; past it the issue closes under the bounded closure rule, recorded as never confirmed rather than as resolved. (example: 5 days–10 days; configure complaint.closure_window) - **Exit**: Fixed operationally - any later contact about the same problem enters knowing this was never verified, which is why the distinction is recorded - **Decision**: What did they say? - Resolved: Close the issue, preserving the full resolution history: what was wrong, who owned it, what was done, when, and that the person confirmed it - Still not right: Has the reopen limit been reached? - **Decision**: Has the reopen limit been reached? - Not reached: until the operational fix for the issue is recorded complete - Reached: Escalate one level: notify, then involve the team or manager, then reassign into a priority queue. Nothing customer-facing is sent because of this - an internal delay is our problem, not new information for them ## Guardrails - Escalate complaints without a clear owner. - Do not assume closure when customer confirmation is required. ## Core rule Keep the issue open until ownership and the conditions for closure are clear. ## When to set it up Newly opened complaints sitting without an owner, SLA misses passing without anyone acting, or reports that count an operational fix and a customer-confirmed closure as the same thing all call for this journey. Complaints need a type, a severity and a related record, the owner must be derivable from those, every severity needs an SLA threshold, and a permitted contact route for the confirmation question has to be stored before launch. If records open from a negative sentiment score alone or from support conversations that have not yet established a failure, fix the trigger source first; this journey follows a detected failure. ## How to set it up - **Trigger and entry**: An actionable issue enters once it is formally created and verified in the system with a type, a severity and a related entity. Because the only customer message is the confirmation question, do not hold out a random control group; measure the outcome across every complaint that enters. - **Who must not enter**: One complaint record is one journey instance. Duplicates against the same underlying problem are reconciled at entry rather than opened twice, and a negative sentiment score or a support conversation that has not yet identified a failure does not start the journey. - **Timing and channels**: When the owner is known, the issue is assigned and waits for the operational fix up to the SLA threshold for that severity; a miss escalates one level and nothing goes to the customer. If closure requires confirmation and a permitted route exists, the confirmation question goes out by email or in-app message. - **Exit and handoff**: An issue with no determinable owner is handed to Work assignment, and one that outlives its escalation ladder to the Human-in-the-loop journey. The record closes either as resolved and confirmed, or as fixed operationally when the confirmation window expires or no permitted route exists. - **Frequency and consent**: The confirmation question goes out once per fix, only where a permitted route for issue correspondence exists; if the customer says it is still not right, the record returns to resolution until the reopen limit, then escalates. Engagement does not extend the confirmation window; assignment and escalation are human tasks and carry the full history. ## How to measure success **Confirmed closure rate**: The journey exists to produce an owned fix and a closure the customer has confirmed; a recorded operational fix or a delivered confirmation question does not show that on its own. Among all complaints opened into the journey, the share closed as resolved and confirmed within the same follow-up window. A classic control group does not apply here; report closures that did not require confirmation on a separate line, and do not let delivery or non-response to the question change the denominator. Also track: - **Resolution rate**: Of all opened complaints, count those whose operational fix is recorded within the SLA threshold; the intermediate step before confirmation and the work that closes without escalating. - **Unowned and escalated share**: Track records handed off for lack of an owner and records escalated at least one level separately; if both climb, the problem is in the assignment rule or in team capacity. - **Unconfirmed closures and reopens**: Count closures that went unconfirmed because the window expired or no permitted route existed, and reopens where the customer said the problem persists, as separate numbers; a rise in the second says the fix is not closing the real issue. - **Complaints and opt-outs on the confirmation ask**: Among people who received the confirmation question, watch email unsubscribes, in-app message opt-outs and new support contacts; asking for confirmation should not create a fresh complaint. ## What to watch when reading the result - Read the confirmed closure rate next to unconfirmed closures: if total closures rise while the confirmed share falls, records are closing quietly rather than quickly. Where confirmation is required, never assume closure before it arrives; an unanswered record is an unconfirmed closure, not verified satisfaction. - Keep the conclusion tied to these SLA thresholds, this confirmation window and this reopen limit. The outcome of a record handed off for lack of an owner, or escalated past the ladder into the Human-in-the-loop journey, is credited to that journey; a record left without an owner never counts as a resolution here. - When confirmed closure is a rare outcome and volumes are low, monthly rates will swing; before comparing two periods or two teams, use the [sample size calculator](https://alidemirbas.com.tr/en/calculators/sample-size-calculator) with your current closure rate and the smallest difference you want to see to find how many records you need, and keep the follow-up window long enough to cover the whole confirmation window. ## Frequently Asked Questions ### Who should own a newly opened complaint? Identify and record an owner able to resolve it. Use the assignment process if ownership is unknown rather than closing an unowned case. This journey tracks the remedy and any required customer confirmation. Assignment is not resolution. ### Does no customer response mean the complaint was resolved? Silence is not confirmation. Report an operational remedy separately from customer-verified closure. This flow checks whether confirmation and a contact route are required. Do not label an unanswered case as verified satisfaction. ### What if the customer says the issue remains unresolved? Reassess the case while preserving its history. Use defined reopening and escalation rules rather than repeating the same automated question indefinitely. Escalate to human review when limits are reached and transfer prior actions to the new owner.