Support as architecture: The 3-Layer Model for Workflow-Embedded Support

Support in companies often follows the logic of systems. Documents are stored in the DMS. Tickets run in the service tool. AI works in a separate interface. For users, this means multiple paths, multiple decisions, multiple breaks.

A viable support model is based on the specific work situation—and aligns the technology used with it.

The 3-Layer Model for Workflow-Embedded Support describes such an architecture. It bundles different forms of support behind a uniform access point and arranges them in a clear sequence: context, search, assistance – with clean escalation if necessary.

The 3-Layer Model for Workflow-Embedded Support with the tts performance suite structures support not according to technologies, but according to a clear usage logic.

The focus is on uniform access. Regardless of whether someone is working in an ERP system, an Office application, or an HR tool, the path to help remains the same. This fixed entry point reduces complexity because users do not have to decide which tool to open.

This access is followed by three coordinated levels:

1. Context-based support

Help appears where you work—right next to the main application in a help bar. It refers to the specific screen or the current process step.

2. Search

When specific questions arise, users can actively search for content.

3. Assistance

AI-supported assistance answers questions in a dialogical manner and refers to underlying content directly within the tts performance suite.

Only when these layers do not provide sufficient guidance is the issue escalated to technical support.

The model thus defines a clear sequence:

Orientation → Deepening → Dialogue → Escalation.

This sequence seems unspectacular. That is precisely where its strength lies. It creates predictability in support and relieves both users and service teams.

The first layer determines whether support is accepted in everyday work.

Context-based support means that help appears where the work is being done—not in a separate portal. When someone opens a transaction or a specific process step, the relevant information is immediately available.

The key difference lies in the trigger. Users don't have to search for or know the name of a document. The tts performance suite recognizes the context and provides relevant content.

In practice, this can include:

• Step-by-step instructions for new processes
• Explanations of mandatory information
• References to downstream process steps

Context-based support is not a substitute for training. It reinforces what has been learned in everyday work.

After a go-live, uncertainties arise for various reasons. Some things were taught in training, but that was some time ago. Some of what was learned is forgotten. At the same time, details in the system change: a field has been renamed, an order has been adjusted, an additional mandatory field has been added.

Context-related notes come into play here. They retrieve knowledge at the right moment and make deviations transparent.

The decisive factor here is not the amount of content, but its clear assignment. Content must be clearly linked to masks, roles, or process steps. This is the only way to build trust. If this link is missing, even good documentation becomes a search task again.

Layer 1 reduces friction in the work process by providing orientation directly at the point of use.

Context resolves many questions—but not all of them.

Once users know what they are looking for, the second layer becomes relevant: active research. Searching within the tts performance suite provides structured access to existing content.

The difference from the first layer lies in the initiative. With context support, the information comes to the right place. With search, users go one step further and formulate a specific request.

Typical situations for this layer are:

• Rarely used processes
• Cross-cutting topics across multiple applications
• In-depth information after an initial reference

For search to work, two conditions must be met:

1. Content must be clearly structured and consistently named.
2. Terms in the search must match the language of the organization. Employees do not search for system names but for tasks.

Search therefore does not replace context support. It complements it. While layer 1 reduces friction, layer 2 enables targeted in-depth analysis.

Both layers are interlinked. Without context, the number of search queries increases. Without search, specific questions lead to frustration.

Even search has its limits.

Not every question can be formulated with a clear keyword. Some situations are more complex: a process affects several areas, an exception occurs, or an error cannot be clearly identified.

This is where the third layer comes in: assistance.

Within the tts performance suite, AI-supported assistance answers questions in a dialogical manner. Users can describe their concerns in natural language. The assistance draws on existing content and refers to the underlying sources.

The crucial point here is not the technology, but its integration. The assistance does not work in isolation from the knowledge base. It uses verified documentation as a basis and makes it accessible.

This changes its role. It does not replace content. It structures and condenses existing knowledge.

This has two effects:

1. Users receive a precise answer more quickly.
2. At the same time, it remains clear what this answer is based on.

This transparency is crucial, especially in an enterprise context. Without reference to valid content, trust declines. With a clear source base, assistance becomes an extension of the existing knowledge architecture – not a separate information channel.

Layer 3 thus supplements context and search with a dialogical approach. It is particularly suitable for complex questions that require the consolidation of multiple pieces of information.

Not every question can be answered through context, search, or assistance.

Some cases are technical in nature: an authorization is missing, an interface is not responding as expected, an error code is blocking the process. This is where self-support ends. And this is precisely where escalation begins.

In the 3-level model, the transition is deliberately clearly defined. Only when orientation, in-depth information, and assistance do not provide a solution is a ticket created. The crucial difference lies in the preparation.

If users have previously seen contextual information or formulated a question in the assistance section, relevant information is already available. This information can be transferred to the ticket creation process. This reduces duplicate entries. It shortens queries. And it speeds up processing by the service team.

In this model, escalation does not mean a break but a structured transition. Self-support and technical support do not exist side by side. They are intertwined. Users go through a comprehensible sequence before a case is handed over to the service team.

This relieves both sides: employees receive help more quickly. Service teams focus on cases that actually require technical expertise.

The 3-Layer Model is not a large-scale project. It is a structure that can be built up step by step.

The first step is to define the central access point. Employees should know where to find support, regardless of the application or role. This entry point provides orientation even before the content has been fully developed.

In the second step, prioritized processes are equipped with context-based support. This results in structured content with clear titles and classifications. These also form the basis for a functioning search function.

Context and search therefore grow together. While context provides immediate orientation, the search function enables targeted in-depth exploration.

Only on this consistently maintained knowledge base can an assistant unfold its full effect. It can merge content, answer questions in a dialogical manner, and refer to valid sources.

Escalation to technical support should be considered from the outset – but not as the primary entry point. The goal is to avoid unnecessary tickets and prepare technical cases properly.

A proven approach therefore looks like this:

1. Implement tts performance suite as the central access point
2. Equip prioritized processes with context support
3. Prepare content in a structured manner and name it consistently
4. Integrate assistance
5. Cleanly connect ticket transfer

This results in a clear sequence rather than an overloaded start.

It is not important to cover all applications completely. The key is that the model works in the core area and builds trust. From there, it can be expanded to other processes, roles, and systems.

Many organizations already have all the building blocks in place: documentation, search, AI, ticketing. What is often missing is the structure that connects these elements in a meaningful way.

The 3-level model for support in the workflow with the tts performance suite organizes support along the actual workflow. It starts with context, supplements targeted search, expands with assistance, and leads to a clean escalation if necessary.

This logic creates predictability. Users know how to proceed. Service teams receive better-prepared requests. Knowledge does not remain in the project context, but becomes part of daily work.

A support model is not made stronger by additional features. It is made stronger by clarity.

Is the model only intended for ERP systems?

No. Centralized access works independently of the application. ERP, HR, Office, or specialized applications can be integrated into the same support logic.

Do I have to introduce all three layers at the same time?

No. Many organizations start with context support for prioritized processes and gradually add search and assistance.

Does assistance replace traditional documentation?

No. Assistance accesses existing, verified content. Without a consistent knowledge base, it loses quality and trust.

Does this make technical support redundant?

No. The model reduces unnecessary tickets, but does not replace technical malfunctions or authorization problems. It structures the transition to support.

What is the tts performance suite?

The tts performance suite is a digital adoption platform. It technically combines central access and the three support layers. It connects context-based support, search, assistance, and ticket transfer within a consistent architecture. The goal is not to create another tool, but rather a uniform support logic across applications.