A problem at three branches is a pattern, and a bad day at one branch is an incident. You tell them apart by checking four things: how many separate branches raised the same complaint, whether the complaints were read the same way at each branch, whether they are spread over days or stacked into one afternoon, and whether the branches share something that could explain them. One branch with ten complaints in a single shift is usually an incident. Three branches with a few complaints each on the same topic over several weeks is usually a pattern, even though no single branch looks alarming.
This guide sets out how to make that call, what evidence is enough, and what to do while you are still unsure.
Why head office gets this wrong
Head office tends to be wrong in one of two directions. It treats a bad day at one branch as a trend and sends out a company-wide reminder, or it treats a real pattern as a run of unrelated incidents because each branch manager explained their own case away.
The second mistake costs more. Each branch has a reasonable story: a staff shortage, a delivery delay, a busy weekend. Nobody sees all the stories together, because the people who could join them up are on separate sites.
Four checks that separate a pattern from an incident
1. Count branches, not mentions
Ten complaints from one branch tell you about that branch. Three complaints from each of three branches tell you about something the branches share. The number of separate locations raising a topic matters more than the total count.
This is why Outhentik defines an issue as a topic raised as a complaint in two or more messages and shows how many branches it appears at, and since when. Whatever you use, make the branch count the first thing you look at.
2. Check that the complaints mean the same thing
Complaints only add up if they were sorted the same way. If one manager logs "long wait" and another logs "slow service", your totals will not join up and a pattern can hide in the gap.
Use one reader and one scheme for every branch. A complaint at branch 40 should be measured like one at branch 3, and anyone looking at a figure should be able to open the original message behind it.
3. Look at the timing
Plot when the complaints arrived, in days, not just in total.
- Stacked into one shift or one day: more likely an incident. Look for the cause on that day, such as an absence, an equipment fault, a delivery or an event nearby.
- Spread across several weeks: more likely something structural, such as a process, a supplier, a menu or a rota rule.
- Starting on the same date at several branches: look for what changed on that date, such as a new supplier, a policy, a system update or a promotion.
4. Look for something the branches share
Ask what the affected branches have in common that the others lack. It might be the same supplier, the same regional manager, the same opening hours, the same software version, the same recent hire or the same type of site.
If you cannot find anything shared, that does not clear the pattern. It may mean you do not yet know enough about the branches. Write down the hypothesis anyway and test it.
How much evidence is enough
There is no number that works for every business, and a figure quoted without looking at your volumes is a guess. What you can do is set a rule before you look at the data and apply it the same way to every branch.
A workable approach has three parts.
- Set a minimum number of mentions per branch before you compare that branch with others. Outhentik marks a location with fewer than five mentions of a topic as low evidence and does not rank it. A handful of mentions is an anecdote.
- Treat the branches that fall below the minimum as unknown on that topic, not as fine.
- Decide in advance what you will do at each level: read the messages, call the branch manager, send someone to look, change a process.
The rule matters more than the exact number. Without one, the loudest branch decides the agenda.
Silent branches change the picture
A branch with no complaints might be excellent, or its customers might have no easy route to tell you. Before you decide a problem is limited to three branches, check which branches produced any messages at all in the period.
If twelve of twenty branches sent nothing, a problem found at three of the eight that did is a very different finding from a problem found at three of twenty. Show coverage next to every pattern you report.
What to do while you are unsure
You do not have to settle the question before you act. Match the action to your confidence.
- Read the actual messages from each branch. Ten minutes of reading usually beats an hour of charts.
- Call the branch managers and ask them what happened that day, without framing it as a charge.
- Contact any customer who asked to hear back, whatever you decide. A customer waiting for a call does not care whether the problem is a pattern.
- Put the topic on a watch list with a date to review, and check again after a set period.
- If it grows or spreads, move from watching to fixing, with a named owner.
What not to do
- Do not rank branches on raw complaint totals.
- Do not send a network-wide instruction after one bad day.
- Do not accept a branch manager's explanation as the whole answer when three branches have the same story.
- Do not read silence as proof that a branch has no problem.
- Do not wait for a certain answer. A pattern is confirmed over time and you usually have to act earlier.
Where Outhentik fits
Outhentik gives head office a direct line from customers. Every message is read the same way at every branch, and a problem raised at two or more branches becomes an issue on the daily brief, with the branches it appears at and since when. A location with too little evidence is marked as low evidence, and a branch that sends nothing shows as unknown. It does not do the diagnosis for you, and it depends on customers sending messages. Whether enough of them do to make the branch view useful is the first thing every rollout finds out.
Frequently asked questions
How many branches does a problem need to appear at to count as a pattern?
Two separate branches is the lowest sensible threshold, and Outhentik's definition of an issue starts there. Three or more with the same topic over several weeks is stronger. What counts depends on how many branches you run, so set your own rule in advance.
What is the difference between an incident and a trend?
An incident is tied to a specific time and place and has an identifiable cause, such as a staff absence or an equipment fault. A trend shows up across places or time and points to something the branches share, such as a process, a supplier or a policy.
How do I stop one noisy branch from skewing the picture?
Count the number of separate branches that raise a topic, not the total mentions, and apply a minimum number of mentions before a branch is compared with others.
Should I act on a problem before I know whether it is a pattern?
Yes, in proportion. Read the messages, call the managers and contact the customers who asked to hear back. Save the large, company-wide actions for when the pattern is clear.
What if the branches have nothing in common?
Then you may lack the information to see it, or it may be coincidence. Keep the topic on a watch list and set a review date.
Can a quiet branch have the same problem without showing it?
Yes. Silence can mean no problem or no route to tell you. Check coverage before concluding that a problem is limited to the branches where it appeared.
Is this something I can do without software?
For a few branches, yes, with a shared sheet and discipline about how complaints are logged. It gets harder once several people sort complaints differently or when you need the original message behind each figure.
Try Outhentik free for 7 days, no credit card required
Outhentik gives head office a direct line from customers at every branch: a case with an owner for each customer who asks to hear back, every message read the same way, and a daily view of which problems repeat and where. For a head office trying to tell a pattern from a bad day, that means counting branches, reading every message the same way and showing silent branches as unknown.