Customer complaints fall through the cracks: one log that closes the loop

Short answer: complaints get lost because they arrive in many places and each place has its own owner, or none. One way to start is a single log. Every complaint gets one row with an owner, a severity, a due date and a status. A row is closed only after someone tells the customer the result. Then you review the log for causes that repeat.

At a glance

Swipe sideways to see all columns.

Item	Number	What it means for you
List view threshold	5,000 items	A view that must scan more than this many items at once can be blocked. Filter on indexed columns.
Items in one list	30 million	Far more than a request list will ever need, so size is not the concern.
File attached to a list item	250 MB	Larger files belong in a document library, with a link in the row.
Flow that keeps failing	14 days	A cloud flow with a trigger or action that fails nonstop is turned off. Check run history.

Why complaints disappear

A complaint can arrive on a phone call, in an email, in a chat message, or in a note passed along by a coworker. Each person who hears it may plan to deal with it. Then a busy day happens. The complaint stays in a voicemail, an inbox or a chat thread that nobody opens again.

Four causes show up often:

There is no single place. Each channel holds a piece, and no one sees the whole.
There is no owner. The person who heard it assumes someone else will act.
There is no due date. A complaint with no date is never late, so it never feels urgent.
Nobody tells the customer. The team fixes the problem, but no one says so. The customer still thinks it was ignored.

Signs this is happening in your team

A customer calls a second time to ask what happened.
Two people answer the same complaint in different ways.
You learn about a complaint from a manager, not from your own system.
The same problem comes up again and again, and nobody can say how many times.
Your lead keeps a private list and chases people one by one.

Step 1. Decide what counts as a complaint

Before you build anything, write one sentence that says what goes in the log. For example: "Any message where a customer says something went wrong or they are unhappy." Keep it broad at first. It is easier to drop a small item later than to find a lost one.

Also decide who may add a row. One way to start is to let anyone on the team add one, so the person who hears it can log it in under a minute.

Step 2. Log it once, in one place

Pick one list for all complaints, no matter how they arrive. A SharePoint list can do this. Microsoft describes lists as a way to share a collection of data with your team, and you can create them in SharePoint, the Lists app in Microsoft 365, or Microsoft Teams.

Give the list a few columns:

Summary (one line: what went wrong). This is the Title column that every list has. Title is required by default, so rename it to Summary.
Channel (Phone, Email, Chat, Other)
Customer (name of the account, not private details)
Severity (1 High, 2 Medium, 3 Low). The number prefixes make the choices sort in the right order.
Owner
Due date
Status (New, In progress, Waiting on customer, Closed)
Cause (a short pick list, see Step 6)
Customer told? (Yes or No)

Microsoft's page on lists names several column types, including Choice and Date and Time. Those cover Channel, Severity, Status, Cause and Due date.

Step 3. Give every row an owner the same day

A complaint with no name on it is not being handled. Make it a rule that the person who logs it also puts an owner on it, even if the owner is themselves. The owner can hand it off later, but the column is never empty.

If you use a shared inbox for complaints, see "Requests lost in a shared inbox: add an owner and a status" for the same idea applied to email.

Step 4. Set severity and a due date

Severity tells people what to do first. Keep it to three levels and write one line for each so people choose the same way. Number the choices so they sort in order. One way to start:

1 High: the customer cannot use what they paid for, or may leave.
2 Medium: the customer is annoyed but can keep working.
3 Low: a small issue or a suggestion.

Then set a due date for each level. Pick dates your team can meet. For example, 1 High is due the next business day, 2 Medium within three business days and 3 Low within a week. These numbers are only a starting point. Change them after you see how long the work really takes. For late alerts, see "Late tasks nobody notices: setting up late alerts".

Step 5. Close the loop with the customer

This step is the one most teams skip. A complaint is not closed when the problem is fixed. It is closed when the customer hears what you did.

Add a rule: a row cannot move to Closed until the "Customer told?" column says Yes. The message can be short. Say what went wrong, what you did, and what you will do to stop it from happening again. If you could not fix it, say that and say why.

You can also make the Status "Waiting on customer" when you need more information, so the row does not look stuck for the wrong reason.

Step 6. Look for repeat causes

A log gives you something a pile of emails cannot: a count. Once a month, filter the list by Cause and see which ones come up most. Microsoft notes that list views can organize, sort and filter data and can group items, so a grouped view by Cause is a good place to look.

Keep the Cause list short, about six to eight choices, such as "Late delivery", "Wrong item", "Billing error", "Unclear instructions" and "Slow reply". Add "Other" and review it. If "Other" grows, add a new choice.

Then ask one question for the top cause: what change would stop this from happening? Write down one change, give it an owner and a date. That is how complaints go down over time, not just get answered.

Step 7. Add a reminder

You can have a flow check the list each morning and message owners whose items are due soon or past due. Microsoft's page on triggers says a scheduled cloud flow runs at a specific time or on a recurring schedule, such as every day at 10:00 AM. Send one message per person, not one per row, so the message does not get ignored.

Honest limits

A log does not fix the cause of a complaint. It makes complaints visible and gives each one a name and a date. If the team is understaffed, rows will still go late. A log also depends on people adding rows. If staff skip the log when they are busy, you will undercount. Start with one channel, such as the main support email, add the others once the habit holds, and ask the team each week which complaints they heard that are not in the list. This guide covers tracking only. It is not advice about customer-service rules or legal duties.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Updated 2026-10-27.

Who should own a complaint?

The person best able to fix it, not the person who happened to hear it. The person who hears it logs it and names an owner. If no one is sure, a team lead assigns it the same day.

Should every small comment be logged?

One way to start is to log anything the customer says is wrong. 3 Low severity rows are quick to close. After a month, look at what you log and decide whether to narrow the rule.

Can I use Excel or a shared inbox instead?

You can, but a shared file is easy to edit in two places and an inbox mixes complaints with other mail. A list gives you filters, views and one row per complaint. The key rules matter more than the tool: one place, one owner, one date.

How do I catch complaints that come by phone?

Ask staff to add a row right after the call, with a one-line summary. Keep the form short so it takes under a minute. Check once a week that phone complaints appear in the log.

How do I know the fixes work?

Compare counts by cause month to month. If the top cause drops after a change, the change helped. If it does not, pick a different change.