Start times: why a supplier number is not a promise

The start time on a service row is the number buyers quote back to support when an order is late. It is also the number often read as a deadline. It is neither a deadline nor a measurement of your order. It is the supplier's estimate for one segment of the delivery, and three other clocks are running around it.

This guide separates those clocks, shows which one owns the number, and gives a timeline you can check against the order page. The aim is simple: when an order is late, you should know whether to wait, ask a question or cancel, without guessing.

Three clocks, one number

The first clock is the panel's placement step. After you pay, the panel creates the order and sends it to the supplier. On a real supplier this is a network call, and it can fail, time out or need a retry that is safe. The placement timeout is 60 minutes. If the supplier has not confirmed by then, the order is canceled and the wallet is not charged.

The second clock is the supplier queue. Once the supplier accepts the order, it waits for a slot, for balance, or for the service to be available. This is where a queued order sits. The queue timeout is 180 minutes, and when it passes the charge returns to the wallet in full.

The third clock is the supplier's start estimate, the number on the service row. It describes the gap between the supplier accepting the order and the first delivered unit. It does not describe the placement step, the queue, the platform's rate limit or the time to completion. A row that says five minutes is saying that the supplier usually starts within five minutes of acceptance, not that your count moves five minutes after payment.

The policy layer adds a benchmark. This panel treats a start above 30 minutes as a fallback, chosen only when no faster row fits the request. That is a selection rule, not a promise that a row below the limit will start on time. It tells you which row the panel prefers when two rows can do the same job.

The symptom that brings people here

What you see: the order is pending twenty minutes after payment, or queued for three hours, or in progress with a count that has not moved.

What it means: each of those is a different clock. Pending is the panel's placement step. Queued is the supplier queue or a supplier balance shortfall. In progress with no movement is an accepted order that has not started delivering.

Next action: read the state, then the event log. The state tells you which clock owns the order. The event log tells you when it last changed and why.

A single status word is not enough to choose an action. Pending for two minutes and pending for sixty minutes are the same word and different situations. The timestamp next to the state is what turns the word into a decision.

What the number is built from

The service row stores a start estimate in minutes. It comes from the supplier's catalogue or from the panel's own observation, depending on how the row was imported. It is a central estimate, not a worst case. A supplier that starts many orders in five minutes can have an hour-long tail when its queue fills.

The estimate also depends on the link. A public profile with an open count is easier to start than a private profile, a deleted post or a channel with restricted joining. The supplier may accept the order and then discover that it cannot deliver, which produces a partial or a cancel after the start clock has already begun.

Platform limits are the third input. A platform can slow a supplier's delivery without telling the panel. The supplier keeps the order open and reports remains. The start estimate did not change, because the estimate was about the supplier's queue, not about the platform's willingness to accept units at that moment.

In the current catalogue, 4,571 of 4,571 active services carry a start time at or below the panel's 30 minute benchmark. That is a count of rows, not a delivery record.

The clock you are actually on

State	Clock	Owner	Deadline	What to do
Pending	Placement	The panel	60 minutes	Wait for confirmation, then read the next state
Placing	Supplier confirmation	The panel and the supplier API	60 minutes	Wait; a timeout cancels without a charge
Queued for funds	Supplier balance	The panel	180 minutes	Wait for the top-up or the automatic refund
Queued behind an order	Earlier order on the same link	The panel and the supplier	180 minutes	Cancel while queued if the deadline matters
In progress	Supplier delivery	The supplier	No fixed deadline	Ask for the reported remains
Partial	Refund	The panel	Automatic	Check the wallet entry against the order id

The timeouts are the defaults in the order engine. A deployment can change them, so the order page is the source of truth for a specific order.

The table makes one thing clear: only the in-progress row is the supplier's start estimate. Every earlier row is a different clock. A buyer who compares a five-minute start estimate with a pending state at minute twenty is comparing two different measurements.

A worked example timeline

Suppose a hypothetical order is paid at 10:00. The panel creates it and sends it to the supplier. If the supplier confirms at 10:04, the placement clock stops after four minutes. The supplier's start estimate, say five minutes, then begins. The first unit is expected around 10:09, but the estimate is not a deadline.

