> ## Documentation Index > Fetch the complete documentation index at: https://support.fieldko.com/llms.txt > Use this file to discover all available pages before exploring further. # Close the Loop on Store Exceptions > Turn store audit findings into verified fixes: exception records, severity, closure stages, a weekly review, and how to build the loop in FieldKo. This page is for field managers, admins, and sales leaders who want store problems found on a visit to end in a fix someone has checked, not in a report nobody reads. The outcome is a short, repeatable loop: every meaningful exception has an owner, a due date, and a recorded verification, and recurring problems get fixed upstream. > [!NOTE] > > **What FieldKo does today:** FieldKo has no standard object that holds an exception's owner, due date, and verified closure. You build the loop from verified pieces: Next Visit To Do's for re-checks, incidents, notes, and Salesforce Flow. Owner, due-date, and closure tracking need configuration. See [How to Implement It in FieldKo](#how-to-implement-it-in-fieldko). ## What Good Looks Like * Every exception that matters is recorded once, with the store, the product or campaign, what was seen, the standard it breaks, and the evidence. * Each exception has a severity, an owner, a next action, and a due date. * "Closed" means new evidence shows the shelf or display changed, or an authorized exception applies. A rep finishing a task isn't the same as the issue being fixed. * Repeat problems are linked, so a manager sees one chronic issue instead of 10 unrelated ones. * A short weekly review starts with overdue critical items and ends with named commitments. ## When to Use It and Common Failure Patterns Use this loop for findings that need someone other than the rep to act, or that need a second visit to confirm: out-of-stocks on must-stock products, missing promotional displays, price errors, damaged stock, and safety issues. Common failure patterns: * **Audits with no owner.** Survey answers show the problem, but nobody is assigned to fix it. * **Task completion treated as resolution.** The rep escalates and completes the task, and the issue is reported as closed while the shelf is still empty. * **"Closed" means "scheduled".** A follow-up is added to the next visit, and nobody checks the result of that visit. * **Speed without proof.** Teams are measured on time to close, so issues get closed early. * **Every issue is urgent.** Without severity levels, critical items wait behind cosmetic ones. ## Operating Procedure ### Record the Exception For each meaningful problem, capture these fields. Your org may hold them in different places; see [How to Implement It in FieldKo](#how-to-implement-it-in-fieldko). | Field | What to Record | | - | - | | Store | The account | | Product or campaign | The product, display, or field campaign affected | | Observed condition | What the rep saw, in the words of your standard | | Standard | The rule it breaks, such as the must-stock list or the campaign's display requirement | | Evidence | A photo, survey answer, or ranging record | | Severity | Critical, High, Medium, or Low (see the next table) | | Likely cause | A category from an agreed list, marked unconfirmed until checked | | Owner | The person or role who acts next | | Next action and due date | What happens next, and by when | | Status | The closure stage | | Verification | The evidence that shows the fix, and when it was captured | ### Set Severity Agree severity levels with your business owners. These are examples, not an industry standard: | Severity | Example | Response | | - | - | - | | Critical | Safety risk, product integrity, or a major contract risk | Follow your immediate escalation procedure | | High | A must-stock product or promotion fails during a time-limited window | Owner acts within the campaign's action window | | Medium | An execution gap with a known owner and a reasonable correction window | Fix by the next scheduled visit | | Low | A cosmetic issue or improvement idea | Review in the monthly business review | ### Move Through the Closure Stages Keep these stages separate, so a completed task never hides an open issue: 1. **Detected:** a credible observation is recorded. 2. **Triaged:** a cause category and an owner are chosen. 3. **Actioned:** a concrete corrective step is taken. 4. **Verified:** new evidence shows the issue is fixed, or a documented authorized exception applies. 5. **Learned:** recurring patterns go to the monthly review for a systemic fix. Allow 3 side paths: **Authorized exception** (the store is allowed to differ), **Not reproducible** (the next visit found no problem and no fix was recorded), and **Reopened** (the problem came back). ### Run the Weekly Review Keep it to about 30 minutes, in this order: 1. Overdue critical issues. 2. High-severity campaign and availability exceptions. 3. Repeating patterns by store, product, or cause. For each item, ask who owns it, what blocked it, what evidence will show it's done, and whether something upstream must change. Leave with a decision log: issue, decision, owner, due date, and how it will be verified. Start the next review with last week's commitments. ## How to Implement It in FieldKo FieldKo captures the findings and carries follow-up work to the next visit. Ownership, due dates, and verified closure need configuration. Choose one of these options, or combine them. | Option | What It Gives You | What It Doesn't | Availability | | - | - | - | - | | A. Next Visit To Do's | Re-check tasks and a note on the account's next visit | An owner beyond the assignee, a due date, or a verification outcome | Built-in | | B. Incident plus a flow | A logged problem with priority and photo, routed by your own Flow | Owner, due date, or status on the incident itself | Incident built-in; routing configured | | C. Case or a custom object | Owner, due date, status, and closure on one record | Anything out of the box: you design and maintain it | Configured | ### Option A: Re-Check with Next Visit To Do's Use this when the next rep visit is the right time to fix or re-check the issue. 1. During the visit, the rep taps **Next Visit To Do's**, carries over unfinished tasks or adds a re-check task, and adds a note. See [Next Visit To Do's](https://support.fieldko.com/visits/notes-and-follow-ups.md#next-visit-to-do’s). 2. Managers can do the same in Salesforce with the **Next Visit ToDo's** quick action on a visit. See [Next Visit To Do's for Admins](https://support.fieldko.com/admin/call-cycles-and-visits.md#next-visit-to-do’s). 3. FieldKo adds the tasks to the account's next planned visit, or to the next visit created for the account. 4. The re-check task's survey answer on that later visit is your verification evidence. > [!WARNING] > > Once its tasks are added to the next visit, the to-do goes inactive. "Closed" here means **scheduled**, not **fixed**. Verify with the answer from the later visit. FieldKo also keeps only 1 active to-do per account and assignee, so a new to-do replaces an existing one. To create these to-dos automatically when a must-stock product is missing, see [Follow Up on an Out-of-Stock Product](https://support.fieldko.com/platform/automate/flow-recipes.md#follow-up-on-an-out-of-stock-product). ### Option B: Log an Incident and Route It with Flow Use this for problems someone other than the rep must fix, such as damaged stock or a safety issue. 1. The rep logs an incident during the visit, with a **Subject**, a **Priority** (High, Medium, or Low), a description, and an optional photo. See [Log an Incident](https://support.fieldko.com/field-work/log-incident.md). 2. The incident records the account and the visit. Managers see it on the **Incidents** tab. See [Review Incidents and Pack-Outs](https://support.fieldko.com/managers/monitor-your-team.md#review-incidents-and-pack-outs). 3. Build a record-triggered flow on the incident that creates a Salesforce **Task** (the standard activity) with an assignee and a due date, or sends a notification. Follow the pattern in [Flow Recipes for Field Teams](https://support.fieldko.com/platform/automate/flow-recipes.md) and [Notifications and Email Alerts](https://support.fieldko.com/platform/automate/notifications.md). The incident has no owner, due date, or resolution status of its own, so track closure on the Salesforce task your flow creates. Treat Critical as High plus your escalation procedure, unless you add your own severity field. ### Option C: Use a Case or a Custom Object If you need one record with owner, due date, status, and verification, configure it yourself. Salesforce **Case** or a custom object can hold the exception record fields above, a status picklist with the 5 closure stages, and lookups to the account, visit, and product. A flow can create the record from an incident, a survey answer, or a ranging line item that isn't present. Before you add objects or automation that touch synced FieldKo records, read [Extend FieldKo Safely](https://support.fieldko.com/platform/customize/extend-safely.md) and [Design Automation for FieldKo](https://support.fieldko.com/platform/automate/design-automation.md). > [!NOTE] > > FieldKo doesn't include a standard pattern for this. If you're unsure which option fits your org, ask your FieldKo contact. ## Fictional Example Fictional example: a regional manager looks after 40 stores for a made-up snack brand, Northwind Crunch. In one week, reps record 20 exceptions. | Severity | Detected | Due this week | Verified closed | | - | - | - | - | | Critical | 1 | 1 | 1 | | High | 6 | 6 | 4 | | Medium | 9 | 8 | 7 | | Low | 4 | 0 | 0 | | **Total** | **20** | **15** | **12** | The org uses Option A for the 9 medium out-of-stocks and Option B for the 1 critical (a broken shelf) and the 6 high-severity missing displays. Of the 15 exceptions due this week (all except the 4 low and 1 medium due next week), 12 have a later survey answer showing the fix, so the verified closure rate is 12 ÷ 15 = 80%. The 2 open high items are the same display at the same store, reported on 2 visits, so the manager links them and asks the store-operations contact what's blocking it. ## What to Measure | Metric | Definition | Population | Denominator | Exclusions | Owner | | - | - | - | - | - | - | | Verified closure rate | Due exceptions with recorded verification ÷ exceptions due in the period | Exceptions with a due date in the period | Exceptions due | Authorized exceptions; not-reproducible items, reported separately | Regional manager | | Median time to verified resolution | Median days from Detected to Verified, by category | Exceptions verified in the period | Not applicable (median) | Open exceptions, reported as aging instead | Regional manager | | Repeat issue rate | Resolved issue categories that recur at the same store within your window ÷ resolved issue categories | Exceptions verified in the prior window | Resolved categories | Different severity or product, unless you agree to group them | Retail execution lead | | Critical with no owner | Critical exceptions with no owner after 1 business day | Open critical exceptions | Count, not a rate | None | Field operations lead | All 4 metrics need the owner, due date, and status fields from Option B or Option C, built in reports. With Option A alone, you can count scheduled re-checks and their later answers, but not owners or due dates. Report speed next to shelf outcomes: speed alone rewards closing too early. ## What to Do When It Goes Wrong | Symptom | Likely Cause | What to Do | | - | - | - | | Issues show as closed but the shelf is still empty | Task completion or a scheduled to-do counted as resolution | Count an exception as closed only when a later answer or photo shows the fix | | A manager's to-do disappeared | A new active to-do for the same account and assignee replaced it | Check for an active to-do before adding one; in flows, add entries to the existing to-do | | Follow-ups pile up with no action | No owner, or the owner can't fix the cause | Assign an owner role per cause category, such as store operations for replenishment | | The same issue appears every week | The cause is upstream: supply, listing, or retailer process | Move it to the monthly review and assign a systemic owner | | The flow didn't create a task | A flow error or entry condition | Add a fault path that emails your admin team, and test the flow in a sandbox | ## Checklist * [ ] Agree the exception fields, severity levels, and cause categories with business owners. * [ ] Choose Option A, B, C, or a combination, and document where each field lives. * [ ] Assign an owner role for each cause category. * [ ] Define what evidence counts as verification. * [ ] Build the flow and reports, and test them in a sandbox. * [ ] Schedule the 30-minute weekly review and keep a decision log. * [ ] Report the loop metrics next to shelf outcomes. ## Industry Best-Practice Context FieldKo's guide [The Exception Loop: How to Turn Audits into Fixes](https://fieldko.com/best-practices/closed-loop-exception-management/) sets out the principles behind this page. To run the loop, use the [Exception and Corrective-Action Log](https://fieldko.com/best-practices/toolkits/exception-action-log/) and the [30-Minute Weekly Execution Review](https://fieldko.com/best-practices/toolkits/weekly-execution-review/) templates. ## See Also * [Keep Products on the Shelf](https://support.fieldko.com/retail-execution/availability.md) * [Measure What Matters](https://support.fieldko.com/retail-execution/measure.md) * [Add Notes and Follow-Ups](https://support.fieldko.com/visits/notes-and-follow-ups.md) * [Log an Incident](https://support.fieldko.com/field-work/log-incident.md) * [Flow Recipes for Field Teams](https://support.fieldko.com/platform/automate/flow-recipes.md) * [Share, Schedule, and Subscribe to Reports](https://support.fieldko.com/managers/platform/share-and-schedule.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.