Your WhatsApp quality rating dropped: what actually caused it
A rating drop almost never means the platform is being unfair. It means a specific group of people reacted to a specific message in the last seven days. Here is how the score is built, the five causes I check in order, and what it costs you while it recovers.


A rating drop almost never means the platform is being unfair. It means a specific group of people reacted to a specific message in the last seven days. Here is how the score is built, the five causes I check in order, and what it costs you while it recovers. In this deep dive, we explore actionable strategies, real-world engineering blueprints, and future-proof patterns to elevate your digital operations.
The message I get most often about quality ratings sounds like this: "We sent the same broadcast we always send, and this time the number went yellow. Nothing changed on our side."
Something did change. The rating is not a verdict on your business, and it is not random. It is a summary of how a specific group of people reacted to a specific set of messages in the last seven days. Once you accept that framing, the drop stops being bad luck and becomes a question with an answer.
What the rating actually measures
WhatsApp builds message quality from how users received your messages over the past seven days, weighted by recency. The signals are user feedback: blocks, reports, mutes, archives, and the reasons people give when they block you. That is the entire input. Not your reply rate, not your revenue, not how well-written you think the copy is.
Two things follow from that, and both matter more than any dashboard detail.
It is a lagging indicator. A campaign that goes out on Monday can show up on Thursday, because the window is a moving seven days and older feedback fades as it ages out. Fixing the cause today does not fix the number today.
It is per phone number, and it is displayed in WhatsApp Manager under Account tools → Phone numbers alongside your status and messaging limits. If you run more than one number, check each one before you do anything else — a single number with an aggressive campaign can look like a company-wide problem.
Template quality is a second, separate rating, and people mix the two up constantly. Every template carries its own GREEN, YELLOW, RED or UNKNOWN score, based on usage, customer feedback and read rates. A template at RED can still be sent, but the docs are explicit that it is in danger of being paused or disabled, and continuous negative feedback or low engagement can eventually change its status — at which point it cannot be sent until it is APPROVED again.
The five causes I check, in this order
1. You messaged people who never opted in
This is the cause more often than the other four combined. Somebody exports a customer list from the billing system, drops it into a campaign, and calls it a re-engagement push. Those people bought from you — they never agreed to receive promotional messages on WhatsApp.
WhatsApp rates quality on feedback, and unsolicited messages produce the exact feedback that hurts: blocks, reports, and "this business is sending me things I did not ask for" as the reason. A few hundred of those in a week is enough to move a number.
The fix is not a better subject line. It is a consent record per contact that says when and how they agreed. If you do not have that, the list is not sendable.
2. Marketing content wearing a utility template
Utility templates are for things the customer already expects: order updates, invoices, appointments. Marketing templates are for offers. Sending an offer through a utility template gets you two problems at once — a likely category correction, and a read rate that does not match the category you claimed.
Low read rates feed template quality directly. The docs name low read-rates as a reason a template lands at YELLOW or RED, alongside negative feedback. So a "utility" message that people ignore quietly drags the template down even when nobody actively blocks you.
3. Frequency
"Too many messages per day" is one of WhatsApp's own listed guidelines for high-quality sending. Most teams that hit a quality problem are not sending bad messages. They are sending reasonable messages too often, to the same people, from three different systems that do not know about each other.
Before you rewrite content, count. How many template messages did a single customer receive in seven days, across every automation you run? In my experience the answer is usually three to five, and nobody intended it.
4. Read the block reasons, not the count
Blocks tell you what happened. Block reasons tell you why. If the reasons cluster around "too many messages", the problem is frequency. If they cluster around "not relevant", the problem is targeting, or an offer aimed at the wrong segment. If they cluster around "I did not sign up for this", you have a consent problem and no amount of copy editing will fix it.
One session reading actual block reasons is worth more than a week of guessing.
5. The traffic that is not yours
Numbers with high traffic commonly see quality changes within short intervals, sometimes within minutes — that is in the platform docs, not an excuse I invented. A spike in volume from a retargeting campaign, a seasonal sale, or a partner sending through the same portfolio can move the rating before anyone on your team sends anything unusual.
This is why the first question is always "what went out in the last seven days", not "who broke the account".
What the drop actually costs you
Two costs, and the second one is the one people miss.
Templates at risk. A template at RED is in danger of being paused. If it becomes unapproved, every automation that depends on it stops working — and the team usually finds out from a customer, not from the dashboard.
Scaling stalls. Messaging limits are now calculated at the business portfolio level and shared across all numbers in that portfolio. A new portfolio starts at 250 unique recipients per moving 24 hours, moves to 2,000 by completing a scaling path, and only then scales automatically to 10,000, 100,000 and unlimited. Automatic scaling requires high-quality messages across your numbers and templates, plus using at least half your current limit in the last seven days.
So a quality dip does not just risk one template. It parks your ceiling exactly where it is, at the moment you were about to grow into it. For a business whose WhatsApp volume is seasonal, that timing is the whole cost.
The first 48 hours
- List every template message sent in the last seven days, with the audience source for each. Anything without a consent record gets paused today.
- Read the block reasons in WhatsApp Manager. Classify them into frequency, relevance, or consent.
- Check each template's quality score separately. Pause the RED ones; do not "send a bit less" and hope.
- Stop all promotional sending from every system that touches the number until you have the list above.
- Then resume with the smallest useful campaign, to opted-in people only, and watch the score daily.
That last step matters. The window is seven days and recency-weighted, so the number usually recovers only after the bad week has aged out, even if you stopped the cause on day one. Expect a lag and do not restart sending early because the dashboard looks better.
If you are not sure where your sends are actually coming from, that is usually an architecture problem rather than a content one: multiple tools writing to one number with no single place recording who was messaged and why. That is the problem BNex is built to solve — one inbox and one record of every conversation, so a campaign cannot hide behind three automations. If you want the mechanics of the template side, the template approval guide walks through categories and rejection reasons, and pricing explained covers what each conversation type costs you.
If this is happening to you right now and you would rather have someone look at the account with you, message me on WhatsApp and describe what went out in the last week. I have seen most versions of this.
Related Reading
Get more insights like this
Join our list for practical automation, web engineering, and growth strategy — written by builders, for builders.

Manikandan S
Founder & Technical Lead at ZiyncFounder and technical lead at Ziync. I build high-performance websites and web applications for startups and mid-market teams: React, Next.js, Firebase. Based in Chennai, working with clients worldwide.