Task evidence and completion standards
Completed missions, refunds and turnaround
One request counts as one mission, including AI, human calls, retries and follow-up. Here are the results for closed missions; ongoing work is excluded from the closed-mission figures.
Real requests. Recorded results.
April 26–September 8, 2026 · Available historical task records
Mission requests received
181missions
155 closed + 26 ongoing / queued = 181 requests
The five closed-outcome categories below are mutually exclusive and total 155. The 26 ongoing or queued missions are counted separately.
155 closed missions: the complete breakdown
- Missions reported completed
- 52
- Refunded missions
- 44
The service report records an outcome matching the requested goal.
No service fee if your requested outcome is not achieved. Web prepayments are refunded in full; app task credits are returned.
- Cancelled
- 19
- Goal not achieved
- 4
- Result awaiting confirmation
- 36
52 + 44 + 19 + 4 + 36 = 155 closed missions
Refund counts reflect system refund labels; individual transactions have not been reconciled. Of 203 source records, 17 tests and 5 courtesy tasks are excluded, leaving 181 requests.
How long did completed missions take?
Median: 12 hours 11 minutes
Of 35 completed missions with usable timestamps, 22 finished within 24 hours. The shortest took 11 minutes; the longest took 4 days, 19 hours and 59 minutes.
Measured from the recorded request to the matching outcome report, including any business-hours or customer-response waits. The other 17 completed missions lack usable timing. Available records do not reliably measure payment to completion, so this is neither an all-mission average nor compliance with the 24-hour payment-to-completion promise.
Refunds when the goal is not achieved
These are the recorded reasons for 44 refunded missions. You do not pay a service fee for an unmet goal, including when availability, business rules or another outcome outside our control prevents it.
- Business, delivery or lost-item outcome prevented the requested result
- 27
- Customer cancellation or refund request
- 6
- Reason not recorded
- 11
For example: no availability, the business’s rules, no response from the recipient, item not found, or a delivery already completed.
These records were closed after the customer’s decision.
There is not enough information to determine the reason or assign responsibility.
Of the 33 refunds with a recorded reason, 27 cite a business, delivery or lost-item outcome and 6 cite a customer cancellation or refund request. The remaining 11 do not state a reason; we do not infer responsibility from those records.
| Reason | Missions |
|---|---|
| No availability for the requested date, time or space | 10 |
| Booking or change not allowed through the requested route | 9 |
| Could not reach the business | 5 |
| Lost item not found | 2 |
| Delivery already completed; change no longer possible | 1 |
| Cancellation or refund requested | 6 |
| Reason not recorded | 11 |
These figures cover available historical task records, not a complete all-channel payment ledger or independently audited success rate. Scope and missing records are explained below. Customer details remain private.
Download figures and scopeSources and detailed methodology
The main table starts with 203 available historical task records, excluding 26 open/queued records, 17 tests and 5 courtesy tasks: 155 remain. Another 12 paid, closed web records await review: 8 marked completed and 4 marked refunded. They are not merged without outcome evidence and test exclusions. Nine identified cross-system duplicates are not counted twice.
Available operational status counts
30-day snapshot, grouped by record creation time:
2026-08-09 02:11:18 UTC – 2026-09-08 02:11:18 UTC.
- Orders with checkout created
- 12
- Paid orders
- 8
- Orders marked “completed”
- 7
These are workflow states, not a verified task-success rate.
A “completed” status alone does not prove a booking, enquiry, lost-property request or other customer goal succeeded. Task deduplication, test exclusions, refunds, and pending or unknown outcomes have not been audited in this aggregate, so we do not turn 7 and 8 into a success percentage.
Source: authenticated NativeCall operational aggregate. Retrieved: 2026-09-08 02:11:18 UTC.
Verified task outcomes
This historical dataset preserves each closed outcome and its available timing instead of combining records with different evidence strength into one success rate. We will publish an overall success rate, all-mission resolution time and task-type rankings when a complete cohort and goal-outcome evidence are available.
How we count one task
- Fix the creation-date window and snapshot time. Include the complete cohort of tasks created in that window and evaluate their latest outcomes at the same cutoff.
- Deduplicate by task. AI work, human work, retries, payment records and call records cannot become separate successes. Exclude a task if any revision identifies it as a test.
- Check goal evidence. Success requires a reviewed booking confirmation, recipient confirmation, customer confirmation or verifiable task artifact tied to the requested goal. Payment, connection, call completion and workflow labels alone do not establish success.
- Retain unsuccessful outcomes. Failed and refunded tasks count as failed; unfinished work is pending; insufficient evidence is unknown. Conflicting records at the same timestamp are unknown.
- Publish the denominator. Verified achievement share equals verified goal-achieved tasks divided by all eligible tasks. Pending and unknown tasks remain in that denominator and are shown separately.
Our product reporting minimum is 20 eligible tasks in a complete cohort before publishing a rate. This is a reporting threshold, not proof of statistical significance or representativeness. Median successful resolution time separately requires at least 20 verified successful tasks. Public data contains aggregates, without names, phone numbers, transcripts, recordings or evidence links.