Research reviewed 7 September 2026 · Independent proposal · 16 quests
The opportunity is already-in-place help.
At a suitable Supercharger, an owner may have a little spare time, a familiar task they are willing to do, and a connected car that helps establish location. Dispatch could bring an eligible empty robotaxi to that confirmed helper. The owner's extra journey can approach zero.
The proposed gain is shorter service interruptions and a more engaged owner community. It is conditional: the robotaxi still incurs travel and waiting costs, and a busy charging site may be the wrong place. The useful asset is confirmed, capable help at the right moment, rather than every parked Tesla.
Published building blocks
Tesla documents vehicle and charging telemetry, charge controls, rewards, and Robotaxi support and privacy practices. These make the concept plausible. Telemetry · Commands · Rewards · Support
Proposed new product
Session opt-in, availability matching, safe task access, reservations, verification, fair reputation and reward accounting. Public documentation does not establish that this complete system exists.
The idea survives the charging cable. Tesla has demonstrated Cybercab wireless charging. Plugging quests apply to compatible vehicles and stations; observations, small resets and other approved assistance could remain useful as charging becomes automated. Tesla's demonstration
Start where the task is small and the result is clear.
These priorities balance operational impact, implementation ease, verification and expected participation. Pilot tasks come first; later stages require more preparation. Accessibility support can have very high value while still needing a separate, dependable service.
Willingness: no reward → small reward. Qualitative hypotheses, not measured acceptance rates. They assume the person has opted in, is already present, has time, and has any necessary training and supplies. Times cover the task, excluding travel and setup.
A small enthusiast segment may enjoy detailing; weak broad appeal.
Low → Low
How the priorities were assessed
Each dimension uses a judgmental 1–5 score. The weighted score is 40% operational impact, 25% implementation ease, 20% verification and 15% participation with a small reward. Tasks are grouped by rollout stage, then ordered by that score, with ties resolved editorially. The workbook exposes the inputs so a reviewer can change the assumptions.
Impact means plausible avoided interruption or better service; ease includes new software, access and physical preparation. The model does not use Tesla's internal costs, incident frequency, staffing needs or measured owner behaviour. A numeric score is an aid to comparison, not a forecast. Rewards and examples on the main page are illustrative.
Open a quest for the implementation detail
01 / Connect a charging cable
Pilot · 0.5–1.5 min. Expected willingness with no reward: high; with a small reward: high. These are hypotheses for eligible, available participants.
Why an owner might help. Familiar easy action; see the car recover; charging-community reciprocity.
How the task starts. Charging plan creates a scheduled task
Existing building blocks. Charger network, charge-port controls, cable/latch state and charging telemetry.
What Tesla would need to add. Helper enrolment; protected service state; task-specific access; connection timeout and unplug fallback.
How to check the result. Correct vehicle and connector; stable charging state and energy transfer; failed charger remains an infrastructure issue.
Who should receive it. Helper already at the station; trained for the connector; enough declared availability.
Scope limit. Route only eligible vehicles. A confirmed disconnection plan is required before relying on volunteer connection.
05 / Confirm a reopened route or usable pickup bay
Pilot · 0.5–2 min. Expected willingness with no reward: medium; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Local expertise; better maps for everyone including oneself.
How the task starts. Owner report or stale-information check
Existing building blocks. Navigation, location, app reporting and fleet observations.
What Tesla would need to add. Freshness timestamps; evidence review; distinguish observed access from legal permission.
How to check the result. Photo, posted signs, time and corroboration; route availability expires or is rechecked.
Who should receive it. Already nearby; no special journey and no need to enter traffic.
Scope limit. Do not remove cones or barriers. A visually clear space is not proof it is authorised for use.
Expand · 1–3 min. Expected willingness with no reward: medium; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Technical problem solving; restore the robot's useful vision.
How the task starts. Visibility diagnostic or reviewed report
Existing building blocks. Camera images, obstruction warnings and published cleaning instructions.
What Tesla would need to add. Approved supplies; short training; exact camera identification; independently tested image-quality checks.
How to check the result. Before/after image quality plus obstruction checks; escalate persistent faults or uncertain verification.
Who should receive it. Camera-care opted in; approved kit available; platform-specific training.
Scope limit. No inference that a clearer image alone makes the entire vehicle roadworthy.
Expand · 1–3 min. Expected willingness with no reward: medium; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Technical curiosity; assist diagnosis; useful contribution without cleaning.
How the task starts. Passenger report, anomaly or service review
Existing building blocks. Phone camera, vehicle ID, remote service/support workflow.
What Tesla would need to add. Guided angles; lighting checks; upload and remote triage.
How to check the result. Required areas visible and images usable; specialist interprets damage.
Who should receive it. Photo-inspection preferred; empty parked vehicle at an approved site.
Scope limit. The helper gathers evidence and does not certify driving safety.
Expand · 0.5–2 min. Expected willingness with no reward: medium; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Simple puzzle; instant visible success; help the next rider.
How the task starts. Door/seat state plus cabin inspection
Existing building blocks. Door states, seat signals and cabin images.
What Tesla would need to add. Narrowly permitted reset instructions and access; service-state confirmation.
How to check the result. Relevant sensor transition plus visual confirmation of the specified reset.
Who should receive it. Cabin-reset opted in; task within reach and without tools.
Scope limit. Mechanical faults, jammed mechanisms or uncertain objects are escalations.
Expand · 1–4 min. Expected willingness with no reward: medium; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Help someone recover something important; direct human benefit.
How the task starts. Rider lost-item request or cabin check
Existing building blocks. Lost-item reporting and post-ride cabin inspection.
What Tesla would need to add. Limited access; documented custody; approved locker or staff recipient; privacy controls.
How to check the result. Item location and recorded handoff; identity checked only by the authorised service.
Who should receive it. Trusted property-handling helpers at sites with secure custody.
Scope limit. Do not take property home or expose passenger identity or trip history.
12 / Move an authorised light obstruction in a parking area
Expand · 0.5–2 min. Expected willingness with no reward: medium; with a small reward: medium. These are hypotheses for eligible, available participants.
Why an owner might help. Restore access; useful physical action with an obvious outcome.
How the task starts. Fleet observation reviewed for suitability
Existing building blocks. External cameras and route obstruction observations.
What Tesla would need to add. Object/authority assessment; safe work area; renewed vehicle assessment after movement.
How to check the result. Object moved to permitted destination; path reassessed before vehicle departure.
Who should receive it. Only light objects, clear permission and a safe parking area.
Scope limit. No public-road debris, traffic controls, confrontation or heavy objects.
14 / Provide rider-requested orientation or short escort
Specialist · 2–5 min. Expected willingness with no reward: high; with a small reward: medium–high. These are hypotheses for eligible, available participants.
Why an owner might help. Strong direct helping motive; meaningful human contact.
How the task starts. Passenger explicitly requests assistance
Existing building blocks. Rider support, accessibility options and app communications.
What Tesla would need to add. Co-design with disabled riders; trained/vetted helpers; consent, accessible handoff and staffed guarantee.
How to check the result. Rider confirmation plus service oversight; never rely on camera judgement of consent or dignity.
Who should receive it. Qualified consenting helpers with the appropriate language and task ability.
Scope limit. This row excludes lifting, wheelchair transfers and securement. Accessible service cannot depend on volunteer acceptance.
Gamification: make the contribution feel worthwhile.
The strongest invitation is a clear, useful favour with a visible result: help this car recharge, add context when a robotaxi appears to be blocking traffic, or make the next rider's trip more pleasant. Choice, a short commitment and an honest explanation of the impact could matter as much as a small credit.
Meaning and identity
Some owners may enjoy helping, improving a product they use, or participating in new technology. Research on premium EV buyers supports a mix of environmental, performance and technology motives, but does not measure willingness to maintain a commercial fleet. Purchase-motivation study
Recognition and rewards
Symbolic awards helped retention in a Wikipedia experiment. Broader research suggests intrinsic motivation and incentives can coexist. Neither establishes the right reward or participation rate here. Awards experiment · Motivation meta-analysis
Offer optional Supercharging credit, points, contribution milestones or occasional merchandise. An impact receipt should say what was verified—“helped this car start charging”—instead of inventing minutes or money saved. Recognition-only participation should be a choice, with the reward stated before acceptance.
A proposed engagement loop: choose a suitable quest, complete it, verify the result, then show recognition and progress toward a personal milestone or a shared local goal. Badges and optional rankings make contributions visible; they do not certify competence. Task access still depends on relevant training and verified reliability. Count validated outcomes toward community goals, rather than raw reports or time spent.
Keep recognition optional and make quiet participation equally welcome. A helpful identity, curiosity about the technology and an immediate, visible result are hypotheses for sustained engagement—not proof that rewards will reduce operating costs. Test the contribution experience against a simple task invitation, including repeat participation after the novelty wears off.
Let people choose “observations only,” “charging,” “camera care,” or “light tidying,” set a time limit, and mute invitations. Public rankings should be optional. Avoid rewards for rushing, the number of accusations, or repeated reports of the same issue. Waze provides a precedent for contribution points; physical assistance needs its own evidence and design.
The key unknown is repeat participation. Early enthusiasts could be unusually willing. Charging time is also personal time. Pilot results need to distinguish curiosity on the first visit from durable engagement across different owners and stations.
Match the whole task, including its ending.
An invitation should specify the car, location, action, time, reward and what happens if the task cannot be completed. The first eligible acceptance reserves the task exclusively for a short window; nobody needs to race another helper.
Confirm availability. Charging telemetry establishes vehicle context; a fresh check-in establishes that a person is present and willing. Preferences, qualification, station access and spare time filter the match.
Compare the alternatives. Dispatch weighs vehicle detour, expected waiting, task success, supplies, support, charger congestion and paid-service alternatives. Only suitable empty vehicles enter physical service tasks.
Hold and guide. Use a protected service state and limited task-specific access. Keep instructions short and provide “cannot complete” and support paths.
Verify and release. Check the task result, account for the helper being clear, and apply the fleet's separate readiness rules. A completed quest alone does not release the vehicle to service.
Connecting and disconnecting a cable are separate commitments. The first helper may leave before charging finishes. A reserved available helper or dependable staff fallback must cover disconnection. Do not turn a successful connection into an occupied stall with no exit plan. Charging signals · Charge controls · Congestion considerations
Use different proof for different tasks.
Type
Example
Useful evidence
What it cannot establish
Telemetry
Connect a cable
Correct vehicle, charging state and sustained energy transfer
Why a failed charger failed, or who caused it
Visual + audit
Remove a specified object
Relevant before/after views, quality checks and sampled review
All cleanliness, hidden residue or complete roadworthiness
Human judgment
Describe an unclear entrance
Fresh context with corroboration; allow “cannot tell”
Permission to drive or a guaranteed safe path
Full product and operating decisions
These are proposed requirements. They identify the work behind a simple user experience.
Station eligibility
P0 — before physical tasks. Start at approved sites with safe space, supplies, bins and staff fallback. Confirm the owner's presence and available time for this session.
Design limit. Charging telemetry does not prove a human is beside the car, and charger occupancy does not reveal every adjacent bay.
P1. Always allow Report nearby Robotaxi. Offer a short voice report or, when parked, Something off / Looks okay / Cannot tell. Bookmark time and optional footage.
Design limit. The most socially awkward behaviour may not trigger any internal low-confidence flag.
P1. Create tasks from charge plans, cabin checks, persistent anomalies, rider requests and human support triage. Deduplicate reports into one incident.
Design limit. An incident can generate an observation first and a separate physical task only if needed.
P2 — after useful intake. Use a small face/question badge labelled Check requested. Distinguish a check request, available service task and professional support already engaged.
Design limit. The badge is an operational status, not the car expressing pain or a numerical measure of driving safety.
P2. Require a stable, actionable condition, a suitable place and useful human help. Suppress transient hesitation, repeated prompts and cases already assigned.
Design limit. Raw model confidence may be uncalibrated or task-specific; do not publish it as an emotional urgency signal.
P2. Match an authenticated fleet status to the correct visible vehicle. If association is ambiguous, show a nearby card with ID rather than attach a badge to a guessed car.
Design limit. GPS alone can confuse adjacent vehicles. Reliable association and stale-status handling are new engineering work.
P0/P1. Explicitly authorise short incident-linked upload, preserve relevant context and redact unrelated people where appropriate. Restrict passenger information and cabin access.
Design limit. Current Dashcam records locally by default. Public helper maps and unrestricted cabin feeds are unnecessary.
P1. Filter by authorisation, preferences, presence, time, equipment and task-specific competence; then compare expected completion and service value. Reserve exclusively.
Design limit. Estimate willingness from accepted/declined offers separately from earned reliability. Declining does not lower trust.
P0/P1. Use direct telemetry for objective state changes; multi-view images plus audits for visible changes; humans for ambiguous sensory, legal or safety outcomes.
Design limit. Automatic reward approval and authorisation to return to service are separate decisions.
P1. Track task-category quality, accepted-task reliability and evidence integrity. Show counts and recent outcomes; use a conservative prior for new helpers.
Design limit. A single universal star average confuses skills, popularity and operational failures.
P1. After repeated verified, attributable failures: give specific feedback, retraining and task-category restrictions. Provide review and restoration paths.
Design limit. A broken charger, inaccessible vehicle, mismatched instructions, correct abort or ambiguous evidence does not establish helper failure.
P1. Offer category opt-outs, time limits and optional recognition. Keep material work compensation transparent. Acknowledge actual impact after verified completion.
Design limit. Do not infer ideology from ownership year, assume payment always helps, or promise free charging as costless.
P0/P1. Deduplicate, validate outcomes, audit repeat pairs and separate reporting from authorising one's own paid repair. Handle deliberate fabrication distinctly.
Design limit. Rewards for raw report volume or unaudited before/after pictures can incentivise spam and manufactured problems.
P1. Compare recognition-only, modest-credit and fair fixed-payment offers within comparable low-risk tasks. Use a staff-only baseline and track repeated participation.
Design limit. Measure eligible offers, verified successes, cost, downtime, rework and charging delays; initial novelty is not long-run supply.
Two doors in: notice something, or answer a check.
Owner-initiated report. A parked control or brief voice bookmark captures time, approximate location and an optional description. “Something off,” “looks okay” and “cannot tell” can be enough. Offer an optional relevant video clip with explicit sharing controls. Existing Dashcam functionality is a building block; it is not evidence that another car's footage is already available to dispatch. Tesla Dashcam · Waze voice-reporting precedent
Fleet-initiated check. A diagnostic, rider report or support review creates a neutral, specific question for someone able to observe safely. A “Check requested” badge can be friendly and legible without presenting an undocumented FSD confidence score as a human emotion. Classifier confidence is not automatically a calibrated probability of correctness. Calibration research
A nearby-vehicle overlay is a later enhancement: Tesla would need reliable association between the fleet vehicle and the displayed object. Start with the requested location and a securely confirmed vehicle identity. Showing a badge on the wrong car would create confusion and poor reports.
Merge duplicates, expire stale conditions and protect the reporting channel against fabricated issues. Reward useful evidence after validation. Owner observations inform operational review and future learning; they do not directly command a manoeuvre.
Vehicle, rider and owner permissions are separate. Minimise location and clip retention; restrict access to passenger information; avoid publishing identifying footage as part of a leaderboard. Tesla's existing privacy notice describes its service practices, but a new owner-help programme would need its own clearly explained permissions. Robotaxi privacy notice
Build confidence in a helper, fairly.
Maintain task-specific completion evidence and recent reliability rather than one opaque popularity score. Someone excellent at reporting parking problems may never want to clean a camera. A preference is a matching input, not a failure.
Repeated attributable failures after accepting a clear task could reduce that category's matching priority, trigger a short refresher or pause access. Show the reason and provide a way to correct a mistaken assessment. Protect new helpers from permanent low ranking caused by a tiny sample.
Declining, being unavailable, reporting “cannot tell,” correctly aborting, or encountering an infrastructure fault should not lower standing. Separate truthful reporting from the fault being reported. Uber's rating exclusions offer a useful precedent, although verifiable maintenance outcomes call for a different scoring model.
Pair quality signals with duplicate detection, cooldowns, independent evidence and occasional audits. Avoid a reward structure that makes creating a problem and then “solving” it profitable.
Each useful action can improve the next decision.
The novel possibility is a joint dispatch problem: where should the robotaxi go next, and where is reliable help already available? The following feedback loops are proposals, not claims about Tesla's internal architecture.
Signal
Potential fleet improvement
Potential owner benefit
Availability + preferences
Route suitable service tasks to confirmed help; predict coverage gaps
Fewer irrelevant invitations and tasks that fit a charging stop
Validated local reports
Fresher pickup context, better issue triage and fewer repeat disruptions
Better local routing and a visible resolution to useful reports
Task result + time + fallback
Learn when a quest actually beats a depot or staff visit
More honest duration estimates and clearer instructions
Verified before/after examples
Candidate data for maintenance detection and future automation
Fewer unnecessary tasks as the system improves
Repeated unresolved issues
Identify site-design, vehicle-design or passenger-experience problems
A better service, even for owners who never contribute a car to the fleet
Tesla describes fleet-based AI development and evaluation. Useful quest evidence could become candidate training data after consent, validation and review. Selection bias matters: reports overrepresent visible problems, enthusiastic owners and well-covered locations. Count ordinary successful cases too, and evaluate changes before deployment. Tesla AI & Robotics
A few further possibilities
Service-aware charging. When charging is already necessary, choose a suitable site with confirmed helper availability if the total benefit is positive.
Small service kits. Approved sites could hold a standard kit or locker so a one-minute task does not become a search for supplies.
Learn what to automate next. Task frequency, cost and failure patterns can identify where a hardware redesign or automated cleaning process would remove the most work.
Community stewardship. Opt-in groups could contribute local access knowledge and track resolved issues without exposing individual movements or passenger data.
Test a useful service, not just a popular demo.
Begin at a small number of approved sites with predictable access and staffed fallback. Include two tracks: familiar charging assistance for eligible vehicles and low-friction context reporting. Add camera care and light tidying only after the access and verification process works.
Compare similar site-and-time blocks with and without quest availability. Within an appropriate voluntary design, compare clear reward offers—recognition only, a small fixed credit, or a larger credit. Agree success criteria and stopping conditions before the trial; do not infer fleet-wide economics from a launch-day enthusiast event.
Question
Measure
Does it improve operations?
Net vehicle downtime, paid-service interventions avoided, detour and waiting time, charger congestion, support cost
Incremental verified completions per reward cost; quality and retention, rather than gross quest count
A practical economic test: avoided service cost and recovered vehicle availability must exceed rewards, vehicle detour and waiting, supplies, verification, support and expected rework. No credible savings percentage is available without measured task frequency and costs.
Scale only the task-and-site combinations that show durable participation and a positive operating result. If help is sparse, supplies are missing or results are ambiguous, use the staffed service path. That fallback is part of the design.
Sources, with their limits.
This is a concept feasibility assessment based on published capabilities and related research. It does not have access to Tesla's internal dispatch system, incident logs, costs or owner-participation experiments. “Existing building blocks” describes components, not a complete implemented quest service. Current service coverage is not an assumption required by this proposal.
The original downloadable workbook contains the 16-task matrix, implementation notes, product decisions, scoring method and sources. This page adds the visual concept's explanation and the wireless-charging consideration.