Drip feed: when spreading delivery helps and when it hurts

An order that arrives all at once is easy to read: the count moves, the order completes, the wallet is settled. A drip-feed order is harder, because the same quantity arrives in pieces and the order page can say completed while the count is still catching up. This guide explains what the drip-feed flag describes, which situations reward pacing, and which ones punish it.

The short version is that pacing is a delivery method, not a quality grade. It changes when the units arrive and when the refill clock starts. It does not change the price, the quantity or the supplier's obligation. Once you know which clock you are on, the order page becomes readable.

What the drip-feed flag describes

A drip-feed service splits one order into several runs. Each run delivers a share of the quantity, then the supplier waits for an interval before the next run. The customer sees one order, one charge and one order id. The supplier sees a schedule.

The flag on a service row is a claim about that schedule. In this catalogue the flag is stored on the service and on the market offer, and it is read from the service name and description when the market is crawled. The flag tells you that the seller describes the service as paced. It does not tell you how many runs the supplier will use, how long the interval is, or whether the supplier will honour the schedule on the day you order.

In the current catalogue, 995 of 4,571 active services carry the drip-feed flag. That count is a property of the rows, not a promise about any single order. A row can carry the flag and still be delivered in one block if the supplier changes its method.

Suppliers offer paced delivery for three reasons. It spreads the load on an account pool that is shared with other orders. It reduces the size of a single spike, which matters when an account has organic activity and a sudden jump would sit outside its normal range. And it lets a supplier accept a large quantity without holding the whole pool at once. None of those reasons is about giving you a better result. They are about the supplier's capacity.

The symptom that brings people here

What you see: the order says in progress, the count moves by a few hundred every few hours, and the remains number barely changes. Or the order says completed and the count is still short of the ordered quantity.

What it means: the first case is a drip schedule doing what it says. The second case is either a delivery dispute or a drop after completion, and the two have different remedies.

Next action: open the order page, write down the start count, the current count and the remains, then check whether the service row carries the drip-feed flag. If it does not, ask support why the delivery is arriving in steps.

The distinction between a drip delivery and a partial delivery matters. A drip order is still delivering. A partial order has stopped and the supplier has reported the missing units. The order page should show which one you have. If it shows in progress with a falling remains, the supplier is still working. If it shows partial, the supplier has stopped and the missing share is a refund question.

What the panel sends when you order

The order call carries three fields: the supplier's service id, your link and the quantity. It does not carry a run count, an interval or a start date. That is the whole request. The supplier's default schedule applies to any service that is paced.

This has two consequences. First, the checkout cannot offer a "spread this over five days" control, because the supplier API call does not accept one. Second, a drip-only service that requires an explicit run count can reject the order. When that happens, the order is canceled before the wallet is charged, and the order page says so. You have not lost the money; you have lost the attempt.

If the schedule is part of your plan, confirm it in writing before you pay. Ask two questions: how many runs will the supplier use, and how long is the interval between them. If support can state both, you can compare the answer with what the order page shows. If support cannot state either, treat the row as a one-shot delivery with a drip label and plan accordingly.

When spreading delivery helps

An account with existing organic activity. A profile that already gains followers at a steady rate has a daily delta. A large one-shot delivery creates a step that is easy to see against that delta. Pacing keeps each step closer to the account's normal range. This is not a guarantee that the platform will ignore the order. It is a reason the shape of the delivery can matter.

A large quantity on a small account. A hypothetical 50,000 unit order on an account with 2,000 followers is a visible change no matter how it arrives. Spread over several days, each daily change is smaller. If the goal is to avoid a single large jump, pacing is the mechanism that does it.

A service that only sells paced delivery. Sometimes the row you need for a country, a category or an account type is a drip row. The alternative is a different supplier with a different pool. In that case pacing is the price of access, and the useful question is whether the schedule fits your deadline, not whether pacing is ideal in general.

An order you expect to refill. A refill request requires a completed order. If a drip order takes several days to complete, the refill clock starts later, and the replacement covers a later period. That can be useful when the drop risk is concentrated in the weeks after delivery rather than in the first hours. It is not useful when you need the refill remedy available immediately.

When spreading delivery hurts

A time-bound campaign. A launch, a live event or a sale has a moment. A drip order delivers across days, so the count at the moment is a fraction of the order. If the campaign needs the number now, pacing works against the plan. The charge is the same whether the units arrive today or next week.

A second order on the same link. This panel refuses to send two active orders for the same service and link to a supplier, because the supplier rejects the duplicate. The second order is stored as queued behind the first and released when the first finishes. A drip parent can run for days, while the second order's queue timeout is measured in hours. The second order therefore refunds long before the parent completes. If you need two orders on one link, place them as one order with the combined quantity, or wait for the first to finish.