If the supplier has not confirmed by 11:00, the placement clock reaches its 60 minute limit. The order is canceled and the wallet is not charged. The correct action is to read the event log, not to open a dispute, because there is no charge to dispute.

If the supplier accepts the order but the panel's supplier balance is short, the order moves to the funds queue. The funds clock runs for 180 minutes. At 13:00 the order is refunded in full if the balance was not topped up. The start estimate never applies, because the order never reached the supplier's delivery queue.

If the order is accepted and starts, but the platform slows the delivery, the order stays in progress with a remains number. There is no deadline in the table for this state because the supplier has not promised one. The useful question is not "when will it finish" but "what remains does the supplier report now, and when did it last change".

Why a supplier's number is not a promise

A start estimate is a central value from a distribution. Many orders can start near it and some cannot. The tail is produced by queue load, by a service pause, by a platform limit, by a link that needs a manual check, or by the time of day in the supplier's operating hours. None of those inputs is visible on the service row.

The number is also not audited. A supplier can publish five minutes because that is what its dashboard shows, or because it is the number that sells. The panel can compare the number with its own delivery records, but a single order cannot prove or disprove the estimate. That is why the policy uses a benchmark rather than a promise: a row above the benchmark is a fallback, and a row below it is preferred, but neither is a promise.

The honest reading is comparative. A five-minute row and a thirty-minute row are telling you something about the supplier's expected queue, not about your specific link. If the deadline is tight, choose the shorter row and keep the order small enough that a miss is cheap. If the deadline is loose, the longer row can be fine.

How to read a start time without guessing

Record four timestamps for every order you care about: the time you paid, the time the supplier accepted, the time the count first moved, and the time the order reached a final state. The difference between the first two is the panel's placement latency. The difference between the second and third is the supplier's start latency. The difference between the third and fourth is the delivery time.

Compare the supplier's start latency across at least three orders on the same service and quantity. Use the median, not the mean, because one queued order can move a mean far more than a median. If the median is close to the published number, the number is useful for planning. If the median is far above it, the number is decoration.

Keep the state attached to each timestamp. A pending order at minute fifty is a placement problem, not a slow supplier. An in-progress order at minute fifty is a supplier problem. Mixing the two produces a false average and a wrong decision about which supplier to use next.

Three common misreadings

"Five minutes means five minutes after payment." The number starts after the supplier accepts the order. The placement step comes first, and it has its own 60 minute limit. A payment at 10:00 with a confirmation at 10:20 and a five-minute start estimate puts the first unit around 10:25, not 10:05. The order page shows both timestamps, which is why the state and the time belong together.

"The number is a maximum." It is a central estimate, so half of the orders can land on the slower side of it. A supplier with a five-minute estimate can have a tail of an hour when its queue fills or when a platform slows the pool. The estimate is useful for comparing rows and for setting expectations, not for calculating a refund deadline.

"A late start means the supplier lied." A late start can come from the platform, from the link, from a service pause or from the supplier's operating hours. The published number does not encode the supplier's day. If the order is in progress and the remains is falling, the delivery is happening even when the start was late. If the remains is static, the cause is a fact to ask for, not a conclusion to announce.

The three misreadings share a fix: attach the published number to the state it describes. A start estimate without a state is a number without a clock, and a number without a clock cannot tell you whether to wait.

When to cancel, and when to ask

Cancel while the order is pending, placing or queued. In those states the order has not reached the supplier's delivery queue, and the full charge can return to the wallet. The exact path depends on the state: a placing order that times out cancels itself without a charge, and a queued order can be canceled while it waits.

Do not cancel an in-progress order just because the start estimate passed. Once the supplier accepts, the order is in its queue and a cancel can be refused. If the service row allows cancellation and the supplier agrees, the cancel goes through. If the supplier refuses, the order stays open and no refund is issued. You then have neither the delivery nor the money back, which is worse than waiting for a partial result.

Ask for the remains instead. A supplier that reports remains is telling you how much is still outstanding. That number, not the start estimate, is the basis for the next decision. If the remains is falling, the order is moving. If it is static for a long stretch, the supplier's answer about the cause is the next fact you need.

For the state names and the money path, read the order lifecycle. For the queue that holds an order before delivery, read order queues. To follow a live order, open the tracking page, and to ask about a specific start delay, use the support page.