Skip to main content
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.
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.

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.

Set Severity

Agree severity levels with your business owners. These are examples, not an industry standard:

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 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.
  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.
  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.
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.

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.
  2. The incident records the account and the visit. Managers see it on the Incidents tab. See 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 and Notifications and Email Alerts.
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 and Design Automation for FieldKo.
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. 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

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

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 sets out the principles behind this page. To run the loop, use the Exception and Corrective-Action Log and the 30-Minute Weekly Execution Review templates.

See Also

Last modified on October 26, 2026