Task evidence and completion standards
Completed missions, refunds and turnaround
One request counts as one mission, including every call, retry and follow-up. See recent documented outcomes, recorded turnaround and verified web refunds, with the full scope and method below.
Restaurant bookings, changes and cancellations
Restaurant requests, with every outcome included
September 9, 00:00 to October 4, 09:58, 2026 (Japan time). The full period was reviewed by the actual request, including unfinished and refunded requests.
72 stored requests67 closed · 5 ongoing, kept separate from closed results.
- Documented goal matches
- 31
- Marked for refund
- 28
- Median recorded turnaround
- 18h 22m
Other closed records: 3 tasks cancelled and 5 partial or unconfirmed outcomes. Refund labels and verified refunds are reported separately.
Each stored submission counts once; repeat submissions remain separate. Retries and follow-ups within a submission are not counted again. These are first-party historical records.
All outcomes by request type
| Request | Goal met | Refund label | Cancelled | Partial / unknown | Ongoing | Total |
|---|---|---|---|---|---|---|
| New booking | 19 | 25 | 3 | 5 | 5 | 57 |
| Change | 4 | 2 | 0 | 0 | 0 | 6 |
| Cancellation | 8 | 1 | 0 | 0 | 0 | 9 |
| Total | 31 | 28 | 3 | 5 | 5 | 72 |
What the timing and refund evidence confirms
Of 31 goal matches, 25 have usable timing: 16 within 24 hours and 9 longer; 6 lack timing. Measured from submission to recorded result, including waits for opening hours, customer replies and follow-up.
Ten web payments were individually matched, totaling US$45. Four full refunds were verified in Stripe, totaling US$16. Of 24 app refund labels, one has a task-linked ledger entry (500 credits), 20 have historical reconstructions only, and three lack a matching ledger entry.
Only four records pair payment time with result time: two within 24 hours and two longer.
Scope and anonymous data download
The frozen October 4 evidence contains 118 records in this window. We excluded two zero-price records without linked web payment, 37 other-category requests and seven restaurant-tagged requests outside booking, change or cancellation. Accepted late arrival counts as a change; confirmation-only, menu and opening-hour enquiries do not.
Goal matches require explicit written results, not just a completed label. This cohort overlaps the reports below; do not add their totals. The public file contains aggregates only, without customer names, venues, contact details or booking information.
Download anonymous totals and methodology (JSON) →Checked October 4, 2026 · Recent task results
43 tasks with documented goal-matched results
We reviewed all 116 eligible tasks created from September 9: 105 closed and 11 ongoing. For 43, written results support the original request or a change accepted by the customer, such as a confirmed booking, completed cancellation or answered enquiry.
- Documented goal matches
- 43
- Median recorded turnaround
- 19h 12m
- Tasks in the current inventory
- 289
Full review cohort: 116 tasks
37 tasks with matched result timestamps
Since April 26: 274 closed, 15 ongoing
Scope: September 9–October 4, 2026, 09:58 Japan time. This is our review of first-party written records. Timing runs from task creation to the recorded result and includes waiting for opening hours, customer replies and agreed follow-ups.
See all 116 outcomes, current totals and the method
The period contains 118 records. We exclude 2 zero-price records without a linked web payment, leaving 116 unique tasks. We read every included task and compared all 57 marked completed against their requested goals and written results. Completion or call connection alone does not count. Unanswered required terms and conflicting records remain unconfirmed.
Outcomes of the 105 closed tasks
- Written records support the requested outcome
- 43
- Marked refunded
- 41
- Cancelled
- 7
- Goal unmet
- 1
- Partial or unconfirmed
- 13
Another 11 tasks are ongoing. They remain in the full 116-task review cohort and are excluded from the closed outcomes above.
Of the 43 documented goal matches, 37 have a matched timestamp and 6 do not. Of those 37, 24 took at most 24 hours and 13 took longer. Nineteen timestamps come from updates, customer replies or booking confirmations; 18 come from the timestamp within the final result note. We subtract no waiting time and retain slower follow-ups.
Only 4 tasks have both an exact web-payment time and a matched goal-result time: 2 within 24 hours and 2 later. Refund labels and financial refund records are checked separately below.
Current inventory across all dates
The full export covers all 324 stored records, from the first request on April 26 through October 4 at 09:58 Japan time. Excluding 27 test/staff-marked records and 8 zero-price records without linked web payment leaves 289: 274 closed and 15 ongoing. The 116 recent tasks above are a subset of these records.
- Marked completed
- 158
- Marked refunded
- 90
- Cancelled
- 26
- Ongoing
- 15
These totals describe workflow states. The recent subset, full task inventory, web refund cohort and September 8 history overlap and must not be added together.
Checked October 3, 2026 (UTC) · Payment records
9 web prepayments verified as fully refunded
We matched NativeCall orders to Stripe payment, refund and balance records. All 9 refund-marked orders in this web-order dataset match succeeded refunds for the full payment amount: US$52 in total.
- Full refunds verified
- 9 / 9
- Total refunded
- US$52
- Paid orders in scope
- 36
Scope: general web task orders created July 1–October 3, 2026 (Japan time). This is our reconciliation of payment-provider records. App-credit refunds and the separate lost-property checkout system are outside this scope.
See the full denominator, deduplication and refund matching
There are 50 orders: 36 with stored payments and 14 unpaid. The paid orders have 23 completed, 9 refunded, 1 in-progress and 3 paid workflow labels.
The 36 orders link to 34 distinct succeeded Stripe payments, totalling US$190. For 33 orders, the order reference and amount match individually. Three orders share one US$12 payment, with US$4 allocated to each in NativeCall. Those allocations sum correctly but lack independent order-level Stripe metadata. We therefore count 34 payments.
Each of the 9 refunds matches its original payment and charge. Stripe reports succeeded for the refund and available for its matching balance transaction. This verifies the processor’s refund result.
App credits were checked separately on October 4. All 85 credit-refund-marked missions were reviewed. One has a matching task-linked refund entry in the current ledger for 500 credits. Eighty have only reconstructed historical entries and four have no task-linked refund entry. Credits are not added to the US$52 in web refunds.
The September 8 task history below keeps its original date and stays separate from this payment cohort to avoid double counting.
View the September 8, 2026 task history
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. Of 203 source records, 17 tests and 5 courtesy tasks are excluded, leaving 181 requests.
Completed missions: time from request to reported result
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.
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. 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.
Web order workflow 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
Source: authenticated NativeCall operational aggregate. Retrieved: 2026-09-08 02:11:18 UTC.
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. Calls, retries, follow-ups, 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. 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.