Skip to the content
  1. Work
  2. Clear Decisions

Product study · Clear Decisions

Know what happens next, before you need to ask.

Clear updates, understandable recommendations, and a choice you can review before confirming.

A new customer experience concept informed by communication gaps encountered while building service software.

Demo visit · Compact SUV (generic)

Waiting on your choices

The requested work is under way. Two extra items need your choice; nothing extra is done without it.

  1. Checked in (done)
  2. Being checked (done)
  3. Waiting on your choicesNow
  4. Work under way
  5. Ready for pickup
Last confirmed by the service team
10:40 AM
Next update
By 11:30 AM, as promised by the team
Ready time
Not known yetThe team has not given one, so none is shown.

Needs your choice

The working product with a fictional visit. Choices you make here carry into the demo; nothing is sent or stored beyond this tab.

Overview

Product conceptDesign and build

The problem

When a car is in for service, the update often arrives as a price: a number by text or phone, before anyone has said what was found or why it matters. A question about status gets “should be soon”, with no next update promised. People approve under pressure, or say no to work they might have wanted, and then call again to ask what is happening.

Why it matters

People need enough understanding to choose without pressure: what is known now, what was found, why it may matter, the whole amount and what happens next. The service team needs that choice recorded exactly, against the estimate the person actually saw.

The change

Clear Decisions is a phone-first update and decision experience. It opens on what the team has confirmed and when, keeps an unknown ready time unknown, explains each recommendation with its evidence before the amount, and lets a person approve, decline or ask before reviewing the full total and confirming one exact version.

My part, and its stage

A new concept that I designed and built as a working demo. It grows out of two problems my earlier service software was built to surface in conversations: a price given before its reason, and an update request answered without a next step.

Three decisions

Decision one

Explain the reason and evidence first

Each recommendation opens with what was found, the evidence behind it and why it may matter, in plain words. The amount follows the reason, split into parts and labor. Evidence says what it is: an illustration is labelled as not a photo of this car, a missing photo stays visibly missing, and no measurement is invented when none was taken.

How evidence is shown
  • Each evidence chip names its kind: illustration, photo or note.
  • An unavailable photo opens to the reason it is missing, with nothing drawn in its place.
  • A measurement appears only when one was taken; otherwise the screen says none was.
  • Timing repeats what the team said. The product never adds urgency.

Recommendation 1 of 2

Replace the cabin air filter

What was found

The filter that cleans the air coming through your vents is covered in leaves and dark dust.

No measurement was taken for this item.

Why it may matter

A clogged filter lets less air through, so heating, cooling and window demisting work less well, and the cabin can smell musty.

The service team did not mark this as urgent. It can wait for another visit.

If you approve

Parts
$48.00
Labor
$22.00
This item
$70.00

Before the demo tax, which the review shows in full.

The cabin filter recommendation: finding, evidence and reason, then the amount.

Decision two

Keep approve, decline and ask distinct

Nothing is preselected. Approve, decline and ask carry the same weight, and each says what it means. Preparing a question approves nothing: the item stays out of the total and the message is marked prepared, not sent. An item left alone stays “no decision yet”, never quietly declined, and every choice can change until confirmation.

How choices become a total
  • A choice is no decision, approved, declined or a question. Only approved items reach the total.
  • Choosing Ask opens a short composer; the earlier choice stays until the question is prepared.
  • Any change clears the confirmation tick, so the total is always reviewed as it stands.
  • Tax is worked out once, on the approved subtotal, in whole cents, rounded half up.

Prepared, not sent

“Is the cracked edge only on one side?”

The review: one approval, one prepared question, and a total that counts only the approval.

Decision three

Treat a changed estimate as a new commitment

If the team revises a price while someone is reviewing, confirming stops. The screen shows the old and new line, the exact difference including tax, and why it changed. Choices are kept as drafts, but an approval at the old price has to be made again. The server rule matches: a submission against an older version is refused even if the interface is bypassed.

How a confirmation is checked
  • Every submission names the estimate version and each item version it was made against.
  • The server works out the total itself and ignores any total the phone sends.
  • Each confirmation carries one request key, so a retry after a lost reply returns the same receipt instead of a second one.
  • A failed or offline attempt keeps the draft and retries with the same key.

The estimate changed: version 1 to 2

The filter in stock does not fit this model. The one that fits costs more.

Itemized change
LineWasNowChange
Replace the cabin air filter, parts$48.00$53.00+$5.00
Total for your approved items$75.60$81.00+$5.40

That is +$5.00 in parts and labor plus +$0.40 in demo tax.

Your earlier choices are kept as drafts. An approval made at the old price needs to be made again before you confirm.

Why you cannot confirm yet: the estimate changed. Look at what changed before confirming.

An updated estimate: the changed line, the exact difference, and confirming paused.

The tradeoff

Pausing on every price change adds a step for someone in a hurry. I chose that step over a total that quietly moved after it was read.

Where it stands

Try these interactions in the demo:

  • Built

    Totals in whole cents match the fixtures, and only approved items count.

  • Built

    A question never approves anything, and an untouched item is never declined.

  • Built

    A changed version blocks confirming until it is reviewed and approved again.

  • Built

    A lost reply, an offline attempt, a slow reply and a double tap each behave in a defined, tested way.

  • Built

    The receipt says it is a demo kept in this tab, and it authorizes nothing.

Open the full demo