Most smart products already have a name. The hard part is making the device hear that name reliably without sending every conversation to the cloud.

This is the product question behind a custom wake word: can a device recognize one short phrase locally, then start the next interaction?

The product name and the wake word are different things

A brand name is designed for people. A wake word is designed for a detector. The same phrase can be a good brand name and a poor wake word if it is too short, too common, or easily confused with normal conversation.

For an example product, imagine a small robot called “Taro”. The desired flow is:

“Hey Taro”       → wake the robot
“Move forward”   → start a fixed action
“Stop”           → stop the motor

The wake phrase and the fixed commands are not the same product requirement.

KWS or ASR?

If the product needs to understand arbitrary sentences, names, numbers, or parameters, it needs speech recognition and intent handling. But if it only needs one wake phrase or a small list of commands, keyword spotting is a more focused option.

KWS does not try to transcribe everything. It asks a narrower question: “did one of the target phrases occur?” That makes a small, local model possible.

What I would test before choosing the name

I would not approve a wake word from the spelling alone. I would test:

1. Several speakers saying the phrase naturally.
2. Different speaking speeds and distances.
3. The target microphone and enclosure.
4. Background conversation, music, fans, and household noise.
5. Similar-sounding phrases that should not trigger the product.

The browser is a useful first filter. It can tell us whether a phrase is worth taking to a device. It cannot prove that the same result will hold after the microphone, enclosure, distance, and noise environment change.

The delivery path

The practical flow is:

Product name
    ↓
Train a custom keyword model
    ↓
Test with real voices
    ↓
Export ONNX or TFLite
    ↓
Run locally on the target product

For a product team, the useful deliverable is not only a model file. The team also needs the audio input assumptions, feature extraction path, threshold behavior, cooldown logic, and a way to connect a detection callback to a safe product action.

Where a small custom model fits

For my experiments, I wanted a model that could run offline and fit several possible targets: Python, Web, Android, and embedded hardware. A standard ONNX or TFLite artifact makes that transition easier than a platform-locked runtime.

Voicute is one way to start this process without building the training pipeline first: enter the product name, train a Basic model, test it with real voices, and decide whether the result is good enough to download. Real-voice enhancement can help when the target users have a specific accent or speaking style.

The honest boundary is important: online testing is a screening step, not a production guarantee. The final product still needs measurements for recall, false triggers per hour, latency, memory and power.

A minimal local integration example

The runtime should expose a simple event to the application layer:

def on_keyword(word, probability, info):
    if word == "hey_taro":
        robot.start_interaction()
    elif word == "stop":
        robot.stop()

The application should also implement cooldowns and safe failure behavior. A detector should not repeatedly start an action because the same phrase remains in the audio buffer.

What I would ship with the project

• The ONNX or TFLite model;
• A reproducible inference example;
• The supported sample rate and audio format;
• Threshold and cooldown defaults;
• A test checklist for the final microphone and enclosure;
• Clear limitations instead of a universal accuracy claim.

The open-source runtime and examples are available in onnx-wakeword. If you want to test your own product name, use the Voicute online training page.

Disclosure: Voicute is my project. I am sharing the engineering process and its limitations, not claiming that one wake-word model is best for every language or device.