Failed Store Visits: Reason Codes and Rescheduling Steps

To handle a failed store visit, record it with one reason code, attach the evidence required for that code, assign a named owner, set a dated next action, and keep it out of the completed-visit count until review and closure. The most common failure in practice is not the missed call itself — it is a failed attempt either being logged as a completed visit or left with no reason and no owner, so it disappears from the follow-up queue. Reporting should distinguish attempted visits from completed visits, and both from task outcomes.

reason codes for failed store visits in FMCG field sales — Failed store visit process: record a reason code, attach evidence, assign an owner, set a dated next action, then review, reschedule or escalate.

Define attempted, completed and failed visits before you count anything

Field teams need three distinct visit states, agreed before rollout, because they drive different actions:

Attempted visit. The rep reached the planned location within the route window, but the visit objective could not be carried out. Record it with a reason code.
Completed visit. The rep reached the outlet and the planned store tasks were carried out. Whether it counts as productive depends on your own task rules.
Partial or incomplete visit. The rep reached the outlet and finished some tasks but not all. This is separate from a failed visit and should be tracked separately, otherwise incomplete execution is hidden inside a success rate.

For any coverage or compliance figure, state the numerator, the denominator, the time period and the exception policy — for example, how a store temporarily closed for renovation is treated in a coverage rate. Suggested measures such as scheduled versus completed visits, required-field completeness and follow-up completion are evaluation measures, not guaranteed improvements.

Reason codes that cover most failed store visits

A short, controlled list works better than free text. A practical starting taxonomy:

Reason codes for failed store visits and the action each one triggers
Reason code group	Typical situation	Evidence to record	Typical next-action owner
Outlet closed — unplanned	Shutters down, holiday closure, no staff on site during opening hours	Timestamped check-in, outlet ID, note of time and visible state	Field rep reschedules within the route cycle
Outlet closed — ceased trading or vacant	Premises gone, tenant changed, unit empty	Note, confirmation from the distributor or local contact, photo where policy allows	Sales operations updates master data with approval
Contact unavailable	Decision maker absent, staff cannot accept stock or sign	Note naming who was present and the last known contact pattern	Field rep books a return time; manager tracks repeat cases
Access refused — buyer decision	Buyer declines the call, the order or the audit on that day	Note of the stated reason and the person who gave it, where permission allows	Area manager or key account owner
Access refused — store policy	Chain or site policy bars visits, van sales or photographs	Note of the policy; no photograph if it is not permitted	Channel or key account team
Incomplete task	Visit happened, but planogram checks, orders or audits were not finished	Task list showing which tasks were done and which were not	Field rep or area manager, depending on the task
Location or route error	Outlet relocated, address in master data is wrong, route window too short	Note, corrected address or coordinates where available	Sales operations corrects master data
Safety or access restriction	Site security, weather, local restrictions, unsafe conditions	Note and manager notification	Area manager
Other (capped)	None of the above	Short mandatory note	Area manager reviews weekly and proposes new codes

Cap the share of visits recorded as ‘other’. If ‘other’ grows, the taxonomy is wrong, not the field team.

What evidence must a failed visit record contain?

A check-in or a photograph on its own does not establish that a task was completed correctly. Use a completeness checklist instead of an assumption about any particular detection capability:

Time and rep identity for the check-in or attempt record.
Store ID or outlet identifier that matches master data.
One reason code from the controlled list.
A short note in the rep’s own words, written on the spot.
Photo only where the outlet policy and local rules allow it, and only where the reason code requires it.
The task or task list, with each item marked done, not done or not applicable.
A next action with a date and an owner.
A review status — unreviewed, accepted, queried or escalated.

Ask an internal question before rollout: can a reviewer reconstruct, from the record alone, what happened, when, where and what happens next? If not, the evidence fields are incomplete.

Who owns what after a failed visit?

Field rep: records the outcome at the point of failure, selects the reason code, writes the note, proposes the next date.
Area or field manager: validates reason codes in review, owns escalation for repeat refusals, approves reassignment of the visit.
Sales operations: maintains the reason code list, the closure rules and the master data behind route plans; owns coverage definitions.
Distributor or partner operations: where visits are run by third-party teams, agrees the same reason codes and evidence fields so reporting is comparable.
Key account or channel team: takes ownership of persistent access refusals that sit above store level.

How to reschedule a failed store visit in order

