“My followers dropped” — how to check it properly, in about two minutes

The ticket is always the same. A link, no order number, and a sentence like followers droped fix it. Sometimes there is a screenshot. Usually there is not. What you send back in the next ten minutes decides whether this is one message or eleven.

There are two wrong ways to answer it and both are everywhere. The first is to reply from feeling — there may have been a small drop, we are looking into it — which tells the customer nothing he did not already believe and guarantees a follow-up. The second is to ask him to send a screenshot of his own follower count. You can read that number yourself in about fifteen seconds, and asking for it reads, correctly, as a delay.

There are exactly two exceptions to that, YouTube watch time and Spotify, because those genuinely cannot be seen from outside the account. Asking there is the honest first reply rather than the lazy one. Everywhere else, asking is admitting you did not look.

The three numbers

A drop complaint is arithmetic on three figures, two of which your panel already stored the moment the order was placed.

• Start count — what the account had when the order began. If your panel recorded nothing there, that absence is itself the finding, and there is a section on it below.
• Quantity — what was ordered.
• Live count — what the account has right now. The only one that takes work.

For a completed order, what the account should hold is start + quantity. For one still running, or marked partial, it is start + quantity − remains. The drop is expected − live, and a negative result means the account has gained followers since the order finished. The order is fine and the customer is looking at a number that went up.

That case is far more common than the real thing, and it is worth answering with the actual figures. Started at 12,040, you ordered 5,000, you are sitting at 17,180 — nothing has dropped ends the conversation. Everything looks fine on our side does not, because it is exactly what you would say if you had not checked.

Getting the live count without asking

This is the only part that is any work, and it is different on every platform. What it is not is impossible. One of these needs a paid scraper. The rest are a request and a regular expression.

The case that costs you money

Run the arithmetic often enough and you will find a live count that is below the start count. Not below expected — below start. The account has fewer followers today than it had before your order ever ran.

That is not this order’s drop. It is a loss that predates it. File a refill against this order and you are asking a provider to replace something they did deliver, which they will look at once and refuse. Top it up yourself instead and you have paid for somebody else’s failure, quietly, out of a margin that is already thin.

The fix is to trace back. Pull every order that has ever run against that link, newest first, and walk backwards until you reach the order whose start count sits below the live figure. That is where the loss actually happened. If three orders are implicated then that is three separate claims against three separate order IDs, each going to whoever ran that one — not one claim against the most recent, which is the shortcut that gets rejected.

It is also the reason the customer’s own order number is not enough to work from. He quotes the one he is angry about. You need all of them on that link.

When the panel never recorded a start count

A completed followers or subscribers order with no start count is not a completed order. It is a completion that was written without anything being delivered. On the worst provider we have dealt with, any completed order missing a start count turned out to be exactly that — enough of them, clustered on the same service IDs, that the pattern was the finding rather than the individual orders.

Two things follow. Nothing about it is visible to the customer until the count fails to move, so the ticket arrives days later, by which time you have already paid for it. And you cannot compute a drop on it at all, because there is no start to subtract from. Which means a missing start count has to be a flag in its own right — a case your report raises — and not a null that your arithmetic quietly skips over.

The threshold nobody tells the customer about

Providers do not accept refills for trivial amounts. The line we work to is 100: below it there is nothing to file, above it there is. The mistake is keeping that number to yourself.

You are 60 short right now. Refills only go through from 100, so if it slips further, message me and I will file it the same day is a reply that holds, because it tells the customer what you are actually doing and what will change. Promising a refill you already know will bounce is a reply that comes back in four days, angrier, with the first reply quoted underneath it.

What the reply should look like

Specific, and without an apology you do not owe. If the order is fine, say so with the numbers and no sorry — an apology on a correct order tells the customer something went wrong, which is the opposite of what you just proved. If it did drop, name the figure. 4,896 dropped, refill filed today is a different message from there has been a drop and we are on it, and only one of them stops the thread.

And it is worth being honest about what the two minutes actually consist of. Read the ticket end to end, because customers drop a second and a third order ID halfway down and a reply that answers only the first one is a reply you will write twice. Pull every order on the link rather than the one he quoted. Get one live number. Subtract.

That is the whole job. It is not difficult. It is just fifteen times a day, and it is the fifteen times a day that decides whether the panel feels run or merely open.