# From inbox to proposal: a purpose-built workflow for a European speaker agency
> A leading European speaker agency handles hundreds of speaker requests a month, and each one used to move by hand across five tools. Twistag built a workflow for the agency's known process that takes a request from the shared inbox to a client-ready proposal. Every step has one defined job, which keeps latency, cost and reliability under control, and the agency's team reviews every proposal before it goes out.

Client: European speaker agency · Industry: Media & entertainment · Practices: AI & Agents, Product Engineering · Timeline: Multi-month engagement
## Key results
- **5** tools each request used to pass through
- **6** retrieval signals behind every search
- **1** model call to structure each request
- **Every** proposal reviewed before it goes out
## The challenge

**Five tools for every request.**

Twistag built a workflow for a leading European speaker agency that takes each speaker request from the shared inbox to a client-ready proposal. Each step has a defined job: one structured extraction call, a search that runs six retrieval signals in parallel, drafted proposal copy with a written reason for every match, and a review by the agency's team before anything is sent.

The agency receives hundreds of speaker requests a month. Each one used to be handled by hand across five tools: the inbox, the speaker database, a document editor, the CRM and the calendar. Requests arrive as free text, with budgets in different currencies, mixed formats and languages, and speakers sometimes named and sometimes only described. A good shortlist depends on who a speaker is and what they talk about, and every shortlist then needs a proposal written around it. The process was well known. The cost was in repeating it by hand, request after request.

## The approach

**A defined job for every step.**

1. **Turn the email into a brief.** A sidebar app inside Front, the agency's shared inbox, turns an email conversation into a brief. It identifies the client's organisation from the email domain, extracts budget, location, topics, session format and session type, and skips duplicate briefs. 
2. **Search on meaning, filter on facts.** One model call splits each request into who the speaker should be, what they should talk about, and the budget, format and language. Budget is converted by currency and applied as a hard filter, with format and language. Six retrieval signals then run in parallel, from semantic similarity over profiles and talks to fuzzy name matching, and their results are merged by weighted rank. Searches the team has already mapped, such as AI or ESG, skip the model entirely. 
3. **Draft a proposal with its reasons.** Each proposal section is filled by the same search. Every speaker comes with a written reason for the match and a bio adapted to the event's topic. Speakers without fee information are left out. If the model's output does not match the expected structure, the workflow asks for one correction and stops there. 
4. **Keep the team in control.** New proposals wait in review. The team edits sections, swaps speakers or regenerates a section, then approves. Approval emails each speaker an availability check, the proposal goes to the client through Front, and the client confirms speakers on a shared page. Leads are created in Pipedrive. 

## The impact

**A known process, run the same way every time.**

Requests now move from the inbox to a client-ready proposal in one workflow, and the team's time goes to reviewing proposals and to clients. Because each step has one defined job, latency, cost and reliability stay under control, and a slow or failed step does not stop the rest: a slow search signal returns no results, a failed bio rewrite falls back to the original, and a failed availability email does not block approval.

The data stays current without manual upkeep. Speaker profiles sync from Airtable on a schedule, a watchdog resumes stalled syncs, and speakers deleted at the source are removed behind a safety check. Prompts are versioned per environment in Amazon Bedrock, and failures are reported to Sentry. Speakers, their tags, topics and talks are stored as linked records, so matching works on meaning across all of them.

> A known process is better served by a defined workflow than by an open-ended agent.

## Technologies used

- AWS Bedrock
- Supabase
- pgvector
- Next.js

> Twistag built a workflow that takes a European speaker agency's requests from the inbox to a client-ready proposal, with the team approving each one.

---

Source: https://twistag.com/case-studies/ai-workflow-european-speaker-agency