Submitted is a handoff, not approval.

A patient uploads an insurance card and expects to have finished preparation. An office may still need to receive it, check readability, match the patient and ask for clarification. This is an authored service scenario. I have not observed that workflow inside a Zocdoc practice.

The appointment-detail flow reviewed in Mobbin includes preparation tasks and an appointment pending confirmation. That distinction changed my opening: “Booked isn’t prepared” treated booking as settled when the reference did not. I now keep appointment confirmation separate from preparation progress.

The patient’s question is not simply “How many tasks are left?” It is “What do I still need to do, and what is the office doing?” A checklist can answer the first while concealing the second.

I considered a single Ready badge, separate task completion ticks, and a handoff model with visible ownership. Ready was too broad: it could be read as confirmed attendance, accepted insurance or completed office review. Individual ticks were clearer but still ambiguous about submission versus acceptance.

I chose narrow states: To do, Submitted, Needs your attention and Reviewed by office, with the last state available only when a real office acknowledgement supports it. The proposal does not infer coverage, clinical readiness or appointment confirmation from an uploaded document.

The blueprint below supports the screen sequence. It connects the patient-visible state to an acknowledgement, the office’s next action and an exception route. Its backstage lane is a proposed contract for discovery with a practice, not a diagram of Zocdoc’s current architecture.

The revised screen labels the appointment Pending confirmation, groups tasks requested by this office and selects the next incomplete task. Upload ID is the immediate action; Choose another task preserves control; Contact office remains available. Submitting a task does not confirm the appointment.

The example uses sample clinician, appointment and task data. Task requirements vary by practice and visit. I removed the blanket preparation-time claim: a person should not receive a precise completion estimate without evidence appropriate to the actual forms and their circumstances.

The cost of this hierarchy is that secondary details move lower. I would check that appointment location, timing, cancellation and accessibility information remain easy to find, especially when preparation is not the patient’s main reason for opening the page.

A useful receipt identifies the submitted item, timestamp and next responsible party. It can say “Submitted to the office” only after the agreed acknowledgement exists. It must not silently promote that state to Reviewed, Accepted or Confirmed.

If review reveals an unreadable image, the patient should receive a specific correction request tied to that item. Replacing the image should preserve the history needed by the office and make the new submission state visible. The service must avoid sending a generic “Finish your paperwork” reminder after the patient has already done their part.

A failed upload is different from a successful upload awaiting review. The proposed exception examples below keep those states separate and preserve a route to assistance. They are interface copy and workflow proposals, not live office messages.

If the task list cannot be loaded, I would show an unavailable state with retry and contact options, never “0 tasks left.” A newly requested form should say “Your office added a form,” identify the new request and preserve previous submissions. Removed requests should leave an understandable history; a revised form or rescheduled appointment needs an explicit rule for whether an earlier submission still applies.

The current preparation list and an experiment’s original assignment snapshot are different records. A pilot must preserve the latter for analysis without freezing the patient’s actual requirements. The interface should not make an office-side change look like a patient losing progress.

The first operational question is whether staff receive usable information in their existing workflow. I would map who checks submissions, how a clarification is sent, which system is authoritative and what happens if an appointment changes. Without those answers, the Reviewed label cannot be responsibly implemented.

The later screen below assumes the patient replaced the unclear photo, the new version was received, and the office acknowledged its review. I close only that item. Insurance remains Submitted, the forms remain To do and the appointment stays Pending confirmation. This preserves the boundary that a global Ready badge would erase.

An initial rehearsal could use a small set of fictional requests with a participating practice: readable card, wrong patient, unclear image, duplicate submission and changed appointment. Staff would explain the needed next action. That is a proposed desk rehearsal, not completed field research or proof of operational impact.

I would avoid building a new staff dashboard just to make the portfolio story look complete. An existing workflow integration may be the smaller useful intervention. If no reliable acknowledgement is available, the patient-facing promise must remain narrower.

The operational model is: avoided reminder and clarification work, minus new review, correction and maintenance work. Each term needs an observed baseline. An uploaded document is not automatically a minute saved, and nominal staff capacity is not automatically cash savings.

A pilot would segment contacts by missing document, unclear status, unreadable upload, eligibility question and unrelated scheduling need. Patient understanding, successful correction, missed requests and office handling time belong beside preparation completion. Appointment attendance would need its own analysis and cannot be attributed to this concept from a mockup.

I removed simulated interview totals, prototype percentages and uplift figures from the evidence narrative. The work currently demonstrates a service boundary, a patient hierarchy and the conditions for a credible handoff. The next proof must come from patients and an office working through it together.

I would release a narrow pilot only when the acknowledgement source, exception owner, review expectations and patient contact route are agreed. I would withhold Reviewed if the underlying event is unreliable, and remove automatic reminders that contradict known submissions.

The no-build outcome is explicit: if the practice repeats intake anyway, cannot act on submissions, or incurs more new work than it avoids, this interface is not enough. The correct next investment would be the office process or integration. That is why this case ends with an operational decision instead of a large completion chart.