# Let customers log their day by speaking.

A health coaching product’s customers already speak their day into a separate messaging app, because typing it in is the step they drop first. The system is drawn to turn a one-tap voice note into structured entries the team can review, tagged to the right customer from the start.

Domain: Health coaching · product
Label: Designed

## Architecture

- **Identify**: The customer is signed in before they speak, so every entry is tagged to the right person from the start.
- **Speak**: One tap, and the customer says their day in their own words, in their own language.
- **Transcribe**: An accent-ready engine turns the voice note into text, tuned for the accents a prior attempt got wrong.
- **Structure**: The free speech becomes named fields: readings, meals, symptoms and mood.
- **Confirm**: The customer reviews what was heard before anything saves.
- **Deliver**: Clean, customer-tagged records reach the team’s own system through an API, on their own schedule.

Boundary (never invents an entry): The system structures and tags, and never edits or invents an entry; nothing saves until the customer confirms what was heard.

## Scope

Designed the voice-to-structure system against a real failure from a prior attempt, and proposed it to the company.

Not built for the company, and not running. The demo on this page is ours, on synthetic entries.

## Anonymized

The company, its customers and every logged entry are left out. Every entry in the demo is synthetic, and no real voice sample is used.

## The situation

Customers who stay long enough to matter are already narrating their day by voice into a messaging app, and someone on the team pieces it together into records by hand, with gaps every time a name or an accent gets missed.

A previous attempt at voice logging dropped records outright when it could not parse certain names and accents, so entries never reached the right customer’s file. Typing the day into a form removes that risk, and reintroduces the exact friction that made customers stop logging in the first place.

## What the design settles

This system is designed, not running, so what follows is what the design decides, not a result.

- Which fields a spoken day turns into, and what separates a symptom from a routine note.
- How a customer is identified before they speak, so an entry can never land on the wrong record.
- What the customer sees to confirm before an entry saves.
- What crosses the API to the product’s own system, and what stays inside the log.

## Demo

[Open the demo](https://octyn.co/casestudies/voice-logging/demo)

## Related

- [Product systems](https://octyn.co/systems/product)
- [Log an expense in the time it takes to say it.](https://octyn.co/casestudies/mooney)
- [The Consult](https://octyn.co/consult)

Canonical: https://octyn.co/casestudies/voice-logging