Record immediately. Log the outcome at the outlet, not at the end of the day from memory.
Assign exactly one reason code. One code, one primary cause; add detail in the note.
Decide recoverability. Can the visit still be completed in the same route cycle? If yes, reschedule inside the cycle.
Set the next action. Date, owner and objective — for example, ‘return Thursday morning to meet the owner,’ not ‘follow up.’
Update the route or call plan. A rescheduled visit without a slot in the plan is a promise, not a plan.
Review within the agreed service window. A manager accepts, queries or escalates the record; unreviewed records should not sit indefinitely.
Escalate patterns, not one-offs. Three refusals or closures at the same outlet within a defined period usually need a manager or account decision rather than another rep attempt.
Fix the data. If the outlet has moved or closed permanently, raise a master data change instead of rescheduling forever.

When can a failed visit be closed?

A failed visit can be closed when all of the following are true:

A reason code from the controlled list is recorded.
The evidence fields required for that code are complete.
A next action exists with a date and a named owner, or a documented decision has been made to stop visiting the outlet.
A review status has been set by a manager or operations reviewer.
Any master data correction triggered by the visit has been raised or completed.

If any of these is missing, the case stays open. Closed does not mean the visit succeeded; it means the follow-up loop is complete.

Common mistakes to avoid

Marking a failed attempt as a completed visit, which inflates coverage and hides the real problem.
Using ‘other’ for most failures instead of maintaining the taxonomy.
Recording a next action with no date, or with the rep as default owner when the decision belongs to a manager.
Attaching a photo with no timestamp, store or context, which cannot be reviewed later.
Rescheduling the same outlet every cycle without ever escalating the underlying cause.
Publishing coverage numbers without an exception policy for closures, refusals and holidays.

How to verify the process is working

Attempted visits versus completed visits, by territory and period.
Distribution of reason codes, including the share of ‘other’.
Percentage of failed visits with a next action that has both a date and an owner.
Follow-up completion rate against those scheduled next actions.
Repeat failure rate at the same outlet within a defined window.
Evidence completeness on failed visits, measured as a required-field check.

Define each figure as numerator over denominator for a stated period, and agree who reviews it and how often.

Prerequisites and limitations

This process depends on clean store master data, an agreed reason code list, consistent route windows and a review routine. Practical limits matter too: mobile connectivity at the outlet, local rules and store policies on photography and personal data, different permissions between a rep’s app and a manager’s view, and mixed teams where distributor staff record visits in another system. Agree these points before you publish any coverage or compliance figure.

Questions to ask an SFA vendor about failed visits

Show the failed-visit flow using our own reason codes and our sample stores.
Which fields are mandatory before a record can be saved, and who can override them?
How are attempted and completed visits separated in reporting, and can the definition be configured?
How does a rescheduled visit appear in the route plan, and what happens if it is missed again?
What review and escalation statuses exist, and who can set them?
What data is required to set this up, and what integration or permission scope is involved?

Airpalm’s public site describes mobile visits, route planning, store audits, sales orders, inventory and promotion management. If those workflows match your operating model, evaluate them against your own failed-visit scenarios rather than a generic demo, and confirm the required fields and permissions directly. Start from the Airpalm global site, and see the overview of what sales force automation is and how it works in FMCG for the wider workflow context.

Frequently asked questions (FAQ)

Should a rep still run a store audit when access was refused?

No. Access refused is a recorded outcome, not a partial audit. Record the refusal reason code, note who refused and why where permission allows, then set the next action and owner. Running a visual audit from outside the store or after being refused can breach store policy and local rules on photography and personal data.

How many times should a failed visit be rescheduled before it escalates?

There is no universal number, so define one locally and apply it consistently. A workable rule is to allow in-cycle rescheduling for one-off closures and unavailable contacts, then escalate to the area manager after a small number of failures at the same outlet within a defined period. Persistent access refusals usually need a manager or key account decision, not another rep attempt.

Who should own the reason code list?

Sales operations should maintain the controlled list and the definitions behind it, with area managers proposing additions from the field. Field reps select codes; operations owns the taxonomy. Review the list periodically and keep the share of ‘other’ low, because a rising ‘other’ share usually means the codes no longer match what reps actually encounter.

Can poor evidence quality count as a failed visit?

Treat it as an open case rather than a failure of the visit. If the record lacks a time, store, reason code, note or next action, a reviewer should query or escalate it so it can be completed. A check-in or photo on its own does not establish that a task was performed correctly, so evidence quality is a review question, not an automatic conclusion.

Put this guide into practice

This general-purpose worksheet is a starting point. Adapt its fields, responsibilities and rules to your business process.