Overmind Journal
Voice knows where the conversation happens.
Voice recognises whether it is being used on a website, in an app or within an embedded system. Three illustrative scenarios show possible conversations.
New development · Deployment and scope are agreed for each project.
“What happens next?” On a company website, this question might be about making initial contact. In an app, it may concern a workflow. In an embedded system, the focus might be a particular step.
The words are the same. The starting point is different.
With our new development, Voice recognises the digital environment in which it is being used: a website, an app or an embedded system. This provides an additional piece of information for designing the conversation.
We define how Voice uses this context for each deployment. The task, approved sources and conversation rules determine which response is appropriate.
An initial context for the conversation
Someone visiting a website may want an overview, an explanation of an offering or an answer to a specific question. Someone opening an application often already has a particular task in mind. An embedded Voice may be part of an existing system and its workflow.
Recognising the environment helps us take this starting point into account when designing the conversation. The actual request is clarified through dialogue. A relevant follow-up question can help define the task more precisely.
The information available and the sources Voice may use are agreed for each deployment. Recognising an app or a website does not, by itself, grant access to its content or to personal data.
The same question in three environments
Illustrative scenarios: The following dialogues show proposed conversation paths. Connecting to particular workflows and additional context data is a separate project decision.
On the public website
You ask: “What happens next?”
One possible follow-up question is: “Would you like an overview first, or would you like to discuss a specific deployment?”
Here, Voice could first distinguish between a need for orientation and a specific request. The conversation would begin at the appropriate entry point.
In an app
You ask: “What happens next?”
One possible follow-up question is: “Which step of your workflow would you like to clarify?”
For an app with an agreed workflow, the conversation could focus on the task. The project would define which information about that workflow is available.
In an embedded system
You ask: “What happens next?”
One possible follow-up question is: “Are you asking about the step you are currently working on in the system?”
If the relevant application context has been approved and connected, Voice could use it as a starting point. Follow-up questions would clarify any missing information.
From recognition to appropriate conversation rules
The practical value depends on what follows from recognising the environment. Together with your experts, we clarify: What questions arise here? Which opening is helpful? When does Voice need more information? When should a responsible person take over?
These decisions are part of Voice Design. Environment recognition adds to the foundation for that work. Specialist terminology, sources and common exceptions remain part of the shared design process.
Test it in a real working situation
A useful first deployment begins with a specific task and a clearly defined environment. Real questions help us assess whether the conversation works and which follow-up questions are still missing.
We also consider ambiguous requests. The conversation should remain understandable when a question can mean more than one thing. Supported information and unresolved points remain distinguishable.
In this way, a new capability becomes a conversation suited to your workflow. Deployment, integration and scope are agreed for each project.
