Asking a panel the five questions that reveal how it operates

Many panel reviews are written after a delivery, which is too late to help the next buyer. The useful conversation happens before the deposit, when a support team can still show whether it knows how an order is routed, settled and replaced. Five questions are enough to see that, if they are asked together and read as a set.

The questions are operational, not commercial. They do not ask for a discount, a promise or a review. They ask how the panel handles the five places an order can fail: routing, settlement, queue, refill and continuity. A panel with a process answers with specifics. A panel with a script answers with adjectives.

Why these five

An order can fail at five points. It can be routed to a supplier that does not carry the service. It can be delivered short and settled badly. It can sit in a queue longer than the buyer can wait. It can drop after delivery and face a refill that nobody executes. Or it can fail because a supplier goes down and the panel has no fallback. Each failure has a question that exposes the process behind it.

The questions are also comparable. Ask the same five of three panels and the answers line up. That is the point of asking them together: a single answer can be polished, but five answers that contradict each other are hard to fake. Keep the replies in writing, with the date and the service row, so the comparison survives the sales conversation.

The message

Send one numbered message, with the service row and the quantity you are considering. A template you can copy:

I am considering service [row name or id] at [quantity] units. Five questions before I deposit:
1. Which supplier and service id carries this row, and when did its price last change?
2. If the order stops short of the ordered quantity, who calculates the remains, where does the refund go, and how long does it take?
3. What is the current queue for this row, and what is the timeout before an automatic refund?
4. Which refill window applies to this row, who executes the refill, and what count is it measured against?
5. What did your status page last record, and what happens when the supplier behind this row goes down?

The message is specific on purpose. It names a row, a quantity and a failure point. A support team that can answer it is reading the catalogue and the queue. A team that replies with "we are a direct provider, instant delivery" has answered none of the five, and the reply is the evidence.

Question one: routing

Which supplier and service id carries this row, and when did its price last change?

This is the mapping question. It tells you whether the panel can see the chain behind the row it sells. A strong answer names a service id, a supplier alias and a date for the last price change. The alias is enough; many wholesalers require resellers to keep the company name private, and a refusal to name the company is not proof of a problem. What matters is that the panel can identify the row and the date.

A weak answer says "we are a direct provider" and stops. Almost every panel in this market resells a wholesaler's catalogue, and a panel that claims to own the accounts usually cannot explain why the same row disappears from its catalogue when a supplier changes a price. The mapping question is not an accusation. It is a request for the row's identity.

Use the answer to check the row. If the panel says the price last changed on a date, the price history on the market tables can show whether the market moved on the same day. If the panel says the row has no supplier id because it is "in-house", ask how a refill is executed. An in-house row still needs a pool, a queue and a replacement process.

Question two: settlement

If the order stops short of the ordered quantity, who calculates the remains, where does the refund go, and how long does it take?

This is the partial-delivery question. It is the one that decides whether a short delivery is a small loss or a large one. A strong answer has three parts: the supplier reports the remains, the panel calculates the undelivered share, and the refund goes to the wallet automatically. The time should be named, even if it is a range.

A weak answer sends you to a ticket queue and leaves the decision to whoever is on shift. A bad answer treats the supplier's completed flag as proof that the units arrived. The difference is not cosmetic: one process runs without a person, the other depends on who is online.

Ask where the money goes, too. A wallet credit is a database entry and can be immediate. A refund to the original payment method depends on the processor and can take days. Both can be fair, but the policy should name which path applies and when. If the answer is "we will sort it out", the settlement is a conversation, not a clause.

Question three: queue

What is the current queue for this row, and what is the timeout before an automatic refund?

This is the waiting question. A queue is normal. A queue with no timeout is a place where an order can sit indefinitely while the buyer waits for a deadline. A strong answer gives a current depth or a range and a timeout clause. The number does not have to be precise; it has to be owned by someone who can see the queue.

A weak answer says "usually fast". A bad answer says "instant" for a row whose start estimate is measured in hours. The start estimate on the row is the panel's own statement. If support contradicts it, one of the two is wrong, and the row is the document the order is placed against.

Ask what happens at the timeout. The order should be refunded in full, not left open. If the panel has no timeout, the queue is the policy, and the policy is whatever the supplier decides. That is a risk you can accept for a small test and should not accept for a campaign with a deadline.

