Open any SMM panel's order page and you are met with a row of statuses — Pending, In Progress, Processing, Partial, Completed, Canceled — plus buttons marked Refill, Cancel and Drip-Feed. Most panels explain none of it. Customers guess, guess wrong, and open tickets.
This is a reference for what each one actually means, what it costs you as a panel owner, and which ones cause the support load.
The order lifecycle
An order moves through a small number of states. The names vary slightly between panel scripts, but the underlying flow is the same everywhere.
Launch your own SMM panel
Deploy a branded panel on your own domain in minutes — no server setup.
Pending — the order exists and has been paid for, but has not reached the provider yet. Either your panel has not forwarded it, or the provider has accepted it into a queue that has not started. Nothing has been delivered.
In progress / Processing — the provider has started. Some panels distinguish the two: Processing meaning accepted but not visibly moving, In progress meaning delivery has begun. Treat them as the same stage for customer communication.
Completed — the provider reports the full quantity delivered. Note carefully: completed means delivered, not still there. Retention is a separate question.
Partial — the provider delivered some of the quantity and stopped. The unfulfilled remainder is refunded to the customer's balance automatically on most panels. This is normal, not a fault.
Canceled — the order was not delivered and the full amount is returned to the customer's balance.
Fail / Error — the provider rejected the order outright, usually because the link was invalid, the account was private, or the service was out of stock.
The two that generate the most tickets are Partial and Completed — Partial because customers read it as failure, Completed because customers read it as a permanent guarantee.
Why Partial is not a failure
A partial completion means the provider ran out of supply part-way through. Say a customer orders 10,000 and receives 6,400. The panel refunds the value of the missing 3,600 to their balance, and the order closes as Partial.
From the customer's side this feels like something went wrong. From an operational side it is the system working correctly: they were charged for what arrived.
The support load comes from the refund being invisible. The money goes back to a panel balance, not to their bank, so unless your panel says so clearly, they experience it as paying for 10,000 and receiving 6,400. Put a line on the order page stating the refunded amount explicitly. It removes most of these tickets.
Refill: what it covers and what it does not
Refill exists because delivery is not the same as retention. Followers or likes can be delivered correctly and then decline over the following days as platforms remove inactive accounts.
A refill guarantee means that within a stated window — commonly 30 days, sometimes 60 or 90, sometimes "lifetime" in marketing copy — you will top the count back up to the delivered figure if it drops.
Three things to be precise about, because each one becomes a dispute otherwise:
The window starts at completion, not at purchase. If an order sits pending for two days, a 30-day refill runs from the completion timestamp.
Refill restores to the delivered level, not the ordered level. If a partial delivered 6,400 and drops to 6,000, refill takes it back to 6,400, not to the original 10,000.
Refill is inherited from your provider. If you sell a 30-day guarantee on a service whose provider gives you 15 days, you are covering days 16 to 30 out of your own margin. Check the provider's terms per service, not per provider — they often differ across a single provider's catalogue.
Refill is usually a button on the order. Some panels expose a refill status — Pending, In Progress, Completed — because it is itself an order placed upstream.
Cancel: rarer than customers expect
The Cancel button looks like it should always work. It usually does not.
Cancellation is only possible while an order is still cancellable upstream — typically Pending, occasionally early In Progress. Once a provider has begun delivering, there is nothing to cancel; the work is partly done and the cost is incurred.
Panels handle this in one of two ways: hide the button once the order is in progress, or show it and return an error. Hiding it is better. A button that fails teaches customers that your panel is broken.
Where cancellation does succeed, the amount returns to panel balance, same as a Partial refund.
Drip-feed: delivery spread over time
Drip-feed splits one order into scheduled batches instead of delivering everything at once. You set three values:
- Quantity per run — how much is delivered each batch
- Number of runs — how many batches
- Interval — minutes between batches
Quantity per run multiplied by runs equals total delivered, and that total is what you are charged for. A drip-feed of 100 × 10 runs × 30 minutes delivers 1,000 over five hours.
It exists because a sudden spike looks unnatural. A post gaining 5,000 likes in ninety seconds reads very differently from one gaining them across a day, both to human viewers and to the platform's own signals.
Two operational notes. Drip-feed orders occupy provider capacity for their whole duration, so a long schedule is more exposed to a provider running dry mid-way — expect partials more often. And the interval is a minimum, not a promise; providers queue batches like any other order.
Services you should understand before selling
Three distinctions cause most mis-sold orders.
No-refill versus refill. The same nominal service at two prices. The cheap one has no guarantee and will drop. Selling it as though it were the guaranteed version is how you end up honouring refills out of your own pocket.
Real versus bot. Higher-priced services claim engagement from accounts with activity history. Cheaper ones do not. Retention differs enormously and so does customer satisfaction.
Speed tiers. "Instant", "fast", and "slow" variants of the same service at different prices. Instant usually means the provider has stock in hand; slow means it is sourced on demand. Slow services partial more often.
Your service descriptions should state the refill window, the expected start time, and the speed, for every service. Most panels ship with the provider's raw description pasted in, which is written for resellers rather than end buyers, and is where a large share of avoidable tickets originate.
Mapping statuses to customer messages
The statuses are internal vocabulary. What the customer needs is a plain sentence.
| Status | What to tell the customer |
|---|---|
| Pending | Received. It will start shortly. |
| In progress | Delivery has started. |
| Partial | Delivered X of Y. The difference has been returned to your balance. |
| Completed | Fully delivered. Covered by refill until [date]. |
| Canceled | Not delivered. The full amount is back in your balance. |
| Fail | Could not start — usually a private account or an invalid link. |
Showing the refill expiry date on completed orders is worth doing. It converts a vague guarantee into a specific date, and it stops requests arriving months later.
The support pattern worth pre-empting
The most common ticket on any panel is some version of: "My order says completed but the count went down."
This is not a bug, and it is not usually a bad provider. It is the gap between delivery and retention, which is exactly what refill exists to cover. Panels that explain this on the order page — one line about drop and how to claim a refill — cut that ticket category substantially.
The second most common is "My order is still pending." Publish a typical start time per service, and the number drops. Customers are generally patient when they know what to expect and impatient when they do not.
Neither of these requires new features. Both are copy.
