Keep three timestamps for every order
Record payment, the first meaningful action toward the agreed deliverable, and completion. Use a stated time zone and keep the source of each timestamp. An automated confirmation email is not necessarily the first action that delivers the purchased work.
Define completion before the order begins. For a rank service it may be the agreed target; for coaching it may include a session and written feedback. Use the actual contracted deliverable, rather than treating the seller’s internal status label as the outcome.
| Measure | Calculation | What it describes |
|---|---|---|
| Queue time | First action − payment | Wait before fulfillment begins |
| Fulfillment time | Completion − first action | Time between start and finish |
| Total elapsed time | Completion − payment | Buyer’s full wait for the deliverable |
Save the deadline that applied to the purchase
A product page, a checkout screen, and a support conversation may describe different deadlines. Retain the statement that applied to the final configuration and ask the provider to resolve contradictions before paying. Record whether the promise concerns starting the order or completing it.
A deadline described in business days requires its own interpretation. Ask which time zone and working days the provider uses, when the clock starts, and which conditions pause it. Do not silently convert that promise into a different number of elapsed hours.
Show pauses and changes without hiding elapsed time
Keep interruptions, customer-requested pauses, provider delays, changes of worker, and configuration changes in the event log. Record the start, end, reason, and evidence for each incident. These events help explain why a deadline was met or missed.
If the contract excludes particular pauses, report the adjusted measure and the unadjusted elapsed time together. Explain the adjustment. A buyer should be able to reconstruct the calculation and see how long the order actually remained open.
An incomplete or canceled order is still part of the sample. Record its outcome instead of substituting a completed purchase. When completion never occurs, keep completion time blank and explain the documented failure; do not invent a timestamp to make the table complete.
Measure a useful support reply separately
Record when the customer asked a specific delivery or billing question and when a reply first addressed it. An automatic acknowledgment may establish that a message was received, but it does not answer the question. Preserve both when they are available.
A useful response is not the same as a resolution. Record what the provider proposed, what happened next, and whether the documented issue was resolved. Leave refund performance unmeasured if no refund was requested or exercised.
Compare equivalent work and report the sample
Keep the game, region, starting point, target, service type, options, and purchase window comparable across providers. Randomized timing within a registered plan reduces the opportunity to select only convenient orders, but a small pilot still does not represent all customers.
LootGrade’s empirical protocol requires at least three eligible ordinary paid orders across at least two dates before publishing that component. Report individual outcomes, the arithmetic mean, the range, and incidents. A mean alone can hide a delayed or failed order.
Our current research files contain no documented paid tests, so they show required fields rather than measured delivery times. Public reports can add context in the separate public-evidence component; another publisher’s timing is not a measurement of our purchase.
Sources & further reading
The external sources below establish their own policies or definitions. This article is a purchase-assessment guide, not a record of a LootGrade test.
No paid placements. There are currently no affiliate links on this page. Our funding policy