Question four: refill

Which refill window applies to this row, who executes the refill, and what count is it measured against?

This is the replacement question. A refill is a second order against the same service, and it needs a window, an executor and a baseline. A strong answer names the window on the row, the supplier that executes the refill, and the start count as the baseline. A weak answer points to a badge on the category page. The badge is not the row.

Ask what happens when the pool is exhausted. A refill on a thin pool can be slower than the window suggests, or unavailable. The answer should name the fallback: a credit, a different pool, or a refund. A panel that promises a refill without naming the executor is promising a process it does not control.

The baseline matters as much as the window. A refill measured against the start count replaces the accounts that left. A refill measured against the current count replaces less, and the difference compounds over a second drop. Ask which count the supplier uses, and write the answer next to the order id.

Question five: continuity

What did your status page last record, and what happens when the supplier behind this row goes down?

This is the continuity question. It asks the panel to describe its own health and its fallback. A strong answer gives a timestamp, a catalogue size or a queue depth, and a fallback plan: a second supplier, a refund, or a pause with a notice. A weak answer gives an uptime percentage with no log. A bad answer has no status page at all.

The fallback is the part that matters. A supplier can go down for a day, a week or permanently. A panel with a second supplier can route the order elsewhere, sometimes at a different rate. A panel without one can only wait. Ask which case applies to the row you are buying, and what the buyer is told when it happens.

The answers side by side

Question	A strong signal	A weak signal
Routing	A service id, a supplier alias, a last price change date	"Direct provider", no id, no date
Settlement	Supplier remains, automatic wallet credit, a named time	A ticket, a review, "completed"
Queue	A current depth or range, a timeout clause	"Usually fast", "instant"
Refill	The row window, the executor, the start count	A category badge, no baseline
Continuity	A timestamp, a fallback, a notice process	An uptime claim with no log

A scoring sheet. It contains no market figures and no supplier names.

Scoring the answers

Give one point for a specific answer, zero for a slogan, and subtract a point for an answer that contradicts the policy page. Five points is a panel that can explain its process. Three or four is a panel worth a minimum order. Two or fewer is a panel to use only for a test you can afford to lose.

The score is not a quality rating. It is a measure of how much of the process the panel can see and describe. A panel can score five and still deliver badly, because the process can be described and then ignored. But a panel that cannot describe the process has nothing to follow when the order goes wrong, and that is the risk the questions are designed to expose.

Compare the answers with the policy page. A panel that says "automatic refund" in chat but has no refund clause on its site is a panel whose process lives in a support shift. A panel that names the clause and the page is a panel whose process can be checked after the fact. The page is the document that survives the conversation.

Coverage in the catalogue	Value
Active services	4,571
Services with refill	1
Services with cancellation	2,218
Services with refill, share	0%
Priced market offers	136211
Market offers with refill	36%
Market offers with cancel	18%

Read from the Talon database when the page is rendered. Coverage is a written remedy, not a promise that every row will honour it in every case. Market edition: 7 November 2026.

The coverage numbers tell you how much of the catalogue has a written remedy. Refill is flagged on 1 of 4,571 active rows, cancellation on 2,218. The market offers show a similar split: 36% carry a refill flag and 18% carry a cancellation flag. A row outside those shares is a row where the answer to question two is the whole remedy.

A five-minute check before you send the message

1. Pick one row. Not a category, not a platform. The row name and the quantity you are considering.
2. Copy the five questions. One numbered message, no extra requests, no discount question.
3. Ask for a written reply. A chat reply is fine if you can keep it. A reply that disappears with the session is not a record.
4. Score each answer. One point for a specific answer, zero for a slogan, minus one for a contradiction.
5. Check the policy page. The refund, cancellation and refill clauses should match the answers.
6. Place a minimum order. The score is a reason to test, not a reason to deposit a large balance.
7. Keep the reply with the order id. The pair is the record if the order goes wrong.

The five questions are not a trick. They are the five places where an order can fail, asked in the order they matter. A panel that answers them is a panel you can hold to a process. A panel that does not is a panel you can still use, as long as you know which part of the process you are trusting to luck.

For the pre-deposit checks that sit around these questions, read how to choose a panel without getting burned. For the clauses behind question two, read refunds, cancellations and queues. To see what a public status page can show, open the status page, and for a failed order, start with the refund policy.