> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/guides/ae-handoff.md).

# SDR to AE handoff

SDRs book the AE's first meeting from the Distro browser extension, and a queue picks the AE.

The SDR to AE handoff is the moment an SDR passes a qualified lead to an account executive, usually by booking the AE's first meeting. In Distro, the SDR does it from the browser extension on the Gmail thread or CRM record where they qualified the lead. A workflow picks the AE, so the SDR doesn't need to know whose turn it is, and the meeting records the SDR as the **Booking rep**.

## At a glance

| Step                | Who      | What happens                                                                 |
| ------------------- | -------- | ---------------------------------------------------------------------------- |
| 1. Pick up the lead | SDR      | The extension offers the lead from the page, or the SDR types the email.     |
| 2. Route            | SDR      | **Book with**, picks the handoff workflow, fills the handoff inputs.         |
| 3. Pick the AE      | Workflow | **Show Scheduler** with **Use event hosts**: the event's queue picks the AE. |
| 4. Book             | SDR      | Picks a time on the AE's calendar.                                           |
| 5. Brief the AE     | Workflow | Optional email on **Booked**.                                                |
| 6. Follow through   | Workflow | A **Meeting lifecycle** workflow tells the SDR if it falls through.          |

## Before you start

| You need                                                         | Where                                                     |
| ---------------------------------------------------------------- | --------------------------------------------------------- |
| A queue of AEs with a routing profile that counts **Meetings**   | [Create and manage a queue](/routing/queues.md)           |
| A **Shared event** hosted by that queue, such as `AE intro call` | [Event types and hosts](/scheduling/event-types.md)       |
| Each AE's calendar connected                                     | [Calendars and availability](/scheduling/availability.md) |
| The extension installed and signed in for every SDR              | [Browser extension workflows](/workflows/extension.md)    |

## Build the handoff workflow

{% stepper %}
{% step %}

### Start from the browser extension

Create a workflow named something SDRs recognize, such as `AE handoff`, and choose **Browser extension**. Under **Inputs**, add the details your AEs want: use case (required), timeline, and SDR notes. Set **maps\_to** on a field to prefill it from the CRM record.
{% endstep %}

{% step %}

### Book the AE

Add **Show Scheduler** with `AE intro call` and **Hosts** set to **Use event hosts**, so the event's queue picks the AE with its routing profile.
{% endstep %}

{% step %}

### Brief the AE (optional)

On **Booked**, add **Notify by Email** to the meeting's **Host email**, with the use case and SDR notes from the trigger's inputs.
{% endstep %}

{% step %}

### Publish

**Publish** and turn the workflow **On**. SDRs see it in the extension only while it's on. Try it yourself with a test lead; booking sends a real invite and counts the queue turn, so cancel the meeting afterwards.
{% endstep %}
{% endstepper %}

## Tell the SDR when a meeting falls through

Build a second workflow on **Meeting lifecycle**: **Meeting statuses** **Marked as no-show** and **Cancelled**, **Event types** set to `AE intro call`. Add **Notify by Email** to the **Booking rep**'s email so the SDR can follow up. A meeting the lead booked themselves has no booking rep, so give the email a fallback address such as your SDR manager.

## What the SDR does

1. Open the lead's Gmail thread or CRM record and open the extension.
2. Select **Book with**, pick `AE handoff`, fill in the inputs, and submit.
3. The booking page shows the routed AE as host. Pick a time and confirm.

Book while you are with the lead. The booking page is a routed session, not a standing link, so a lead who wants to pick later should get your team's booking link instead; that booking doesn't go through the handoff workflow.

## Troubleshoot

| What happens                            | What to check                                                                      |
| --------------------------------------- | ---------------------------------------------------------------------------------- |
| The SDR doesn't see the workflow        | It's published, **On**, starts with **Browser extension**, and the SDR has access. |
| The extension can't route the lead      | Every path must reach **Show Scheduler**.                                          |
| The booking page says the session ended | It was booked, closed, or expired. Route the lead again.                           |


---

# 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 following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/guides/ae-handoff.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

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.