A refill that is needed during delivery. The refill action is only available on a completed order. A drip order that runs for a week cannot be refilled during that week, even if the first runs drop. The remedy for units that never arrived is a delivery dispute; the remedy for units that arrived and then dropped is a refill after completion. A long drip schedule keeps the second remedy out of reach for longer.

A small test order. A minimum order spread over several days tells you little about the supplier's normal delivery. You spend the same money and wait longer for the reading. Test a supplier on a one-shot row first, then decide whether the paced row deserves a second test.

A customer who checks the count every hour. Pacing produces more "still waiting" events and more questions. If you run a reseller panel, every drip order is a support conversation. The delivery may be fine and the customer experience still poor, because the visible progress is slow.

A decision table

Situation	One-shot	Drip	Why
Existing account, no deadline	Works	Fits	Smaller daily steps against the account's normal range
Launch with a fixed date	Use	Avoid	The count arrives after the moment
Second order on the same link	Use	Avoid	The second order waits, then hits its queue timeout
Supplier only sells paced delivery	Not offered	Only option	The flag is the supplier's method, not a setting
Refill dependent	Use	Caution	A refill requires a completed order
Minimum test order	Use	Avoid	A slow minimum order gives a slow reading

A qualitative comparison. The only number in it is the quantity you choose.

Worked example: the same 10,000 units on two clocks

Take a hypothetical 10,000 unit Instagram followers order at the median rate in the market table. The charge is $7.35. In this example the quantity is the same and the charge is taken at the same median rate. Only the clock changes.

On a one-shot row, the supplier accepts the order, the count moves in one block, and the order completes when the block is delivered. A refill request becomes possible at completion. If the count drops inside the window, the refill is measured against the start count plus the delivered quantity.

On a drip row, suppose the supplier uses five runs of 2,000 units over five days. That is a hypothetical schedule, not a published one. The count moves by 2,000 at each run. The order completes on day five. A refill request becomes possible on day five, not before. If you placed a second order on the same link on day one, it waits behind the first order. Its queue timeout is 180 minutes, which is three hours. The parent is still running on day five, so the second order refunds in full and has to be placed again.

The same arithmetic explains the campaign risk. If the launch is on day one, the drip order has delivered one run, which is 2,000 of 10,000 units in this hypothetical. The remaining 8,000 arrive after the moment the count was needed. The one-shot order would have delivered the full quantity before the launch. The price did not change; the timing did.

Record four timestamps for either row: the time you paid, the first movement, the completion, and the count seven days later. Those four numbers let you compare a drip row with a one-shot row on the same service without relying on memory.

How to measure a drip order

Write down the start count before the order and the count at the same hour each day. Compute the delivered units per interval: the change in count divided by the hours between readings. For a paced order, do the same calculation per run rather than across the whole order, because an average hides the pauses.

Compare the observed runs with the schedule support gave you. If support said five runs and you see three larger blocks, the supplier is batching. That is not a failure by itself, but it changes the shape of the delivery and the time to completion. Ask whether the remaining runs are still planned.

The order event log is the second source. The panel writes at most one waiting event per 30 minutes, so a long gap in the log does not mean the order is dead. It means the panel has nothing new to report. The supplier's status is the only source that can change the order state.

At completion, compare the count with the start count plus the ordered quantity. A completed report forces remains to zero, so a short count after completion is not a partial delivery in the supplier's report. It is either a drop after completion or a delivery that never arrived. Check the count over the next few days before you decide which one you have, and open a ticket with the three numbers if the count stays short.

What to do next

If the order is in progress and the count is moving in steps, check the drip-feed flag. If the flag is present and the schedule fits your deadline, wait and record the runs. If the flag is absent, ask support why the delivery is paced.

If the order is completed and the count is short, compare the count with the start count plus the quantity. If the gap is small and the count recovers, you are seeing a drop and the refill window is the remedy. If the gap stays, open a ticket with the order id, the start count, the current count and the completion time.

If a second order is queued behind a drip parent, cancel it while it is still queued. The full charge returns to the wallet. Waiting for the parent to finish is only sensible when the parent is close to completion, and a multi-day drip schedule rarely is.

If the campaign is time-bound, cancel before the order is accepted. Once the supplier accepts, the order is in its queue and the cancellation path depends on the service row and the supplier's reply. The earlier decision is the cheaper one.

For the state names and the money path, read the order lifecycle. For the clock that starts before delivery, read start times. To follow a live order, open the tracking page, and to ask about a schedule, use the support page.