> For the complete documentation index, see [llms.txt](https://doc.aissist.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.aissist.io/tutorial/streamline-with-human-team.md).

# Streamline with Human Team

*Last updated: May 14, 2026*

Use human handoff when Aissist should stop and let your team take over.

This works best when you define:

* when Aissist should escalate
* what note Aissist should leave for the team
* where the conversation should go after escalation

### How human handoff works

Human handoff usually has three parts:

1. define the handoff behavior in global instructions or a sub agent
2. let Aissist detect that handoff happened
3. route the conversation to the right team in the gateway

### Step 1: define when Aissist should escalate

Tell Aissist when to hand work to the human team.

You can do this in:

* **Global Instructions** for rules that apply everywhere
* **Sub Agents** for workflow-specific handoff

Sub agents are the better choice for most handoff flows.

For example, a return workflow can tell Aissist to:

* collect the order number
* collect the customer email
* collect the return reason
* tell the customer the case has been forwarded to the team after all details are collected

An order tracking workflow can tell Aissist to:

* send the tracking URL when the user asks about order status
* check whether the tracking shows the order is stuck
* tell the customer the logistics team has been informed when the shipment is stuck

### Step 2: let Aissist detect escalation

Aissist includes built-in escalation detection.

By default, Aissist checks these escalation signals:

1. the user explicitly asks for escalation or a human agent
2. Aissist clearly says the case is escalated or handed off
3. there is a possible escalation condition that is not yet confirmed
4. the conversation is outside the defined scope or context

This includes statements about:

* transferring or escalating the case
* checking, confirming, notifying, or investigating later
* contacting someone or following up later
* lacking the understanding, information, context, access, or capability to help

Confirmed escalation signals trigger automatic escalation.

Unconfirmed escalation conditions does **not** trigger an escalation. For example, if Aissist is still waiting for the user to provide required information—such as a user ID, order number, or any other details needed by the human support team—it does not escalate the conversation until all necessary information has been collected.

In these situations, Aissist would keep the conversation open, request the missing details, and only proceed with the escalation once the required information has been confirmed by the user.

When escalation is confirmed, or when the conversation is clearly out of context, the system escalates automatically.

It adds:

* the `sys_escalation` tag
* a default escalation note with the issue summary and next step

#### Tips for better escalation detection

Write escalation instructions with clear confirmation rules.

This works best:

* define what counts as a direct user request for a human
* define which handoff statements count as confirmed escalation
* define which out-of-context cases should be handed to a human team

Avoid vague triggers such as:

* may need review
* might require escalation
* seems complex

These signals are not confirmed yet.

They should lead to one more check, not immediate escalation.

### Step 3: customize escalation behavior

Use the **Escalation** settings in the workspace when you need tighter control.

#### Customized Escalation Instruction

You can customize how escalation should be detected.

These instructions do not guide how Aissist replies to the user.

They only check the user's message and Aissist's reply to decide whether escalation is needed.

For example:

> "Only escalate when the user has a payment issue."

This lets you narrow escalation to the cases that matter.

Use **Global Instructions** and **Sub Agents** to control reply behavior.

Use **Customized Escalation Instruction** only to control escalation checks.

{% hint style="info" %}
If you change the customized escalation instruction here, update the related **Global Instructions** and **Sub Agents** as well.

This keeps reply logic and escalation logic aligned.

It also improves escalation accuracy.
{% endhint %}

#### Escalation Summary

You can also define the structured summary that Aissist leaves for the human team.

For example:

```json
{
  "destination": "the destination of user travel",
  "number_of_days": "the number of days that user plan to travel",
  "number_of_esim": "the number of eSIM that user wants",
  "Model of Phone": "The model of phone user is using if provided"
}
```

Use this to capture the information your team needs before taking over.

#### Suspend Afterwards

Turn on **Suspend Afterwards** if Aissist should stop replying after escalation.

This is useful when the human team should fully own the conversation from that point.

### Step 4: route escalations in the gateway

Once Aissist escalates, the gateway decides where the conversation should go.

If you want a specific team to handle the conversation, use this step to route the escalation.

You can also skip gateway routing and use platform rules or automation to assign the conversation based on the `sys_escalation` tag.

#### Escalation target

Set an **escalation target** when escalated conversations should go to one default team.

When this is configured, Aissist does more than add the `sys_escalation` tag and escalation note.

It also assigns the conversation to that target.

The target can be an inbox, team, group, or queue, depending on the platform.

#### Handover rules

Use **handover rules** when different workflows should go to different teams.

Each handover rule maps:

* one or multiple sub agents
* a destination target

This gives you finer control than one default escalation target.

For example:

* billing sub agents can go to the billing team
* return sub agents can go to the returns team
* technical support sub agents can go to the support queue

<figure><img src="/files/pJJxwAjkGcUTZGGFC4jd" alt=""><figcaption></figcaption></figure>

See [Deploy Gateway](/tutorial/deploy-gateway.md) for gateway setup details.

### Optional platform routing

You can also build routing rules on your platform using escalation tags.

#### Notify or assign on tag

Use platform rules to notify or assign a human agent when a conversation receives an escalation or handoff tag.

<figure><img src="/files/eUZA7JlKqcOWgMr7Mm1Y" alt=""><figcaption></figcaption></figure>

#### Dedicated inbox

Create a shared inbox for conversations that need human attention.

Then add a platform rule to move tagged conversations there.

This works well for teams that process handoff from a shared queue.

#### Shared view

Some platforms use views instead of inboxes.

In that case, create a shared view for escalation or handoff tags and have the team monitor it.

### Recommended setup

For most teams:

1. use sub agents to define when handoff should happen
2. customize escalation rules and summaries in the workspace when needed
3. turn on **Suspend Afterwards** if humans should take over fully
4. set an escalation target for the default destination
5. add handover rules if different workflows should go to different teams

This keeps escalation logic, summaries, and routing clearly separated.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.aissist.io/tutorial/streamline-with-human-team.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.