# API overview
Source: https://docs.yuzulabs.io/api-reference/introduction
Authentication, base URL, scopes, and error semantics for the Yuzu API.
The Yuzu API lets you create and manage video-generation flows from your own systems — typically to wire Yuzu into a CRM, automation, or notetaker pipeline.
## Base URL
```
https://app.yuzulabs.io/api/v1
```
## Authentication
All endpoints require a Bearer token in the `Authorization` header:
```
Authorization: Bearer yzlk_your_api_key_here
```
API keys start with `yzlk_` and are created from **Settings → API Keys** in your Yuzu workspace. Keys are scoped to a single workspace and can be restricted to specific operations (see **Scopes** below).
Treat keys as secrets. They grant access to your workspace's data and quota. Rotate immediately if exposed.
## Scopes
| Scope | What it allows |
| --------------- | ----------------------------------------------------------------- |
| `flows:create` | Start new flows. |
| `flows:read` | Read flow status, scripts, and rendered video URLs. |
| `flows:approve` | Approve, edit, or reject scripts when manual approval is enabled. |
| `flows:cancel` | Cancel an in-progress flow. |
| `*` | All of the above. |
## Errors
Errors return a JSON body with a stable `code`:
```json theme={null}
{
"success": false,
"error": "Email content must be at least 50 words",
"code": "VALIDATION_ERROR"
}
```
| Status | Code | Meaning |
| ------ | -------------------- | ----------------------------------------------------- |
| 400 | `VALIDATION_ERROR` | Request body failed validation. |
| 401 | `INVALID_API_KEY` | Missing or invalid API key. |
| 403 | `INSUFFICIENT_SCOPE` | Key doesn't have the required scope. |
| 404 | `FLOW_NOT_FOUND` | The flow ID doesn't exist or isn't in your workspace. |
| 429 | `QUOTA_EXCEEDED` | Workspace video quota reached. |
| 5xx | `INTERNAL_ERROR` | Transient — retry with exponential backoff. |
## Available flows
60–70 second follow-up videos generated from a sales-call summary email.
# API quickstart
Source: https://docs.yuzulabs.io/api-reference/quickstart
Generate your first Yuzu video via the API in under five minutes.
This walk-through generates a 60–70 second sales-email video from a call summary using the public API. If you're driving Yuzu from the dashboard instead, see the [UI quickstart](/quickstart).
## 1. Get an API key
1. Sign in at [app.yuzulabs.io](https://app.yuzulabs.io).
2. Open **Settings → API Keys**.
3. Click **Create key**, give it a name, and select scopes: `flows:create`, `flows:read`, `flows:approve`, `flows:cancel`. Use `*` for full access.
4. Copy the key. It starts with `yzlk_` and is only shown once.
Keys are scoped to a single workspace. Treat them like passwords — never commit them to source control.
## 2. Make sure your workspace is ready
Before the first request, your workspace needs:
* At least one **avatar** that's been processed (16:9).
* A configured **ElevenLabs voice** (or use the workspace default).
* Available **video quota**.
You can confirm all three from **Settings → Brand & Voice**.
## 3. Create a video
```bash theme={null}
curl -X POST https://app.yuzulabs.io/api/v1/flows/sales-email-video \
-H "Authorization: Bearer yzlk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{
"emailContent": "Great call with John from Acme Corp today. We discussed video marketing pain points: (1) production time, (2) brand consistency, (3) scaling content. Next step: send a product demo.",
"autoApproveScript": true,
"prospectName": "John",
"prospectCompany": "Acme Corp"
}'
```
You'll get back a `flowId`. The flow runs asynchronously — script → segments → voice → render.
## 4. Poll for completion
```bash theme={null}
curl https://app.yuzulabs.io/api/v1/flows/sales-email-video/{flowId} \
-H "Authorization: Bearer yzlk_your_api_key_here"
```
When `status` is `completed`, the response includes `videoUrl`.
## Next steps
Every parameter, status, and error code.
Bearer tokens, scopes, error codes.
# Sales Email Video Flow
Source: https://docs.yuzulabs.io/api-reference/sales-email-video
Generate a 60–70 second branded video from a sales-call summary email.
The Sales Email Video Flow converts a sales-call summary into a short follow-up video featuring an AI-generated script, voice narration, and avatar render. Flows run asynchronously through a sequence of states.
**Base URL**: `https://app.yuzulabs.io/api/v1`
All endpoints require [Bearer authentication](/api-reference/introduction#authentication) and a workspace with at least one ready avatar, a configured voice, and remaining quota.
## Lifecycle
```
pending → generating_script → [pending_approval] → segmenting → voice_generating → video_generating → completed
```
| Status | Description |
| ------------------- | -------------------------------------------------------------------------------- |
| `pending` | Flow accepted, queued. |
| `generating_script` | Drafting the video script. |
| `pending_approval` | Awaiting a human approve / edit / reject (only when `autoApproveScript: false`). |
| `segmenting` | Breaking the script into scenes. |
| `voice_generating` | Producing the voiceover. |
| `video_generating` | Rendering the avatar + scenes. |
| `completed` | `videoUrl` available. |
| `failed` | Permanent error — see `error`. |
| `cancelled` | Cancelled by user or timeout. |
## Endpoint summary
| Method | Path | Scope |
| -------- | ---------------------------------------------- | --------------- |
| `POST` | `/v1/flows/sales-email-video` | `flows:create` |
| `GET` | `/v1/flows/sales-email-video` | `flows:read` |
| `GET` | `/v1/flows/sales-email-video/{flowId}` | `flows:read` |
| `POST` | `/v1/flows/sales-email-video/{flowId}/approve` | `flows:approve` |
| `DELETE` | `/v1/flows/sales-email-video/{flowId}` | `flows:cancel` |
***
## `POST` Create flow
`POST /v1/flows/sales-email-video`
Creates a flow and starts script generation. The response returns immediately with a `flowId` you can poll.
### Body parameters
Sales-call summary in plain text. Minimum 50 words. Becomes the input for script generation.
When `true`, the flow proceeds straight from `generating_script` to `segmenting`. When `false`, it stops at `pending_approval` until you call the `/approve` endpoint.
Convex ID of the avatar to render. Defaults to the first ready 16:9 avatar in your workspace.
ElevenLabs voice ID. Defaults to the workspace's configured voice.
Prospect's first name. Used in the script's greeting.
Prospect's company name.
Sender's name. Defaults to the API key's owner.
Sender's company. Defaults to the workspace name.
Video title shown in the dashboard. Auto-generated from the prospect name when omitted.
### Response
`true` on accepted requests.
Convex ID. Use this to poll status, approve, or cancel.
Always `pending` for newly created flows.
Human-readable confirmation.
```bash cURL theme={null}
curl -X POST https://app.yuzulabs.io/api/v1/flows/sales-email-video \
-H "Authorization: Bearer yzlk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{
"emailContent": "Great call with John from Acme Corp today. We discussed video marketing pain points: production time, brand consistency, scaling content. Next step: send a product demo.",
"autoApproveScript": true,
"prospectName": "John",
"prospectCompany": "Acme Corp"
}'
```
```ts TypeScript theme={null}
const res = await fetch("https://app.yuzulabs.io/api/v1/flows/sales-email-video", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.YUZU_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
emailContent: "Great call with John from Acme Corp today...",
autoApproveScript: true,
prospectName: "John",
prospectCompany: "Acme Corp",
}),
});
const { flowId } = await res.json();
```
```python Python theme={null}
import os, requests
res = requests.post(
"https://app.yuzulabs.io/api/v1/flows/sales-email-video",
headers={"Authorization": f"Bearer {os.environ['YUZU_API_KEY']}"},
json={
"emailContent": "Great call with John from Acme Corp today...",
"autoApproveScript": True,
"prospectName": "John",
"prospectCompany": "Acme Corp",
},
)
flow_id = res.json()["flowId"]
```
```json 200 OK theme={null}
{
"success": true,
"flowId": "k97x3n2m4p5q6r7s",
"status": "pending",
"message": "Flow created successfully"
}
```
```json 400 Validation error theme={null}
{
"success": false,
"error": "Email content must be at least 50 words",
"code": "VALIDATION_ERROR"
}
```
```json 429 Quota exceeded theme={null}
{
"success": false,
"error": "Video quota exceeded",
"code": "QUOTA_EXCEEDED"
}
```
***
## `GET` List flows
`GET /v1/flows/sales-email-video`
Returns flows visible to the API key, most recent first. Useful for dashboards and reconciliation jobs.
### Query parameters
Page size. Maximum 100.
Continuation cursor from a previous response.
Filter by a single status (e.g. `completed`, `pending_approval`).
### Response
Array of flow summaries. Each entry contains `flowId`, `status`, `createdAt`, `title`, and `videoUrl` (when completed).
Present when more results are available.
```bash cURL theme={null}
curl "https://app.yuzulabs.io/api/v1/flows/sales-email-video?limit=20&status=completed" \
-H "Authorization: Bearer yzlk_your_api_key_here"
```
```json 200 OK theme={null}
{
"success": true,
"flows": [
{
"flowId": "k97x3n2m4p5q6r7s",
"status": "completed",
"createdAt": "2026-01-22T10:30:00Z",
"title": "Acme Corp follow-up",
"videoUrl": "https://assets.yuzulabs.io/videos/k97x3n2m4p5q6r7s.mp4"
}
],
"nextCursor": null
}
```
***
## `GET` Get flow
`GET /v1/flows/sales-email-video/{flowId}`
Returns the current status of a single flow. Poll this every few seconds while the flow is in progress.
### Path parameters
The flow ID returned from the create endpoint.
### Response
One of the lifecycle states above.
ISO-8601 timestamp.
ISO-8601 timestamp. Only present once `status` is `completed`.
Direct CDN URL to the rendered MP4. Only present once `status` is `completed`.
Duration in seconds.
Final script. Available from `pending_approval` onwards.
Per-scene breakdown: `index`, `text`, `durationEstimate`. Available from `segmenting` onwards.
Failure reason. Only present when `status` is `failed`.
```bash cURL theme={null}
curl https://app.yuzulabs.io/api/v1/flows/sales-email-video/k97x3n2m4p5q6r7s \
-H "Authorization: Bearer yzlk_your_api_key_here"
```
```ts TypeScript theme={null}
const res = await fetch(
`https://app.yuzulabs.io/api/v1/flows/sales-email-video/${flowId}`,
{ headers: { Authorization: `Bearer ${process.env.YUZU_API_KEY}` } },
);
const flow = await res.json();
```
```json 200 OK (completed) theme={null}
{
"flowId": "k97x3n2m4p5q6r7s",
"status": "completed",
"createdAt": "2026-01-22T10:30:00Z",
"completedAt": "2026-01-22T10:38:00Z",
"videoUrl": "https://assets.yuzulabs.io/videos/k97x3n2m4p5q6r7s.mp4",
"videoDuration": 65.2,
"generatedScript": "Hey John, great speaking with you today...",
"scenes": [
{ "index": 0, "text": "Hey John...", "durationEstimate": 12.5 },
{ "index": 1, "text": "I understand you're facing...", "durationEstimate": 15.0 }
]
}
```
```json 200 OK (in progress) theme={null}
{
"flowId": "k97x3n2m4p5q6r7s",
"status": "voice_generating",
"createdAt": "2026-01-22T10:30:00Z",
"generatedScript": "Hey John, great speaking with you today..."
}
```
```json 404 Not found theme={null}
{
"success": false,
"error": "Flow not found",
"code": "FLOW_NOT_FOUND"
}
```
***
## `POST` Approve, edit, or reject script
`POST /v1/flows/sales-email-video/{flowId}/approve`
Only valid while the flow is in `pending_approval`. Use it to advance, edit, or kill a draft script.
### Path parameters
### Body parameters
Either `"approve"` or `"reject"`.
Replacement script. Honored only when `action: "approve"`. If omitted, the draft script proceeds unchanged.
### Response
After approval, transitions to `segmenting`. After rejection, transitions to `cancelled`.
```bash Approve as-is theme={null}
curl -X POST https://app.yuzulabs.io/api/v1/flows/sales-email-video/k97x3n2m4p5q6r7s/approve \
-H "Authorization: Bearer yzlk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{"action": "approve"}'
```
```bash Approve with edits theme={null}
curl -X POST https://app.yuzulabs.io/api/v1/flows/sales-email-video/k97x3n2m4p5q6r7s/approve \
-H "Authorization: Bearer yzlk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{
"action": "approve",
"editedScript": "Hey John, picking up where we left off..."
}'
```
```bash Reject theme={null}
curl -X POST https://app.yuzulabs.io/api/v1/flows/sales-email-video/k97x3n2m4p5q6r7s/approve \
-H "Authorization: Bearer yzlk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{"action": "reject"}'
```
```json 200 OK theme={null}
{
"success": true,
"flowId": "k97x3n2m4p5q6r7s",
"status": "segmenting"
}
```
```json 400 Wrong state theme={null}
{
"success": false,
"error": "Flow is not awaiting approval (current status: video_generating)",
"code": "VALIDATION_ERROR"
}
```
***
## `DELETE` Cancel flow
`DELETE /v1/flows/sales-email-video/{flowId}`
Cancels a flow in any non-terminal state. Already-rendered videos are kept; in-flight rendering is aborted.
### Path parameters
### Response
Always `cancelled` on success.
```bash cURL theme={null}
curl -X DELETE https://app.yuzulabs.io/api/v1/flows/sales-email-video/k97x3n2m4p5q6r7s \
-H "Authorization: Bearer yzlk_your_api_key_here"
```
```json 200 OK theme={null}
{
"success": true,
"flowId": "k97x3n2m4p5q6r7s",
"status": "cancelled"
}
```
# Changelog
Source: https://docs.yuzulabs.io/changelog
Product updates and announcements.
## Deal pages now start with a brief
Deal pages can now show a timestamped brief above next actions. The brief summarizes where the account stands, why the signal matters, and which move should happen next.
Under the hood, Yuzu now keeps a per-deal account memory layer. That memory gives Zu and the deal agent a stable view of the account instead of forcing every run to rebuild the story from raw events.
## Next actions follow the path to close
The deal agent no longer treats the buyer package as the answer to every event. The TLDR, business-case page, and follow-up email still stay available when a deal has buyer-package work. The next action now focuses on the concrete step that moves the deal forward.
For stalled deals, that usually means one final check-in email instead of an empty action list. For active deals, it means the action should point at the current path-to-close step.
## Slack can review and send work
Slack notifications now carry more of the finished package: the video, business-case link, and email. Sellers can review, edit, and send an email from a Slack modal, use a compose shortcut, or save the message as a Gmail draft.
Slack request verification now fails closed, and review actions check draft ownership before changing or sending work.
## Native meeting capture is connected
The native Yuzu Notetaker can now connect to a workspace and sync completed calls back into Yuzu. This gives teams another path for meetings that are not coming from Fireflies, Fathom, Granola, HubSpot, or Zapier.
### Fixes and polish
* Email drafting moved to Claude Opus 4.8 with a value-led prompt and less brittle greeting logic.
* TLDR narration tempo was restored and segmentation budgets now scale toward the target duration.
* LinkedIn hosted auth requires the expected webhook secret and owner checks.
* Tempo Sandbox seed tooling gives the team a safe account for docs screenshots and product demos.
* The public landing surfaces were cleaned up with new segment and use-case pages, product demos, and current-brand typography.
## Deal views respect type and owner
Deal lists, pipeline views, and detail pages now handle customer, investor, internal, partner, hiring, and other work more consistently. Counts are scoped to the current view, type fallbacks are safer on older rows, and member views stay limited to records the user is allowed to see.
The sidebar also has an **Other** route for work that should not be forced into the customer pipeline.
## Zu can answer from Slack and Telegram
Zu can now receive inbound chat from external channels, route it to the mentioned workspace, and reply with the workspace scope visible. Slack replies are formatted for the channel instead of looking like raw app text.
This is useful for quick questions such as "what changed on this account?" without making the seller open Yuzu first. When Zu creates work, the real review surface still lives in Yuzu or the connected approval flow.
## Backfills and enrichment are safer
LinkedIn enrichment, company enrichment, and PredictLeads ingestion now use stricter matching and bounded scans. Fathom polling was added, historical reviewed deal backfills are safer, and orphan transcript recovery avoids turning old calls into broken or duplicate work.
### Fixes and polish
* Customer and deal visibility no longer depends on broad workspace reads that can hit Convex limits.
* LinkedIn matching now requires stronger company/profile evidence before attaching a person.
* PredictLeads webhook payloads are consumed directly when possible, with quota exhaustion handled safely.
* Buyer inference understands seller title aliases when assigning unassigned calls.
* Deal classification controls and scoped counts have regression coverage.
## Weekly GTM digests
Yuzu can now generate a weekly digest that is easy to skim before pipeline review. It groups active buyer deals into Hot, Get it going, and Stale, with pipeline value, signal, close progress, and links back to the deal or buyer page.
We also added daily and team digest variants: daily for new deals and buyer packages waiting on review, team for a rep-level view of hot and stale opportunities.
## Add external links as deal evidence
Deal pages now let you add an external link from the **Add to deal** menu. Yuzu stores the link, title, and metadata, and pulls readable page text into the deal when the URL is safe to fetch.
This is useful for pricing pages, implementation docs, security questionnaires, buyer requirements, and other material that should inform the next action.
## Company and people enrichment
Yuzu can now enrich companies and people from LinkedIn and company-signal sources with stricter matching. The enrichment jobs are gated, paginated, and scoped so large workspaces do not need full-table reads just to keep profiles fresh.
## Buyer-package fixes
We fixed several rough edges in TLDR and business-case generation: stale master business page state, share-side effects, seller-logo thumbnails, image-only TLDR generation, avatar crop ordering, and narration/avatar sync.
### Fixes and polish
* Manual deal creation reuses an existing buyer account for the same domain when possible.
* Merged deals are guarded in dead-letter and ingestion paths so old IDs do not create broken work.
* External link ingestion records page content only after authorization and safe-fetch checks.
* GTM digest currency formatting is easier to scan for million-dollar pipeline values.
* Product-shot collections marked as archived are excluded from agent visual selection.
## Home shows the work that needs action
Home now pulls real next actions into the main workspace view. Sellers can mark an action done, dismiss it, or jump into the review surface without opening every deal first.
Resolved work is tracked as resolved, dismissed, or platform-completed instead of disappearing without context. Zu can use that resolution history when it decides what should happen next.
## Companies are easier to inspect
People now includes company-level views that group people, deals, and company logos by domain. Yuzu also stores company associations and stats directly so the list can load without expensive per-person or per-deal scans.
Internal, fundraising, customer, and other deal views were split out so founder workflows do not have to pretend every record is a normal customer opportunity.
## Large workspaces are safer
Several reads were rewritten to avoid 16MB Convex read-limit failures on people, deal lists, companies, and deal detail pages. Asset rollups, company stats, and list metadata are denormalized onto the rows that need them so common views do not hydrate the whole workspace just to render a page.
### Fixes and polish
* Auto-archived deals can reactivate when a new call arrives.
* Deal action resolution is visible on Home, deal pages, and Tasks.
* Business-case sharing, seller-logo thumbnails, avatar focus, and product-clip selection were tightened.
* Deal-agent large-deal runs now preserve the analysis instead of truncating useful context.
* ClickHouse system logs were bounded after local infrastructure filled disk with unbounded log tables.
## Calendar is now part of the operating loop
Yuzu can now sync Google Calendar, show meetings in a dedicated Calendar page, create real calendar invites, and let sellers reschedule, cancel, RSVP, join Meet calls, or open events in Google Calendar from the app.
Deal next actions can also open a meeting invite dialog instead of sending the seller to a blank calendar tab. Yuzu pre-fills known deal contacts, creates the invite from the connected Google account, and can clear the scheduling action when it sees an upcoming meeting with the buyer.
## Booking links live in Yuzu
Each seller can create a public booking link, configure working hours, duration, horizon, timezone, and active/paused state, then copy or preview the `/book/[slug]` page. Bookers only see available slots. Before an event is created, Yuzu re-checks live calendar availability so stale slots do not turn into bad invites.
## Tasks separates seller work from deal signal
Tasks is now a real cross-deal work queue. It combines manual personal tasks with Zu-generated approval work, including TLDR review, business-case review, email review, and meeting scheduling. Sellers can switch between board and list views, filter by source or due date, search by task or deal, show done work, and export a CSV.
Manual tasks stay personal and do not retrigger deal reasoning by themselves. Buyer activity still belongs in the deal thread; Tasks is for work waiting on the seller.
### Fixes and polish
* Calendar month navigation syncs the viewed range instead of only relying on a rolling background window.
* Booking links prefer the owner's Google Calendar timezone when available.
* Meeting next actions now create real Google Calendar events with guest invites.
* Task cards from Zu open the actual review surface instead of hiding the underlying work.
* Manual task status can be changed by drag and drop or by a keyboard-accessible status selector.
## A master business page for what you sell
Home can now create a master business page: a shareable overview page and master TLDR generated from your product description plus one real call transcript. Once published, the page gets a readable `/v/[company-firstname]` link instead of a random share code.
This is not the same as a deal-specific business-case page. Use the master page for low-context introductions and general product explanation. Use the buyer package on a deal when Yuzu has enough buyer-specific evidence for a TLDR, business-case page, and follow-up email.
## Investor calls no longer leak into buyer GTM memory
Yuzu now classifies fundraising, investor diligence, board, and capital-raising calls separately from normal buyer deals. Those records can be filtered as **VC / investors** in Deals, and the agent prompt now keeps investor evidence out of ICP, pricing, objections, TLDRs, business-case pages, and buyer follow-up unless the same fact is supported by buyer or customer conversations.
This matters because founder workflows often mix sales, fundraising, partnerships, and internal work in the same meeting tools. Yuzu should preserve the signal without turning every investor call into buyer-facing GTM advice.
## Presenter avatars are photo-based now
The old legacy avatar requirement is no longer the main setup path. Sellers can upload a photo, choose realistic or cartoon style, generate a HeyGen talking photo, and decide whether the presenter appears in TLDR videos. Cartoon avatars use a generated preview first, then build the talking avatar from the approved image.
Master overview videos can also render without requiring a legacy 16:9 avatar, so new workspaces are not blocked from creating a business page before avatar setup is complete.
### Fixes and polish
* Business cases are listed under Studio -> Business cases; old deal-page URLs redirect there.
* The master business page lookup scans the user's master overview flows directly instead of relying on a recent-flow window.
* Deal type filters now include customer, internal, investor, and other work alongside buyer deals.
* Avatar setup is available in onboarding and Brand and voice settings.
## The buyer package is one workflow now
Deal pages now group the standard buyer package into one card instead of scattering TLDR, business-case, and email work across separate actions. Each row has its own state and action: create, generating, needs review, retry, or done. The package footer handles the seller-level send action once the pieces are ready.
This makes the core flow clearer: first review or generate the TLDR, then review the business-case page, then send the short follow-up email. The contextual action next to the package still stays separate, so meeting-specific work like "send Dana the legal packet" does not get mixed into the standard buyer assets.
The card also disables actions while generation is running and shows the in-progress state in place. Sellers should not have to guess whether a click worked, hunt in Studio, or ask Zu to create a draft that should already be attached to the deal.
## Business-case pages replaced the old deal-room links
Business-case pages are now the buyer-facing page for a deal package. The old public timeline-style deal room is no longer the expected share surface. When a seller clicks review from the package, they should land on the generated business-case page or the review surface that creates it.
We also tightened the public page details that made these links feel unreliable: the browser title should only show one Yuzu suffix, share links should point at the business-case page, and generated pages should use the rendered video asset for the deal instead of falling back to onboarding sample media.
## Deal pages use the full working surface
The deal page layout now gives the next-action area more room, so package cards, contextual actions, the close plan, signal, content, and hotlinks can all coexist without forcing the main work into a narrow column.
### Fixes and polish
* Buyer-package actions are deduped so one analysis cannot create multiple TLDR/business-case/email package cards.
* Package rows show generating states and disable buttons while the async work is running.
* Business-case review links route to business-case pages, not stale timeline pages.
* The public business-case title avoids duplicate `| Yuzu` suffixes.
* Won, archived, and lost deals no longer show generation buttons unless there is an existing package asset to review.
## Email review happens where the deal happens
Agent-drafted emails now open from the deal page as reviewable drafts. Sellers can edit recipients, subject, and body, save changes, approve the send, or schedule it without losing the deal context that motivated the draft.
Replies and new sends are treated as conversation threads, not one-off artifacts. When Gmail is connected, Yuzu can persist sent messages, show received replies, backfill relevant history for a person, and attach deal-scoped rows back to the right buyer thread.
## Deals are easier to scan
Deals now have a List/Pipeline switch and a type filter for views like Internal, VC / investors, customer opportunities, and other deal categories. Filters preserve the URL, so a filtered list or pipeline view can be shared or refreshed without losing state.
Deal detail pages also show a short summary and a path-to-close timeline when the agent has enough evidence. Completed steps, the current "now" step, and upcoming steps make the chronology easier to understand than a loose pile of action cards.
### Fixes and polish
* Empty states mention the selected type filter instead of saying "All deals" when the filter is active.
* The pipeline header no longer renders a TLDR generation action with `dealId=pipeline`.
* Soft-deleted deals disappear from active lists and resolve to a safe not-found state from direct URLs.
* Archived deals leave active lists but remain available by direct URL.
* Regenerate buttons coalesce rapid clicks so one double-click does not create duplicate deal-agent traces.
## Master Vault now carries GTM strategy
Master Vault is no longer just a place for notes. Yuzu now maintains strategy documents such as ICP, Sales process, Buying committee patterns, Positioning, Objection playbook, Pricing rules, Win themes, USPs, and Industries when the workspace has enough meeting evidence.
Placeholder docs stay intentionally empty until the source signal exists. That keeps strategy memory auditable: drafted docs should come from actual calls, emails, and deal activity, not from generic startup filler.
## Gmail and LinkedIn are signal sources
Gmail can now power tracked sends, scheduled sends, reply detection, contact backfill, and deal-scoped email threads. LinkedIn can draft, review, publish, schedule, and pull reactions or comments back into Yuzu when Unipile is connected.
Those events are normalized into deal signal so Zu and the deal agent can reason over what happened: who opened, who replied, who engaged, what changed, and which follow-up should be prepared next.
## Content gets judged before it reaches buyers
We expanded model routing and added LLM judge passes for generated content. Drafts can be scored against a rubric, revised with judge feedback, and rejected when the revision does not improve. The goal is not more AI copy; it is fewer generic, ungrounded, or buyer-unsafe artifacts reaching the review queue.
### Fixes and polish
* Gmail Connect opens the Clerk account connection flow instead of falling through to a sign-in redirect.
* LinkedIn settings now speaks in user-facing LinkedIn language instead of exposing Unipile implementation details.
* People records can be created from transcript email data and can infer deal relationships from sent or received email rows.
* The onboarding demo TLDR asset is self-hosted under `/onboarding/` instead of depending on staging asset storage.
## Schedule seller-reviewed sends
Email drafts and LinkedIn posts can now be scheduled after review. Sellers can edit the copy, choose a future time, and leave the asset in draft until Yuzu's scheduled worker sends the email or posts to LinkedIn from the connected account.
Scheduling uses the same approval-first workflow as send-now actions. The seller still reviews the draft before it leaves the workspace, and scheduled metadata is cleared if the schedule is canceled or the send completes.
## Granola can sync all available notes
Granola imports now support an all-time sync from notetaker settings. Use it when a workspace connects Granola after several customer calls already happened and needs those notes pulled into Yuzu.
## Older transcripts stay safer by default
Historical transcripts imported outside the recent-meeting window are preserved and searchable, but Yuzu does not automatically create new deal records for every old meeting. Assign those calls manually when they belong to an active opportunity, or use recent transcript recovery when you want the current deal-agent package on meetings from the last few days.
### Fixes and polish
* Deal assets now open in the in-context editor for review, approval, scheduling, and link copying before sending sellers into Studio.
* Business-case links are labeled as business-case links, not old deal-room links.
* Email and LinkedIn schedule/cancel behavior now has smoke-test coverage.
## Every deal gets the buyer package
Next actions now treat the TLDR and business-case page as the standard buyer package, not optional model suggestions. When a transcript or deal signal comes in, Zu keeps those buyer-facing artifacts visible alongside one contextual move, usually an email or LinkedIn action when the record gives it a clear reason.
A card is not the same thing as a render job. New TLDR generation still runs through transcript intake or an explicit click, with source-meeting dedupe in place. The difference is that the seller no longer has to wonder whether the right follow-up is hidden in Studio, missing from the action list, or waiting for a later agent run.
## Email review moved back into the deal
Agent-drafted emails can now be opened from the next-action card. Sellers can edit the recipient, subject, and body before sending, without leaving the deal context. Business-case actions also include a **Draft send email** option, so Zu can prepare the short note that shares the TLDR and business case with the buyer.
Replies and sent emails are no longer treated as detached Studio artifacts. Deal and people pages can use Gmail history to show the conversation thread, and people can infer related deals from sent or received email rows.
## Contacts and older meetings are easier to recover
When a transcript includes a buyer email, Yuzu can create the primary contact automatically instead of forcing the seller to re-enter the same person. People pages also show deal relationships inferred from email history, so a contact added from Gmail does not look disconnected from the active deal.
We also added a backfill path for recent completed transcripts. Teams can queue the deal agent across the last few days of meetings so older calls receive the same current next-action package without waiting for another buyer event.
### Fixes and polish
* **Mark done** now completes the specific action you clicked, not just the first action in the list.
* **Copy share link** now writes the deal link to the clipboard instead of silently doing nothing.
* Business-case next-action buttons route to the deal-page review surface instead of falling through to TLDR generation.
* Legacy and internal action types are normalized into email drafts, because email is the usable surface for seller requests and internal follow-up.
## The workspace now starts from the deal
We rebuilt the core app around the seller's real operating loop: buyer conversations, next actions, evidence, and shareable follow-up artifacts.
Deal pages now show the current signal, the next moves Zu recommends, previous completed actions, contacts, deal-specific emails, hotlinks, and buyer-facing content in one thread. The goal is simple: open a deal and see what changed, what matters, and what to do next.
## Zu is now part of the product
Zu is the workspace chat agent. It can answer questions from the current route, inspect deals, pull contacts, create or update artifacts, read uploaded attachments through searchable chunks, and keep notes in the Master Vault.
The new **Zu's notes** document is system-owned. Humans can read it, inspect the version rail, and use it as a memory surface, but direct edits are locked so the agent's workspace memory stays auditable.
Admins also get an agent observability page with recent deal-agent, master-agent, and chat-agent runs, including model, tokens, cost, tool calls, and compaction activity.
## Gmail is a source of signal now
Yuzu can connect to Gmail with `gmail.send` and `gmail.readonly`. People pages can backfill relevant conversation history for a contact, deal pages can show deal-scoped email threads, and replies sent from Yuzu are persisted back into the app.
Email is still seller-controlled. If email autopilot is off, agent-drafted sends wait in an approval queue. If it is on, the same draft and tracking path can send directly from the connected mailbox.
## LinkedIn posts and engagement connect back to deals
LinkedIn is now an outbound channel and engagement source. Yuzu can draft posts, route them through approval when autopilot is off, publish from the connected profile, and pull reactions or comments back into the workspace.
When a LinkedIn actor matches a saved person profile, Yuzu can connect that engagement to the right buyer thread instead of treating social activity as a disconnected vanity metric.
## Better models, better judgment, fewer sloppy drafts
We upgraded the model registry across agents and content generation. Deep deal and chat work now uses Claude Opus where the task needs longer reasoning, Sonnet handles high-volume generation and summarization, and Haiku handles cheap classification-style work.
We also added LLM judge passes for generated content. Drafts can be scored against a rubric, revised once using judge feedback, and rejected when the revision does not improve. This gives Yuzu a stronger quality gate before buyer-facing copy becomes an email, LinkedIn post, or business-case asset.
## Smaller things that matter
* Deal next actions can be regenerated from the deal page and coalesce rapid clicks into one agent run.
* Public business-case pages are now the primary buyer page, not the old timeline-style deal room.
* Business-case pages support video-first layouts, theater mode, picture-in-picture behavior, transcript copy, and CTA mailto actions.
* Product assets can be added as reusable buyer-facing material for business-case pages.
* Public link and rendered-video engagement feeds into deal engagement events for downstream signal.
* Chat is hidden on public routes and only mounts inside authenticated workspace routes.
## One route for customer work
Deals, unassigned calls, Library cards, and video pages now point back to the same customer thread. If a call is not assigned yet, it opens as a temporary call page inside Deals instead of jumping to a raw transcript.
Public Yuzu Links remain shareable buyer links. Internal deal pages remain the workspace view for calls, videos, drafts, quotes, and search.
## Notetaker fanout is deduped
We tightened notetaker ownership so one provider meeting becomes one canonical transcript. If Yuzu cannot match the call to a workspace member, the transcript stays with the admin/integration owner until an admin assigns it.
Autopilot is also idempotent per source meeting, so duplicate webhooks or integration fanout do not create repeated recap videos or burn quota twice.
## Safer background work
Search, analytics, pattern clustering, completed-video visibility, and KB reindexing now use bounded, recoverable queues and indexes. The goal is boring: new data should show up without duplicate jobs, stalled drains, or workspace-scale scans.
## Cmd-K can answer questions now
Search is no longer only a list of matching records. Ask a question like "who did I talk to recently?" or "who asked for security review?" and Yuzu gathers evidence from calls, insights, analytics, and recent transcript context.
Answers include citations so you can open the source instead of trusting a summary.
## Intelligence is a real workspace now
The old async insights page has been replaced with a full Intelligence section: KPIs, patterns, quotes, case-study candidates, and content ideas. KPIs are powered by call, video, link, insight, and team-coverage data. Patterns and content suggestions will keep getting sharper as more call data is indexed.
## Under the hood
We added full-call vector search, insight vector search, Typesense search docs, ClickHouse analytics facts, and coalesced sync queues so new call activity updates search and analytics without creating duplicate background work.
## Calls now roll up into deals
Yuzu now groups calls, TLDR videos, public links, email draft suggestions, and insights into buyer deal threads. When a notetaker or integration provides clean metadata, grouping happens automatically.
When the source is messy, the call stays visible as unassigned. You can assign or merge it later. Merge is a grouping action; it does not delete the original calls, videos, links, or drafts.
## Deal pages carry context forward
Recap generation can use previous calls from the same deal, not only the current transcript. Deal pages also include searchable call moments, so you can ask where a buyer mentioned a feature, objection, or next step.
## Email drafts are suggestions
Yuzu can draft follow-up emails from call and deal context. It does not access your inbox or send email for you. Review the draft, edit it, and send it from your own email client.
## The app now speaks Yuzu
We rebuilt the app shell around the new brand system: Fraunces headlines, warmer surfaces, yuzu yellow, ink, leaf, and a much clearer navigation model.
Home is now a GTM signal board instead of a generic dashboard. It shows what needs review, what happened recently, whether autopilot is on, and which customer language is worth paying attention to.
## Video creation got more personal
We added thumbnail customization, cloned voice support across supported videos, better public video pages, and a cleaner approval flow. Public pages can now show moments and chapters, including useful non-sales-call videos.
## Dark theme, onboarding, and the new site
Dark theme is now first-class, onboarding guides new workspaces through brand and voice setup, and the public website has been updated around the same "Just keep talking" product story.
## New workspace onboarding
New workspaces now get a guided setup flow for brand details, voice selection, notetaker setup, and a first TLDR preview. You can also replay onboarding from settings when you want to refresh setup choices with your team.
## Better shared video pages
Public video pages now support richer business case content, editable business case copy, FAQs, restored analytics breakdowns, and personalized video thumbnails. Shared videos also stay visible while processing, so links do not feel broken during generation.
## Voice and notetaker improvements
You can create cloned voices, choose them in video flows, and manage them from avatar admin. Notetaker setup now includes Circleback, organization-scoped Ergo and Circleback connections, safer webhook handling, and automatic transcript sharing for new team members.
### Fixes and polish
* Preserved automation flow creators during processing.
* Improved classification recovery without abandoning existing rows.
* Tightened organization routing during sign-in and onboarding.
* Cleaned up video UI hook dependencies and onboarding preview transitions.
* Introduced this documentation site, replacing scattered internal notes.
* Published the **Sales Email Video Flow API** reference.
* Added **Integrations** section starting with notetakers (Fireflies, Granola, Fathom).
# Welcome to Yuzu
Source: https://docs.yuzulabs.io/index
Turn sales calls into TLDR videos, deal intelligence, search, and follow-up work.
Yuzu turns sales calls into TLDR videos, deal intelligence, search, and follow-up work. Connect a notetaker, Gmail, LinkedIn, or call the API; Yuzu keeps the conversation useful after the meeting ends.
This site documents three things:
* **Product**: how Home, Zu, Videos, Deals, People, Master Vault, Intelligence, Search, and Library work.
* **Integrations**: how to connect notetakers, Gmail, LinkedIn, CRMs, and other tools so signal keeps flowing.
* **API**: how to drive Yuzu programmatically from your own systems.
Create your first TLDR video from the dashboard.
Learn how calls, videos, emails, LinkedIn engagement, and insights roll up into buyer deal threads.
Ask about deals, draft work, and search workspace context.
Use Cmd-K to search records or ask questions across calls and insights.
Read the GTM signal layer: KPIs, patterns, quotes, and suggested work.
Endpoints, authentication, scopes, error codes.
Connect Gmail, LinkedIn, notetakers, HubSpot, and more.
Recent product updates and announcements.
# Google Calendar
Source: https://docs.yuzulabs.io/integrations/calendar
Connect Google Calendar so Yuzu can sync meetings, create invites, and power booking links.
Google Calendar lets Yuzu work with meetings as real calendar events instead of loose notes. It powers the Calendar page, meeting next actions, RSVP changes, rescheduling, cancellation, and personal booking links.
## What it enables
With Google Calendar connected, Yuzu can:
* Sync your primary calendar into the Calendar page.
* Create events and invite guests.
* Reschedule or cancel events from Yuzu.
* RSVP to events.
* Create deal meeting invites from next-action cards.
* Offer a public booking link based on your working hours and live availability.
* Use scheduled meetings as deal signal when they are tied to a buyer thread.
## Connect Google Calendar
Open **Settings -> Integrations** or **Settings -> Email** and connect Google. If your current Google connection only has Gmail access, reconnect or add permissions so Calendar access is granted.
When the connection is ready, Yuzu provisions a calendar sync channel when possible and falls back to polling when Google cannot create the webhook channel.
## Sync behavior
Yuzu syncs calendar events in three ways:
* **Initial sync** after the Calendar permission is available.
* **On-demand range sync** when you navigate to a month on the Calendar page.
* **Background refresh** through Google webhook notifications or scheduled polling.
The Calendar page is quiet for users who have not granted Calendar access. It returns an empty range instead of throwing errors on every navigation.
## Booking-link availability
Booking links use the link owner's calendar, not the booker's calendar. The public booking page reads the configured working hours, lists available slots, then re-validates the selected slot against live availability before creating the invite.
Current booking availability checks the owner's primary calendar. Secondary calendars are not fully covered yet because that requires broader calendar-list access.
Booking links re-check availability before insert, but they do not hold a temporary reservation while a booker is filling the form. If two people choose the same low-volume slot at the same time, one booking may need to be retried after the calendar rejects or conflicts.
## Privacy
Yuzu uses calendar data to show the signed-in user's meetings and to create events the user explicitly sends. Calendar events do not become public buyer pages. Only the booking page for an active link is public, and it exposes available slots, not the rest of the owner's calendar.
## Troubleshooting
If Calendar is empty:
* Confirm the Google account is connected with Calendar access, not only Gmail.
* Move to the month you expect to see. Yuzu syncs the viewed range on navigation.
* Check whether the event is on the primary calendar. Secondary-calendar coverage is limited.
If a deal scheduling card is still visible after you sent an invite, refresh the deal page. Yuzu should resolve the action when it sees an upcoming meeting with one of the deal contacts.
# Attio
Source: https://docs.yuzulabs.io/integrations/crm/attio
Connect Attio via OAuth — sync companies, people, deals, tasks, notes, meetings, and email activity.
Attio is a CRM and activity source for Yuzu. When connected, Yuzu imports CRM records and keeps Attio email and meeting activity visible on the relevant deal and people pages.
**Auth method:** OAuth 2.0.
## Prerequisites
* An Attio workspace.
* Permission to install OAuth apps in that workspace.
* A Yuzu workspace admin account.
## Setup
Go to **Settings → Integrations** and choose **Attio**.
Attio opens an OAuth consent screen. Pick the workspace you want Yuzu to access and approve the requested scopes.
Yuzu stores the OAuth token, identifies the Attio workspace, and starts an initial background sync.
Yuzu creates an Attio webhook when the server has webhook configuration available. If webhook setup fails, the connection still works and you can run a manual sync.
## What gets pulled
Yuzu imports:
* Companies into buyer accounts.
* Deals into Yuzu deals, including stage, amount, owner, close date, and Attio URL when available.
* People into deal contacts when an email address is available.
* Tasks into deal tasks.
* Notes into deal events or relationship activity.
* Attio interaction attributes as email or meeting activity.
* Meetings and call recordings when Attio exposes them for the connected workspace.
## Email source labels
Attio email interactions are shown with an **Attio** source label on deal and people email views. These rows are imported activity copies, not replyable Gmail messages.
When Gmail is connected for the same seller, Yuzu backfills Gmail for deal contacts and suppresses duplicate Attio copies when the Gmail message matches the same subject, participant, and time window. Gmail remains the preferred source because it can open the full thread and send replies.
## Sync behavior
Attio supports webhooks for real-time changes. Yuzu verifies Attio webhook signatures and schedules a sync for the connected workspace.
Manual sync is also available from the Attio integration card for backfills or webhook recovery. Backfills page through Attio records and update existing Yuzu records rather than creating duplicates.
## Troubleshooting
Click **Sync** on the Attio card in **Settings → Integrations**. If the sync completes with zero records, confirm the connected Attio user can view the companies, people, deals, and activities you expect.
Attio activity is a CRM copy. To show the replyable Gmail thread, connect Gmail for the seller, then open the deal or person email view and click **Sync Gmail** or **Backfill from Gmail**.
The OAuth connection can still sync manually. Check that the deployment has Attio webhook configuration and that the public webhook URL is reachable over HTTPS.
# HubSpot
Source: https://docs.yuzulabs.io/integrations/crm/hubspot
Connect HubSpot via OAuth — pull meeting transcripts and call recordings from your CRM.
HubSpot does double duty in Yuzu: it's both a **notetaker source** (call recordings and meeting transcripts logged on contacts) and a **CRM destination** (videos can be attached to deals and contacts as engagements). This page covers the connection itself.
**Auth method:** OAuth 2.0.
## Prerequisites
* A HubSpot account on a plan that exposes the API (Starter, Professional, or Enterprise).
* Permission to install third-party apps on your HubSpot portal.
* HubSpot Sales or HubSpot Service with call recording / meeting transcripts enabled if you want those imported.
## OAuth scopes
Yuzu requests these scopes during the OAuth flow:
* `oauth` — required for all OAuth flows.
* `crm.objects.contacts.read` — to look up contacts associated with calls.
* `crm.objects.owners.read` — to map HubSpot owners to Yuzu users.
Workspace admins can override this scope list via the `HUBSPOT_SCOPES` environment variable on the Yuzu deployment, but the defaults cover the standard sales recap workflow.
## Setup
Go to **Settings → Integrations**, click **Connect Notetaker**, and choose **HubSpot**.
HubSpot redirects you to a consent screen listing the scopes above. Pick the HubSpot account/portal you want to connect and click **Connect app**.
HubSpot redirects you back to Yuzu's settings page. The HubSpot row now shows your **Hub ID** and a **Connected** badge.
Click **Sync Meetings** and pick **Last 7 days**, **Last 2 weeks**, or **Last 4 weeks** to backfill HubSpot calls and meetings into Yuzu. A 7-day sync also kicks off automatically right after you connect.
## What gets pulled
For each HubSpot call/meeting Yuzu has access to:
* The transcript (if HubSpot transcribed the call).
* The recording URL.
* Title, date, duration, organizer, and attendee emails.
* The associated HubSpot contacts and owner.
Sales calls are eligible to trigger a recap video based on your automation rules.
## Disconnecting
There are two layers to disconnect:
1. **In Yuzu** — click **Disconnect HubSpot** in the integrations row. This revokes the refresh token on HubSpot's side and stops Yuzu from pulling new data.
2. **In HubSpot** — to fully remove the Yuzu app, go to **HubSpot Settings → Integrations → Connected Apps** and uninstall it. This is a HubSpot limitation: revoking the refresh token does not uninstall the app.
Until you uninstall the app in HubSpot, the Yuzu listing remains visible under Connected Apps even after you disconnect inside Yuzu.
## Token refresh
HubSpot access tokens expire every 30 minutes. Yuzu automatically refreshes them using the stored refresh token before each API call, so you should never need to re-authorize unless you explicitly disconnect.
## Troubleshooting
The most common cause is your HubSpot user not having permission to install third-party apps. Ask a HubSpot super admin to install Yuzu, or have them grant you the **Account Access > Edit account integrations** permission.
Open **Settings → Integrations → HubSpot** and click **Sync Meetings → Last 7 days**. If the sync completes with zero imports, your HubSpot account may not have any transcribed calls or logged meetings in that window.
HubSpot only generates transcripts for calls placed through HubSpot's calling system on supported plans. External calls logged manually won't have transcripts. Check the call record in HubSpot — if no transcript shows there, none will reach Yuzu.
The Yuzu UI status reflects the local integration record. If you reconnect, Yuzu reuses the same `notetaker_integrations` row. To wipe the connection completely, disconnect in Yuzu and uninstall the app in HubSpot under **Settings → Integrations → Connected Apps**.
# Gmail
Source: https://docs.yuzulabs.io/integrations/gmail
Connect Gmail so Yuzu can send tracked email, backfill contact history, and detect buyer replies.
Gmail turns email into a first-class Yuzu signal source.
## What Gmail enables
When Gmail is connected, Yuzu can:
* Send tracked email from the seller's mailbox.
* Schedule reviewed email drafts to send later.
* Persist outbound replies back into Yuzu threads.
* Open deal-native email review for generated follow-up drafts.
* Backfill historical conversations for a person.
* Backfill deal contact conversations when a deal arrives from a CRM integration.
* Detect inbound replies and attach them to the right thread.
* Count opens and clicks for tracked sends.
* Queue agent-drafted sends for approval when email autopilot is off.
## Required scopes
Yuzu checks for two Google scopes:
* `gmail.send`: required to send email from the connected mailbox.
* `gmail.readonly`: required for backfill, thread reads, and inbound sync.
If either badge is missing on **Settings → Email**, update Google access from the connection card.
## People backfill
On a person's **Emails** tab, Yuzu can search Gmail for existing messages to or from that person's email address. Backfill is deduped by Gmail message ID and scoped to the signed-in user.
Backfilled messages can also help Yuzu infer deal relationships when the same email address appears on a deal. That keeps a person added from Gmail from looking disconnected from the buyer work already happening in Yuzu.
## Deal emails
Deal pages show deal-scoped email threads: emails Yuzu sent for that deal, replies linked back to the same deal, and Gmail messages found for the deal's contacts.
If Monaco or Attio has already imported email activity for the deal, those rows show as source-labeled copies. Gmail rows show the **Gmail** source label and are preferred because they can open the full thread and send replies. When the same email exists in Gmail and in Monaco or Attio, Yuzu suppresses the provider copy so the deal page does not show duplicates.
Deal email drafts open in the same review surface as package and next-action emails. Sellers can edit the recipients, subject, and body, then send or schedule without leaving the deal.
## Approval queue
When email autopilot is off, agent-drafted sends wait for human approval. Review the draft, approve it, or discard it.
The approval queue is a fallback and admin surface. The primary review path for deal-generated email is the deal page or the people thread that created the draft.
## Scheduled sends
Scheduled sends use the same Gmail connection as immediate sends. Yuzu stores the requested send time on the draft, then a scheduled worker sends from the connected mailbox and records the Gmail message ID on the sent email row.
If the Google token is missing or the `gmail.send` scope is unavailable when the scheduled time arrives, Yuzu keeps the draft and records the error so the seller can reconnect Gmail and schedule again.
Gmail does not make one user's mailbox visible to every teammate. Email enrichment is scoped to the connected user.
# LinkedIn
Source: https://docs.yuzulabs.io/integrations/linkedin
Connect LinkedIn so Yuzu can draft posts, publish approved posts, and bring engagement back into deals.
LinkedIn is both an outbound channel and an engagement source for Yuzu.
## What LinkedIn enables
When LinkedIn is connected, Yuzu can:
* Draft posts from deal context, calls, and generated assets.
* Show posts in Studio for editing and approval.
* Show post previews with profile identity, headline, media, reactions, and comments.
* Publish approved posts from the connected profile.
* Schedule reviewed posts to publish later.
* Store the live post URL.
* Pull reactions and comments back into Yuzu.
* Match engaged actors to saved People records when their profile URL matches.
## Connection status
Open **Settings → LinkedIn** to check whether a profile is connected. The page shows connection status and an approval queue for agent-drafted posts when LinkedIn autopilot is off.
## Studio workflow
LinkedIn posts live under **Studio → LinkedIn**. A post can include body copy, hashtags, media, status, and live-post metadata once published.
The post detail view is designed to feel closer to LinkedIn itself: the connected profile identity appears with the draft, media attachments render in the preview, reactions can be inspected, and the comment box stays hidden until the seller chooses to comment.
Before publishing, review:
* The post body and tone.
* Any attached image or video.
* Buyer or deal references.
* Whether the post should be edited before it goes live.
## Scheduling
Use **Schedule post** when a LinkedIn draft is ready but should not go live immediately. Yuzu stores the scheduled time on the post and publishes later through the connected LinkedIn profile.
You can clear the schedule while the post is still a draft. After a post is live, delete it from LinkedIn if it should be removed publicly.
## Engagement tracking
After publishing, Yuzu can ingest reactions and comments. Engagement becomes more useful when People records include LinkedIn profile URLs, because Yuzu can tell when a buyer or stakeholder interacted with a post.
That engagement can then appear in activity feeds and contribute to deal signal.
If the actor's LinkedIn profile URL matches a person on a deal, Yuzu can treat the event as buyer or stakeholder engagement instead of generic social activity.
# Notetakers
Source: https://docs.yuzulabs.io/integrations/notetakers
Auto-import meeting transcripts and trigger video flows the moment a call wraps.
A notetaker integration listens for completed meetings, pulls the transcript into Yuzu, and (optionally) kicks off a video flow. Each workspace member can connect their own direct provider, and Zapier can bridge anything else alongside those direct sources.
## What you get
* Transcripts arrive in your workspace within a minute of the meeting ending.
* Each completed transcript is classified as a sales call or not.
* Sales calls can auto-trigger a follow-up video — gated by approval rules you set under **Settings → Automations**.
* The activity log under **Settings → Automations** shows every webhook received and what Yuzu did with it.
## Direct providers
Native app. Syncs completed meetings directly into Yuzu.
API key + webhook. Stable.
OAuth. Webhook auto-managed.
API key. Polls Granola and supports all-time sync.
Webhook only. Paste a URL into Ergo.
Webhook automation. Sends notes, action items, and transcripts.
API key. Polls the Monaco API.
OAuth. Pulls call recordings and meeting notes from HubSpot.
Coming soon. Use Zapier today.
Coming soon. Use Zapier today.
## Or bridge anything else
Pipe transcripts from tl;dv, Otter, Grain, or any other app. Map fields in Zapier.
## Approval mode
By default, every sales-call transcript can immediately trigger a video. To require human review:
1. Go to **Settings → Automations**.
2. Toggle **Require script approval** for the connected source.
When enabled, you'll get a Slack DM (if Slack is connected) or an in-app notification with the draft script. The flow only renders after approval.
## Activity log
Every webhook Yuzu receives shows up in **Settings → Automations → Activity log** with the meeting title, classification, and what action was taken. If a meeting didn't generate a video, this is the first place to look.
## Per-user connections inside a workspace
Each workspace member can connect their own direct notetaker source. Multiple teammates can connect the same provider or different providers in the same workspace. Zapier can run alongside direct sources, so teams can also bridge tools that do not have a direct connector yet.
## Ownership and duplicates
Yuzu keeps one canonical transcript for each provider meeting. If an integration sends the same meeting more than once, or if multiple teammates match the attendee list, Yuzu dedupes the meeting and assigns one owner.
If no workspace member can be matched safely, the transcript stays with the admin or integration owner. Admins can assign it later instead of letting duplicates spread across the workspace.
# Circleback
Source: https://docs.yuzulabs.io/integrations/notetakers/circleback
Webhook automation integration for Circleback meeting transcripts.
Circleback sends completed meeting data to Yuzu through an automation webhook. There is no API key to paste into Yuzu; you create a Circleback automation, include the transcript payload, and save the signing secret in Yuzu.
**Auth method:** Webhook URL + optional HMAC signing secret.
## Prerequisites
* A Circleback account with access to **Automations**.
* A Yuzu workspace where the users who should own transcripts are members.
* Admin access to **Settings -> Notetaker** in Yuzu.
## Setup
In your Yuzu workspace, go to **Settings -> Notetaker**, click **Connect Notetaker**, and choose **Circleback**. Yuzu creates the integration and shows a unique webhook URL that looks like `https:///webhooks/notetaker/ntk_`.
In Circleback, open **Automations**, create a new automation, and use **After every meeting** as the trigger.
In **Choose what happens**, select **Send webhook request**.
Copy the webhook URL from Yuzu and paste it into Circleback's **Endpoint** field.
Circleback creates the signing secret for the webhook step. Click **Copy secret** in Circleback, then paste it into the **Signing Secret** field in Yuzu.
If Circleback is already connected in Yuzu, open the Circleback row on **Settings -> Notetaker** and paste the secret into the connected integration's **Signing Secret** field.
In Circleback's **What to include** section, enable **Meeting notes**, **Action items**, and **Transcript**. The transcript toggle is required for TLDR generation.
Click **Send request for most recent meeting** in Circleback. In Yuzu, confirm the webhook is received, then check **I have added the webhook URL to Circleback** and click **Complete Setup**. Return to Circleback and save the automation.
If you skip the signing secret, Yuzu can still receive Circleback webhooks but cannot verify they were sent by Circleback. Add the secret before using the integration in production, and do not share it outside your Yuzu and Circleback admin setup.
## Ownership mapping
Circleback includes attendee names and email addresses in each webhook. Yuzu maps attendee emails to members of the connected workspace and creates a transcript for each matched member. If none of the attendees match a Yuzu workspace member, the transcript is assigned to the user who connected Circleback.
## What gets imported
Circleback sends the full meeting payload in the webhook body, so Yuzu does not need a follow-up API call. Yuzu imports:
* Transcript segments with speaker labels and timestamps.
* Meeting title, duration, creation date, and attendees.
* Circleback notes as the transcript summary.
* Action items as Yuzu action item strings.
* The recording URL as the meeting video URL when Circleback sends `recordingUrl`.
* A source link back to `https://app.circleback.ai/meetings/{meetingId}`.
Circleback does not currently support historical sync in Yuzu. To backfill past meetings, use Circleback's bulk meeting actions to run the saved automation on selected meetings.
## Troubleshooting
Confirm the signing secret in Yuzu matches the secret shown in the Circleback webhook step. Circleback signs requests with the `x-signature` header using HMAC-SHA256 over the raw request body.
Make sure the meeting attendee email in Circleback exactly matches the Yuzu workspace member email. If no attendee email matches, Yuzu assigns the transcript to the integration owner.
Confirm transcripts are included in the Circleback webhook request. Yuzu discards Circleback webhook payloads with no transcript because there is no follow-up API fetch path for Circleback.
# Ergo
Source: https://docs.yuzulabs.io/integrations/notetakers/ergo
Webhook-only integration — paste a URL into your Ergo dashboard.
Ergo pushes the full meeting payload (transcript, summary, action items) to Yuzu via webhook. There's no API key — you just paste a URL and an auth secret.
**Auth method:** Webhook URL + HMAC auth secret.
## Prerequisites
* An Ergo account with permission to configure webhooks under **Meeting → Webhooks**.
## Setup
Go to **Settings → Integrations**, click **Connect Notetaker**, and choose **Ergo**. Yuzu creates the integration immediately and shows you a unique webhook URL.
In the Ergo dashboard, navigate to the **Meeting** section, click the three-dot menu in the top-right corner, and open the **Webhooks** tab.
Copy the URL from Yuzu (it looks like `https:///webhooks/notetaker/ntk_`) and paste it into Ergo's endpoint field.
Ergo will prompt you to generate an auth secret for the webhook. Copy it and paste it into the **Webhook Secret** field in the Yuzu dialog. Yuzu uses this secret to verify every incoming Ergo webhook.
The integration becomes active once you confirm the webhook is in place.
If you skip the auth secret, Yuzu will still receive Ergo webhooks but won't be able to verify they came from Ergo. Add the secret as soon as you have it.
## What gets pulled
Ergo sends the entire meeting payload in the webhook body, so Yuzu doesn't need to make a follow-up API call. Each `notetaker.meeting.completed` event includes:
* The transcript array with `speaker`, `text`, and `timestamp`.
* Title, attendees, duration, recording URL.
* Summary and action items if Ergo generated them.
* A no-show flag (Yuzu skips no-show meetings).
Ergo does not currently support historical sync.
## Ownership and fanout
Ergo meetings can include several internal teammates. Yuzu still stores one canonical transcript per Ergo meeting ID.
When attendee metadata matches a workspace member, that member becomes the transcript owner. If coverage rules are configured, Yuzu only assigns ownership to covered members. If no safe owner is found, the transcript stays with the admin or integration owner until an admin assigns it.
Repeated webhooks for the same Ergo meeting update or skip the canonical record instead of creating duplicate transcripts or duplicate recap videos.
## Troubleshooting
This usually means the auth secret in Yuzu doesn't match the one in Ergo. Regenerate the secret in Ergo, paste it into Yuzu (**Settings → Integrations → Ergo**), and trigger a test meeting.
Confirm the Yuzu webhook URL in your Ergo dashboard matches the one shown in Yuzu's Ergo row exactly — including the `ntk_…` token. Regenerating the token in Yuzu invalidates the old URL.
They shouldn't. Yuzu drops events flagged with `isNoShow: true` from Ergo. If you see a no-show coming through, check the activity log and report the meeting ID to [support@yuzulabs.io](mailto:support@yuzulabs.io).
# Fathom
Source: https://docs.yuzulabs.io/integrations/notetakers/fathom
Connect Fathom via OAuth — Yuzu provisions and manages the webhook for you.
Fathom uses OAuth. After you authorize, Yuzu provisions a webhook in Fathom's system automatically — there's no URL to copy and paste.
**Auth method:** OAuth 2.0 (`public_api` scope).
## Prerequisites
* A Fathom account with API access enabled.
* Permission to authorize third-party integrations on your Fathom workspace.
* Fathom must be set to record and transcribe the meetings you care about (Zoom, Google Meet, or Microsoft Teams).
## Setup
Go to **Settings → Integrations** and click **Connect Notetaker**, then choose **Fathom**.
Yuzu redirects you to Fathom's OAuth page. Sign in if you aren't already, then approve the `public_api` scope.
Once you authorize, Yuzu creates a webhook in Fathom on your behalf and stores the webhook ID. You return to Yuzu's settings page with Fathom marked as connected.
From the connected state, click **Sync Meetings** and pick **Last 7 days**, **Last 2 weeks**, or **Last 4 weeks** to backfill transcripts. Yuzu also auto-starts a 7-day sync right after you connect.
If you ever need to rotate the connection, click **Regenerate** in the Fathom row of the integrations page. Yuzu deletes the old webhook in Fathom and provisions a new one — no manual reconfiguration needed.
## What gets pulled
For each completed meeting, Yuzu imports:
* The full transcript with diarized segments (`segments[]` with `speaker`, `text`, `start_time`, `end_time`).
* Title, call date, participants, and duration.
* Fathom's summary and action items.
* The recording URL.
Sales calls flow into your automation rules and can trigger a recap video.
## Webhook signature verification
Yuzu verifies every Fathom webhook using the `webhook-id`, `webhook-timestamp`, and `webhook-signature` headers Fathom sends. The HMAC secret is generated by Fathom when the webhook is created and stored on the integration record — you don't need to manage it.
## Troubleshooting
Make sure your Fathom plan includes API access. If it does, try clearing cookies for `fathom.video` and reauthorizing. The error response Fathom sends back is also surfaced in your Yuzu activity log.
Disconnecting in Yuzu deletes the webhook and revokes the integration locally. To remove the Yuzu OAuth grant entirely, go to your Fathom account settings and revoke Yuzu under connected apps.
Check **Settings → Automations → Activity log**. If no entries appear after a recorded meeting completes, click **Regenerate** in the Fathom row of Yuzu Integrations — this re-provisions the webhook.
Fathom labels speakers based on the meeting host's account. External attendees often appear as a single speaker. If pristine diarization matters, prefer Fireflies or HubSpot.
# Fireflies
Source: https://docs.yuzulabs.io/integrations/notetakers/fireflies
Connect Fireflies via API key and webhook to import transcripts the moment meetings end.
Fireflies pushes a webhook to Yuzu when a transcript finishes processing. Yuzu then uses your Fireflies API key to fetch the full transcript, summary, and speaker-labeled segments.
**Auth method:** API key + webhook URL.
## Prerequisites
* A Fireflies account on a plan that exposes the Developer settings (Pro or higher).
* Permission to add a webhook in Fireflies workspace settings.
* Fireflies must be set to record and transcribe the meetings you want in Yuzu.
## Setup
In your Yuzu workspace, go to **Settings → Integrations** and click **Connect Notetaker**, then choose **Fireflies**.
Open [Fireflies Settings → Developer](https://app.fireflies.ai/integrations/api/webhook). Copy the API key shown there.
Yuzu validates the key against the Fireflies GraphQL API before saving it. The email should be the address tied to your Fireflies account.
After Yuzu saves the key, it shows a unique webhook URL of the form `https:///webhooks/notetaker/ntk_`. Copy it.
Back in [Fireflies Settings → Developer](https://app.fireflies.ai/integrations/api/webhook):
1. Paste the URL into the **Webhook URL** field.
2. Choose **Meeting Transcribed** as the trigger event.
3. Save.
Tick the **I have added the webhook URL** box in Yuzu and click **Complete Setup**. Yuzu auto-starts a sync of the last 7 days of meetings in the background.
## What gets pulled
For each completed meeting, Yuzu imports:
* The full transcript with speaker-labeled sentences (Fireflies provides high-quality diarization).
* Title, date, duration, host email, organizer email, and participants.
* The Fireflies-generated summary and action items.
* The transcript URL, audio URL, and video URL.
If the meeting is classified as a sales call, it's eligible to trigger a sales recap video flow based on your automation rules.
## Historical sync
After connecting, you can import past meetings from **Settings → Integrations → Sync Meetings**. Choose 7 days, 2 weeks, or 4 weeks. Existing transcripts are not duplicated.
Fireflies' API does not document a public rate limit, so Yuzu paces fetches with a short delay between requests. A 4-week sync of a heavy user typically completes in a few minutes.
## Troubleshooting
Open the webhook URL row in your Fireflies Developer settings. Make sure the URL starts with `https://` and ends with the `ntk_…` token from Yuzu — a regenerated token in Yuzu invalidates the old one immediately. Trigger a test by recording a short meeting; the activity log under **Settings → Automations** shows webhook arrivals.
The connect dialog tests the key by calling Fireflies' `user` GraphQL query. A failure means either the key is invalid or your Fireflies plan doesn't expose API access. Confirm both, then paste the key again.
Fireflies labels speakers using participant emails on the calendar event. If a meeting was recorded outside your calendar or the participant emails didn't resolve, you may see generic `Speaker 1` / `Speaker 2` labels. This is upstream from Yuzu.
Check **Settings → Automations → Activity log** for that meeting. The most common reasons: the meeting wasn't classified as a sales call, your automation rules excluded it (length, attendees, or pillar), or the workspace is out of video quota.
# Grain
Source: https://docs.yuzulabs.io/integrations/notetakers/grain
Grain direct integration is in beta — connect via Zapier today.
A direct Grain integration is on our roadmap, but the production setup flow isn't yet exposed in the Yuzu UI. In the meantime, Grain recordings and transcripts can flow into Yuzu through Zapier.
**Status:** Beta. Use Zapier as the bridge until the direct integration is generally available.
## Connect Grain via Zapier today
Follow the [Zapier setup guide](/integrations/notetakers/zapier) to connect your Yuzu workspace.
Use Grain's Zapier integration to fire on **New Recording** or **New Story**. Map the transcript and metadata fields to Yuzu's webhook payload.
Record a short Grain meeting. The transcript should appear in Yuzu within a minute of Grain finishing processing.
## Want early access to the direct Grain integration?
Email [support@yuzulabs.io](mailto:support@yuzulabs.io). The direct integration will use OAuth and pull transcripts straight from Grain's API without going through Zapier.
# Granola
Source: https://docs.yuzulabs.io/integrations/notetakers/granola
Connect Granola with a personal API key — Yuzu polls for new notes.
Granola exposes a public API for personal accounts. Yuzu uses your API key to poll for new notes and pulls the transcript, summary, and attendee list for each one. No webhook configuration is needed.
**Auth method:** Personal API key.
## Prerequisites
* A Granola account on the desktop app (the API is exposed there).
* Permission to create a personal API key.
## Setup
Go to **Settings → Integrations**, click **Connect Notetaker**, and choose **Granola**.
Open the Granola desktop app → **Settings → API → Create new key** → select **Personal API**. Copy the key.
Yuzu validates the key against `https://public-api.granola.ai/v1/notes` before saving. Email is optional — the API key already identifies the account.
Once the key validates, Yuzu starts a background sync of the last 7 days of Granola notes. You can also run an all-time import from the notetaker settings. You'll see meetings appear in your transcripts list within a few minutes.
Granola is polling-based, not webhook-based. Yuzu pulls new notes on a schedule, so transcripts may take a few minutes longer to appear than with Fireflies or Fathom.
## What gets pulled
For each Granola note, Yuzu imports:
* The full transcript reconstructed from `transcript[]` entries (microphone vs. speaker labels).
* Title, calendar event metadata (organizer, invitees, start/end time), attendees.
* Granola's `summary_text` and `summary_markdown`.
* Action items where present.
## Historical sync
From the connected state, click **Sync Meetings** and pick **Last 7 days**, **Last 2 weeks**, **Last 4 weeks**, or **All available Granola notes** to backfill notes. Existing notes won't be duplicated.
All-time sync is meant for onboarding an existing Granola account. Older meetings are imported as transcripts and can be searched or assigned, but Yuzu does not automatically create a new deal for every historical meeting.
## Troubleshooting
Granola's API returns 401 for invalid keys. Most often this means the key was created for a workspace that doesn't have personal API access. Recreate the key as **Personal API** in the Granola desktop app and try again.
Granola is polled, so new notes can take a couple of minutes. If a meeting still isn't visible after that, click **Sync Meetings → Last 7 days** or **All available Granola notes** to force a refresh. Check the activity log for any sync errors.
Granola distinguishes microphone (you) from speaker (everyone else) but doesn't label individual external participants. This is expected.
Disconnect and reconnect Granola in Yuzu with the new key. The old key stops working immediately on Granola's side.
# Monaco
Source: https://docs.yuzulabs.io/integrations/notetakers/monaco
Connect Monaco's revenue engine via API key — Yuzu syncs meetings, accounts, opportunities, contacts, tasks, and email drafts.
Monaco exposes meetings and CRM objects through its public API. Yuzu uses your Monaco API key to sync meetings, transcripts, accounts, opportunities, contacts, tasks, and email task drafts into your workspace.
**Auth method:** API key.
## Prerequisites
* A Monaco account with API access.
* Permission to create an API key in your Monaco workspace.
## Setup
Go to **Settings → Integrations**, click **Connect Notetaker**, and choose **Monaco**.
In Monaco, go to **Settings → API Keys → Create new key** and copy the key.
Yuzu validates the key by calling Monaco's API. Email is optional — the API key already identifies the account.
Once the key validates, Yuzu kicks off a 7-day historical sync in the background.
Monaco is polling-based. Yuzu checks connected Monaco accounts every 30
minutes because Monaco does not currently provide webhooks for this
integration.
## What gets pulled
Yuzu imports:
* Accounts into buyer accounts.
* Opportunities into deals, including stage, estimated amount, summary, risks, notes, tags, and custom fields as deal context.
* Contacts into deal contacts when an email is available.
* Tasks into deal tasks.
* Email task drafts into deal email events with a **Monaco** source label.
* Meetings and transcripts, including title, start/end time, organizer, attendees, meeting URL, recording URL, `meeting_summary`, `next_actions`, and diarized transcript segments.
## Email dedupe with Gmail
Monaco email tasks are provider activity copies. If Gmail is connected for the same seller, Yuzu searches Gmail for matching deal-contact conversations and prefers the Gmail thread when the same subject, participant, and time window match. That keeps Gmail replyable while still showing Monaco activity when Gmail does not have the message.
## Historical sync
From the connected state, click **Sync Meetings** and pick **Last 7 days**, **Last 2 weeks**, **Last 4 weeks**, or **All available Monaco data**. Existing records are updated or skipped rather than duplicated.
## Troubleshooting
Monaco returns 401 on invalid keys. Double-check you copied the entire key
and that it has not expired. Monaco strips non-printable characters when
sending the key, so trailing whitespace or unusual characters are tolerated,
but a wrong key will not pass validation.
Monaco is polled every 30 minutes. If the meeting still doesn't appear,
click **Sync Meetings → Last 7 days** to force a refresh, then check the
activity log for sync errors.
Monaco's diarization quality depends on the source recording. Multi-speaker
calls without clear audio may collapse into a single speaker. This is
upstream from Yuzu.
# Otter
Source: https://docs.yuzulabs.io/integrations/notetakers/otter
Otter direct integration is in beta — connect via Zapier today.
A direct Otter integration is on our roadmap, but the production setup flow isn't yet exposed in the Yuzu UI. In the meantime, Otter transcripts can flow into Yuzu through Zapier with no loss of fidelity.
**Status:** Beta. Use Zapier as the bridge until the direct integration is generally available.
## Connect Otter via Zapier today
The fastest way to get Otter transcripts into Yuzu right now:
Follow the [Zapier setup guide](/integrations/notetakers/zapier) to connect your Yuzu workspace.
Use Otter's Zapier integration to fire on **New Conversation** (or your preferred trigger). Map the transcript text and metadata to Yuzu's webhook fields.
Run a short Otter conversation. The transcript should appear in your Yuzu transcripts list within a minute.
## Want early access to the direct Otter integration?
Email [support@yuzulabs.io](mailto:support@yuzulabs.io) and let us know. The direct integration will use OAuth and will skip the Zapier hop entirely.
# Yuzu Notetaker
Source: https://docs.yuzulabs.io/integrations/notetakers/yuzu-notetaker
Connect the native Yuzu Notetaker so recorded meetings sync into your workspace.
Yuzu Notetaker is the native meeting capture path for teams that want recordings and transcripts to arrive in Yuzu without routing through another notetaker provider.
## What it does
After the native app is connected to a workspace, completed calls can sync back into Yuzu. Synced meetings use the same intake path as other transcript sources:
* The transcript is attached to the workspace and owner.
* Yuzu classifies the meeting type.
* Buyer calls can be attached to a deal or left as an unassigned call.
* Eligible sales calls can create next actions, TLDRs, business-case pages, email drafts, and other seller work based on workspace automation settings.
## Connect the native app
Open **Settings -> Notetaker** and choose Yuzu Notetaker. Follow the connection flow in the native app so it knows which workspace should receive completed calls.
Once connected, the settings page should show the integration as active.
## What arrives in Yuzu
When a meeting completes, Yuzu receives the meeting title, participants when available, recording or transcript metadata, and transcript text. The meeting then appears in the same call and deal surfaces as Fireflies, Fathom, Granola, Circleback, HubSpot, and Zapier transcripts.
## Troubleshooting
If a native meeting does not appear:
* Confirm the native app is connected to the intended workspace.
* Check whether the meeting has finished processing in the native app.
* Open **Settings -> Notetaker** to confirm the integration is still active.
* Check unassigned calls if Yuzu could not confidently identify a buyer or deal.
The native notetaker does not change approval behavior. Autopilot and review settings still control whether Yuzu generates, queues, or waits for approval on buyer-facing work.
# Zapier
Source: https://docs.yuzulabs.io/integrations/notetakers/zapier
Bridge any notetaker (or any app) into Yuzu via Zapier — map fields in the Zap editor.
The Zapier integration is the catch-all bridge for tools we don't yet support directly. tl;dv, Otter, Grain, custom internal tools — anything that has a Zapier trigger can pipe transcripts into Yuzu.
**Auth method:** OAuth 2.0 between Zapier and Yuzu (handled by the Yuzu Zapier app).
The Zapier integration is currently in beta. Reach out to [support@yuzulabs.io](mailto:support@yuzulabs.io) to have it enabled for your workspace.
## Prerequisites
* A Zapier account on a plan that supports webhook actions or premium app integrations.
* An admin on your Yuzu workspace who can authorize the Zapier connection.
* The source app (Otter, Grain, tl;dv, etc.) connected to Zapier.
## Setup
Email [support@yuzulabs.io](mailto:support@yuzulabs.io) with the subject "Zapier Integration Request" and your workspace name. Yuzu enables the Zapier app for your workspace.
In Zapier, search for **Yuzu** and click **Connect**. You'll be redirected to Yuzu to authorize the connection. Approve the requested scopes.
Pick your notetaker (Otter, Grain, tl;dv, …) as the trigger. For the action, use the Yuzu **Send Transcript** action.
Map these fields:
* **Transcript** → the full transcript text from the source app.
* **Title** → the meeting title.
* **Meeting date** → the meeting start time.
* **Participants** → attendee emails or names.
* **Summary** (optional) → if your source app produces one.
* **Action items** (optional).
Run the Zap with a sample meeting from your source app. The transcript should appear in your Yuzu transcripts list within a minute.
Once it works end-to-end, enable the Zap. Every new meeting in the source app will now flow into Yuzu.
## What gets pulled
Whatever you map in the Zap. At minimum, the transcript text is required for Yuzu to classify the call and (if it's a sales call) generate a recap video. The richer the metadata you pass through, the better Yuzu's automation rules can target the right meetings.
Zapier-sourced transcripts don't have a Yuzu-managed integration record, so Yuzu cannot retry-fetch them. If a webhook from Zapier fails, the Zap itself needs to retry — Yuzu's "Retry fetch" button does not apply.
## Running Zapier alongside a direct integration
You can keep Zapier connected even if you also have Fireflies, Fathom, or another direct integration active. Yuzu accepts webhooks from both. Use this when one team uses Fireflies and another uses Otter, for example.
## Troubleshooting
The Zapier integration is gated per-workspace during the beta. Email [support@yuzulabs.io](mailto:support@yuzulabs.io) with your workspace name to have it enabled.
Zapier's transcript field is plain text. Speaker diarization isn't preserved unless your source app serializes speakers into the text itself (e.g. `Alice: …`). Yuzu does its best to detect speaker prefixes when present.
Open the run in Zapier and check the response from Yuzu — most failures are field-mapping errors (missing transcript, malformed date). Fix the mapping in the Zap editor and re-run.
Zapier tokens expire periodically. Reconnect Yuzu inside Zapier — go to **My Apps → Yuzu → Reconnect**. No data is lost.
# Integrations overview
Source: https://docs.yuzulabs.io/integrations/overview
Connect notetakers, Gmail, Google Calendar, LinkedIn, CRMs, and meeting sources so Yuzu can turn GTM activity into deal signal.
Yuzu can pull sales-call data, email activity, calendar meetings, LinkedIn engagement, CRM context, and meeting transcripts from your existing tools. Most teams start with a notetaker, then connect Gmail, Google Calendar, and LinkedIn so follow-up, meetings, and engagement can return to the deal thread.
## Available integrations
Auto-generate videos from meeting transcripts. Direct providers plus Zapier.
Native meeting capture that syncs completed calls into Yuzu.
Send and schedule tracked emails, backfill person history, and detect buyer replies.
Sync meetings, create invites, and power booking links.
Draft, schedule, and publish posts, then bring reactions and comments back into deals.
Send package notifications, review emails in Slack, and route Zu replies.
Send mobile-friendly notifications and workspace-scoped Zu replies.
API-key based. Webhook-driven transcript imports.
OAuth. Webhook is created automatically on connect.
API key. Polls Granola for new notes and supports all-time sync.
Webhook only. Paste the URL into the Ergo dashboard.
Webhook automation. Sends notes, action items, and transcripts.
API key. Pulls meetings, transcripts, CRM records, tasks, and email activity from Monaco.
Beta. Connect via Zapier today.
Beta. Connect via Zapier today.
OAuth. Pulls meeting transcripts and call recordings from HubSpot.
OAuth. Syncs companies, people, deals, tasks, notes, meetings, and email activity.
Connect any of 6,000+ apps. Map fields in Zapier.
## How they fit together
Each integration falls into one of three roles:
* **Source** — provides the raw signal (transcript, email, calendar event, CRM event). Examples: Fireflies, Granola, Gmail, Google Calendar, Monaco, Attio, and HubSpot.
* **Trigger** — decides which signals turn into a Yuzu flow. Configured per-workspace under **Settings → Automations**.
* **Destination** — where the rendered video, draft, or notification lands. Examples: Slack, Telegram, HubSpot deal notes, and email.
* **Engagement return path** — sends buyer activity back into Yuzu. Examples: Gmail replies, CRM email activity, calendar meetings, LinkedIn comments, public-link views, and video CTA clicks.
A typical setup wires up at least one source and one destination, then lets Yuzu's automation rules handle the rest.
## Need something custom?
If your tool isn't listed, the [Yuzu API](/api-reference/introduction) gives you the same primitives our integrations use. Most one-off integrations end up as a small webhook handler that calls `POST /flows/sales-email-video`.
# Slack
Source: https://docs.yuzulabs.io/integrations/slack
Use Slack for Yuzu notifications, package review, and workspace-scoped Zu replies.
Slack is both a notification destination and a lightweight review surface. It keeps seller work visible where the team already coordinates, while the durable record stays in Yuzu.
## What Slack enables
When Slack is connected, Yuzu can send:
* Video-ready notifications with the TLDR, business-case page, and proposed follow-up email.
* Email draft review modals for editing and sending from Slack.
* Compose shortcuts for creating a new Yuzu email draft from Slack.
* Approval-required notifications for generated work.
* Transcript-ready and email-draft-ready notifications.
* Workspace-scoped Zu replies in Slack when external chat is configured.
## Review and send from Slack
Slack email review uses the same draft record as the app. A seller can open the modal, edit the recipients, subject, and body, then send or save the message as a Gmail draft.
Slack should not be a hidden second editor. If the draft is changed from Slack, the in-app review surface should reflect the same saved content.
## Security and ownership
Slack requests are signature-verified before Yuzu accepts an interaction. Review actions also check workspace and draft ownership before editing, sending, or saving a Gmail draft.
If a user is no longer allowed to send a draft, the Slack action should fail instead of sending stale buyer-facing copy.
## Setup
Open **Settings -> Notifications** and connect Slack. After the connection is active, choose which event types should notify the workspace.
Slack notifications are not a replacement for Gmail or LinkedIn permissions. Sending email still requires a connected Gmail account with `gmail.send`.
# Telegram
Source: https://docs.yuzulabs.io/integrations/telegram
Use Telegram for Yuzu notifications and quick workspace-scoped agent replies.
Telegram gives teams another notification and chat return path for Yuzu work.
## What Telegram enables
When Telegram is connected, Yuzu can notify the user or workspace when important work is ready, such as:
* A TLDR or buyer package that needs review.
* A transcript that finished syncing.
* An email draft that is ready to inspect.
* A deal event that should pull the seller back into Yuzu.
Telegram can also participate in external Zu chat when configured for the workspace. Replies are scoped to the workspace so the seller can tell which Yuzu account answered.
## When to use it
Use Telegram when the seller prefers mobile-first notifications or when Slack is not the team's operating channel. The reviewed work still lives in Yuzu, Gmail, LinkedIn, or the relevant approval surface.
## Setup
Open **Settings -> Notifications** and connect Telegram. Choose the event types you want to receive.
Keep high-volume events quiet at first. Start with buyer-package-ready and email-draft-ready notifications, then add more event types once the workspace has enough signal quality.
# Agent observability
Source: https://docs.yuzulabs.io/product/agent-observability
Inspect recent deal, master, and Zu chat agent runs with model, cost, tokens, and tool-call metadata.
Agent observability is the admin view for debugging Yuzu's agent work. It is available at `/admin/agents` inside a workspace.
## What the page shows
The page has three main tabs:
* **Deal agent**: recent reasoning traces for deal next actions and signal.
* **Master agent**: recent workspace-doc review runs.
* **Chat**: recent Zu chat turns, tool calls, and compactions.
It also shows a monthly cost rollup across agent sources.
## Why it exists
Use agent observability when you need to answer:
* Which model ran?
* How long did it take?
* How many input and output tokens were used?
* Which tools did Zu call?
* Did a chat conversation compact?
* Did a deal-agent run produce new next actions?
## What it is not
This is not a customer-facing analytics page. It is a workspace admin/debugging surface for model behavior, cost, and traceability.
# Autopilot
Source: https://docs.yuzulabs.io/product/autopilot
How automatic TLDR generation works and when Yuzu waits for you.
Autopilot controls whether Yuzu automatically turns eligible calls into drafts and videos.
## What autopilot can do
When enabled, autopilot can:
* Watch connected meeting sources.
* Classify eligible calls.
* Create TLDR drafts.
* Create or refresh the standard buyer package for eligible transcript intake: TLDR, business-case page, and follow-up email draft.
* Generate email draft suggestions.
* Queue or send Gmail-backed email depending on your approval settings.
* Queue or publish LinkedIn posts depending on your approval settings.
* Publish a video bundle when video-bundle autopilot is enabled.
* Keep call context indexed for search and intelligence.
## What autopilot does not override
Autopilot respects workspace settings. If script approval is required, Yuzu pauses for review. If autopilot is off, calls can still be indexed, but video generation waits for a manual action.
Per-surface toggles control whether Yuzu can ship work automatically:
* Auto-send emails
* Auto-publish LinkedIn
* Auto-publish video bundle
When a surface is off, the generated work lands in the relevant approval queue instead.
## Eligible call types
Sales calls are the core path. Other business call types can also become videos when the workspace settings and call classification allow it.
Yuzu now classifies fundraising, investor diligence, pitch, webinar, customer success, support, internal, networking, interview, and non-sales calls separately. Investor and fundraising calls are not treated as normal buyer opportunities unless the conversation is actually about selling a product or service to that investor.
Autopilot is scoped to eligible intake and explicit package work. It should not regenerate TLDRs or business-case pages for every later event such as an email open, link view, or LinkedIn reaction. Those events update signal and can trigger the deal agent to revise next actions.
Calendar events can resolve or create meeting next actions, but they do not automatically re-render a TLDR unless the underlying deal context warrants an explicit package update.
## Dedupe and quota
Autopilot creates one recap flow per canonical source meeting. If the same notetaker event arrives again, Yuzu records it as already processed instead of creating another video.
The buyer package is also deduped per analysis so the deal page should show one grouped package card, not multiple package cards for the same TLDR/business-case/email set.
Quota checks happen before expensive generation work. When a workspace is at its video limit, autopilot skips new TLDR creation but keeps the transcript available for search, assignment, and intelligence.
## Queues and retries
Yuzu coalesces indexing and analytics sync work so repeated writes do not create unnecessary duplicate sync jobs. If a queue worker fails, stale running jobs are recovered and retried instead of stalling permanently.
# Presenter avatar
Source: https://docs.yuzulabs.io/product/avatar
Create the talking presenter used in Yuzu videos from a photo, with realistic and cartoon options.
The presenter avatar is the small talking version of you that can appear in generated videos. It uses your uploaded photo, your selected style, and your narration voice to make recap videos feel more personal.
## What to upload
Upload a clear photo of yourself in **Settings -> Brand and voice** or during onboarding.
Supported files:
* PNG
* JPG
* WebP
* Up to 8 MB
Use a front-facing photo with enough lighting. Avoid cropped faces, heavy filters, and group photos.
## Realistic and cartoon styles
Yuzu supports two avatar styles:
* **Realistic** uses the original photo as the talking-photo source.
* **Cartoon** first generates a stylized portrait from your photo, then uses that approved cartoon image as the talking-photo source.
For the cartoon path, generate the cartoon preview first. After you approve the look, generate the avatar.
## Generate the avatar
Click **Generate avatar** after choosing the style. Yuzu builds a HeyGen talking photo and stores it for future videos. If you replace your source photo, regenerate the avatar so new videos use the updated presenter.
The avatar is audio-driven. It lip-syncs to the narration voice used by the video, including cloned voices when your workspace has one.
## Turn it on or off
Use the avatar toggle in Brand and voice settings to decide whether TLDR videos include the presenter avatar.
When the avatar is off, Yuzu can still generate all-slide videos with voice-over. This is also the default path for some overview videos that do not need a talking presenter.
## Where it appears
The presenter avatar can appear in:
* TLDR recap videos
* Buyer-package videos
* Master overview TLDRs, when the workflow uses a presenter
Avatar setup is optional. You can skip it during onboarding and add it later from settings.
# Brand and voice
Source: https://docs.yuzulabs.io/product/brand-and-voice
Configure the look, voice, presenter avatar, thumbnails, and theme Yuzu uses for generated work.
Brand and voice settings keep generated videos and public pages recognizably yours.
## Brand identity
Add the assets Yuzu should use in generated work:
* Logo
* Brand colors
* Public page styling
* Thumbnail treatment
## Voice cloning
You can use cloned voices across supported video types. The cloned voice becomes part of your workspace setup, so recaps do not need to be configured from scratch each time.
## Presenter avatar
The presenter avatar is the talking version of you that can appear in recap videos. Upload a photo, choose realistic or cartoon, then generate the avatar. You can turn the presenter on or off for TLDR videos from the same settings area.
See [Presenter avatar](/product/avatar) for the full setup flow and file requirements.
## Thumbnail customization
Thumbnails help a recap feel specific to the buyer and the moment. Use them to make generated videos easier to recognize in the video library and public pages.
## Theme
Yuzu supports light and dark theme. The theme toggle lives in the app sidebar and controls the workspace UI, not the content of already-rendered videos.
## Onboarding
New workspaces use onboarding to collect the basics: brand, voice, presenter avatar, product context, meeting source, and first-video setup. You can revisit settings later as your workflow changes.
# Business-case pages
Source: https://docs.yuzulabs.io/product/business-case-pages
Buyer-facing pages that package the recap video, summary, CTA, transcript, and product assets into one link.
A business-case page is the buyer-facing version of a deal artifact. It is not the internal deal page. Send it when a buyer needs a clear recap, proof, next step, and supporting material in one place.
Business-case pages are part of the standard buyer package with the TLDR recap. The deal page keeps a review card visible so the seller can open the page, check the buyer-facing story, and draft the send email from the same context.
## Layout
Business-case pages lead with a short title, a concise summary, and the recap video. The title should be skimmable; the page is meant to be forwarded inside the buyer's company.
The default layout places the video beside the headline and summary on wider screens. Theater mode switches to a stacked layout with the title, summary, and video in a larger viewing position.
## Video controls
The player can support:
* Theater mode
* Full screen
* Picture-in-picture while scrolling
* Transcript display
* Copy transcript
The transcript starts collapsed so the page leads with the business case, not raw notes.
## CTA
The CTA should give the buyer a useful next step. For seller follow-up, use a mailto-style CTA that opens a draft to the seller with a short subject and starter body.
## Product assets
Some teams have product material that should always be available on a business-case page: calculators, ROI sheets, screenshots, links, one-pagers, or buyer-specific files.
Add these as product assets rather than embedding them in the recap video. The video should stay focused; the page can carry the supporting proof.
## Analytics
Business-case pages can feed engagement back into Yuzu:
* Page views
* Video play progress
* Video completion
* CTA clicks
* Link views when the page is shared through a Yuzu Link
Those events can become deal engagement events and influence signal or next actions.
## Review and sharing
Review the business-case page from the deal's buyer package card. If the TLDR or page is still generating, the card shows the generating state and disables the review action until the asset exists.
After review, use the package send action or the follow-up email row to share the page. The page should use the rendered asset generated for the deal. If a page ever points at onboarding sample media, treat that as a data or generation issue to fix before sending.
## Studio business cases
Studio includes a **Business cases** view for generated business-case pages. Use it to find shared and draft pages, search by buyer or title, and open the page editor when you need to review a buyer-facing asset outside the deal page.
Legacy Studio deal-page URLs redirect to Business cases. Yuzu no longer treats the old public timeline deal room as the expected buyer surface.
## Master business page
The master business page is a workspace-level overview page, not a one-deal page. It is generated from a short product description and one real call transcript, then published at a readable `/v/[company-firstname]` URL.
Use it when a buyer or partner needs a high-level explanation of what you sell before there is enough deal-specific evidence for a richer buyer package. The master TLDR can be generated without requiring the old legacy 16:9 avatar path.
## Internal vs public
Use the internal [deal page](/product/deal-pages) for team work. Use the public business-case page for buyers.
The old public timeline-style deal room is not the default buyer surface anymore. Keep buyers on the business-case page unless a standalone Yuzu Link exists outside a deal context.
# Calendar
Source: https://docs.yuzulabs.io/product/calendar
Review synced meetings, create Google Calendar invites, and share booking links from Yuzu.
Calendar is the workspace view for meetings that live on your connected Google Calendar. Use it to see what is already scheduled, create new invites, and share a booking link without leaving Yuzu.
## What the calendar shows
The calendar page shows events from the month you are viewing. When you move to a different month, Yuzu fetches that date range so old and upcoming events can appear without waiting for the background sync window.
Each event can show:
* Event title
* Time range
* Location or Google Meet link
* Attendees and response status
* Attachments
* Calendar source link
Open an event to inspect the details, join the meeting, open the event in Google Calendar, RSVP, reschedule, or cancel it.
## Create an event
Click **New event** to create a Google Calendar event from Yuzu. Guests you add receive a real calendar invite from your connected calendar account.
You can add:
* Title
* Date and time
* Guest emails
* Description
* Attachment links
After the event is created, Yuzu syncs your calendar again so the new meeting appears in the calendar grid.
## Booking links
Click **Booking link** to create or edit your public scheduling link. Yuzu auto-provisions one link per user the first time you open this panel.
Booking links let someone pick an open time at `/book/[slug]`. You can configure:
* Handle
* Active or paused state
* Meeting duration
* Days ahead to offer
* Timezone
* Working days and hours
* Public title
When someone books a time, Yuzu re-checks the slot against your current calendar availability before creating the event. The booker gets a calendar invite, and the meeting lands on your Google Calendar.
Booking links currently validate against the owner's primary Google Calendar. If a conflict only exists on a secondary calendar, the slot may still appear available.
## Deal meeting invites
Some deal next actions ask you to schedule a meeting. Those actions open a review dialog instead of a blank task. Yuzu pre-fills the deal contact emails, proposes a reasonable time, and creates a real Google Calendar invite when you send it.
If Yuzu already sees an upcoming meeting with one of the deal contacts, the scheduling action can resolve itself so you do not need to mark it done manually.
## Requirements
Calendar features require a Google account connected with Calendar access. If you only connected Gmail, open **Settings -> Integrations** or **Settings -> Email** and reconnect Google with the additional Calendar permissions.
See [Google Calendar](/integrations/calendar) for connection details.
# Case studies
Source: https://docs.yuzulabs.io/product/case-studies
Use call evidence to spot customer stories worth turning into proof.
Case studies collect potential proof points from calls. The goal is to help you notice where a buyer already described the problem, the change, and the value in their own words.
## What Yuzu looks for
* A clear before-and-after.
* A measurable or specific business result.
* A customer quote that can anchor the story.
* Enough deal context to understand who the story is for.
## Current status
Case-study candidates are early. Treat them as a research queue, not a finished customer story. Review the source calls, confirm permission, and edit the narrative before publishing anything externally.
## How to improve candidates
Assign calls to the right deal, merge duplicate buyer contexts, and keep transcripts indexed. Better grouping gives Yuzu better source material.
# Content quality
Source: https://docs.yuzulabs.io/product/content-quality
How Yuzu uses model routing, rubrics, and judge feedback to improve buyer-facing copy.
Yuzu generates buyer-facing material: recap scripts, emails, LinkedIn posts, business-case copy, titles, and summaries. Content quality is the system that keeps that output specific, useful, and less generic.
## Model routing
Different tasks use different model tiers:
* **Opus** for deeper agent work, long-context reasoning, email quality, and high-stakes judgment.
* **Sonnet** for high-volume generation, summaries, emails, and business-copy drafting.
* **Haiku** for fast classification, routing, dedupe, and other lightweight decisions.
The model registry gives Yuzu one place to route work and audit which model generated a result.
Recent deal-agent and email-review work uses Opus 4.8 where the task needs stronger account reasoning. Recurring workspace memory and high-volume strategy drafting can still use lower-cost models when the task is narrower.
## Judge passes
Some generated content can run through an LLM judge panel. Judges score the draft against a rubric and return concrete feedback.
If the first draft is weak, Yuzu can revise once using the judge feedback, then compare the revision against the original. The system keeps the better version and avoids exposing judge language to buyers.
Judge results are also useful for generated-asset review gates. A TLDR, business-case page, email, or LinkedIn post should not be treated as ready just because a background job produced bytes. The review state should reflect whether the asset passed generation, has review metadata, and is safe to expose to the seller for approval.
## What judges look for
Rubrics vary by surface, but generally check:
* Specificity to the buyer and deal
* Clear next step
* Factual grounding in available evidence
* Avoidance of generic AI phrasing
* Appropriate tone for a seller-authored artifact
* No invented claims beyond the source context
## What still needs human review
Judges are a quality gate, not legal or commercial approval. Review anything that mentions pricing, commitments, timelines, discounts, security, or customer claims before sending.
For buyer-package assets, review is explicit. Sellers should open the TLDR, business-case page, email, or LinkedIn post and confirm the final artifact before sending or scheduling it, even when autopilot created the draft automatically.
# Content suggestions
Source: https://docs.yuzulabs.io/product/content-suggestions
Turn repeated call signal into reusable GTM content ideas.
Content suggestions are where Yuzu turns repeated customer language into things your team can use: posts, follow-up angles, sales enablement, and campaign ideas.
## What feeds content suggestions
* Repeated patterns across calls.
* Customer quotes.
* Common objections and blockers.
* Education gaps.
* Deal outcomes and next steps.
## Current status
The content section is still developing. Today, it is best used as a place to watch emerging ideas from patterns, quotes, and case-study candidates.
## Best source material
Content suggestions improve when calls are grouped to deals, transcripts are indexed, and enough recent calls exist to separate a real theme from a one-off comment.
# Deal pages
Source: https://docs.yuzulabs.io/product/deal-pages
Use a deal page to read the buyer thread, review Zu's next actions, and work from all known deal signal.
A deal page is the seller's operating view for a buyer thread. It brings together the history Yuzu has for one buyer context, even when the data came from different tools.
Deal pages are internal workspace pages. They are where your team reviews history, assigns calls, searches context, and copies the right public link when something should be shared.
## Deal thread
The thread is ordered by activity. It can include:
* Meeting transcripts
* Generated TLDR videos
* Public Yuzu Links
* Email threads and draft suggestions
* LinkedIn posts and engagement
* Captured quotes and indexed insights
* Searchable moments from previous calls
* Manual events, notes, links, extracted page text, and uploaded files
## Next actions
The next action cards are generated by the deal agent. They explain the recommended move, why it matters, and which surface to use.
The standard buyer package is shown as one grouped card, not separate TLDR, business-case, and email cards. The package can include:
* TLDR video
* Business-case page
* Follow-up email
* LinkedIn post, when one exists or is recommended
Each row shows the next available action: generate, generating, review, retry, after TLDR, or done. While generation is running, the row stays disabled and shows the in-progress state. When review is ready, the button opens the existing editor or public-page review surface.
The card next to the package is the contextual move, usually an email draft or a LinkedIn post when there is a reason to publish. Contextual cards stay separate so the standard buyer package does not swallow meeting-specific work.
Meeting next actions open a calendar invite dialog when Google Calendar is connected. Yuzu pre-fills known deal contacts and marks the action done after a real invite is created or an upcoming matching meeting is detected.
Some next actions also appear in [Tasks](/product/tasks), where you can scan work across deals without losing the deal link behind each item.
Previous actions stay visible below the cards so the current recommendation does not lose the trail of what already compounded.
Click **Regenerate** when new evidence arrived and the agent should re-evaluate the deal.
## Add evidence to a deal
Use **Add to deal** when useful evidence lives outside the connected sources.
* **Add activity** records a manual event or note.
* **Add link** attaches a web page and, when possible, extracts readable page text into the deal thread.
* **Upload file** stores a file as deal evidence.
* **Paste text/transcript** turns raw call notes or transcript text into deal context.
Link ingestion is deliberately conservative. Yuzu accepts normal HTTP and HTTPS links, blocks private or local network addresses, caps large pages, and falls back to metadata when full page extraction is not available. A successfully added link becomes deal evidence and can trigger the deal agent to re-read the thread.
## Summary and path to close
When Yuzu has enough activity, the page includes a concise summary under the header and a horizontal path-to-close timeline below the action cards.
The timeline shows what is done, what is happening now, and what still needs to happen before the deal closes. It is generated from deal evidence, so older deals may fill in after the deal agent runs again.
## Search inside a deal
Yuzu indexes both extracted insights and full-call chunks. That means a deal page can answer narrower questions like:
* "Who asked for the implementation timeline?"
* "Where did they mention security review?"
* "What objections came up before pricing?"
Search uses the deal grouping. After a merge, the destination deal gets the combined context.
## Public links, business-case pages, and standalone links
A **Yuzu Link** or business-case page is the public URL you can send to a buyer. A **deal page** is the internal workspace thread.
When a link belongs to a deal or buyer account, Library opens the deal page so you can see the surrounding context. Standalone links still open their link-management page because there is no buyer thread to resolve.
The business-case page is the primary buyer-facing deal page. The old timeline-style public deal room is no longer the expected share surface. For buyer-facing links, see [Business-case pages](/product/business-case-pages).
## Generated work and history
When new calls enrich a deal, Yuzu can generate newer versions of recaps and deal pages. Previous artifacts remain available in the thread so you can inspect or reuse older outputs.
Older videos, link entries, and generated drafts stay attached to the thread instead of becoming separate navigation destinations. This keeps the customer history in one place.
## Emails on a deal
Deal pages show email threads that Yuzu can tie to that deal: sends created for the deal and replies linked back to those sends.
When Zu creates an email draft for a next action, you can review it in deal context before sending. Edit the recipient, subject, and body, then send through the connected Gmail account. Use [People](/product/people) when you need the broader email history with a contact.
You can also schedule reviewed email drafts from the deal editor. The schedule stays attached to the draft until it sends or you clear it.
Drafts created for the buyer package should open as reviewable email work, not as a request to ask Zu again. If the package already has a draft, the row opens that draft so the seller can edit, send, or schedule it.
## LinkedIn on a deal
Deal pages can show LinkedIn draft assets when the agent has a reason to prepare a post. Open the asset to edit the copy, hashtags, and media, then approve, publish, or schedule it.
After publishing, LinkedIn engagement can return to the deal thread when Yuzu can match the actor to a saved person.
# Deals
Source: https://docs.yuzulabs.io/product/deals
How Yuzu groups calls, videos, emails, LinkedIn engagement, public links, and insights into deal threads.
Deals are Yuzu's memory layer. A deal groups the calls, TLDR videos, public links, emails, LinkedIn posts, engagement events, next actions, and insights that belong to the same buyer conversation.
## How deals are created
Yuzu tries to resolve the buyer account when a transcript arrives. The safest signals are provider account IDs, CRM IDs, meeting metadata, and email or domain data from notetakers and integrations.
When a transcript includes a buyer email, Yuzu can also create the primary contact for the deal. The goal is to avoid making the seller paste the same buyer name, email, and LinkedIn context again after the meeting has already supplied it.
When the source does not provide enough reliable metadata, the call stays visible as an **unassigned call**. It is not deleted or hidden. You can assign it later.
Historical imports are more conservative. Older transcripts are kept searchable and assignable, but Yuzu does not automatically create a fresh deal for every old meeting outside the recent-meeting window.
Unassigned calls still open inside Deals. Yuzu creates a temporary call page for the transcript so list view and pipeline view behave the same way. After assignment or merge, the call becomes part of the destination deal thread.
## What a deal contains
* Calls and transcripts
* TLDR videos
* Public Yuzu Links
* Email threads, replies, draft suggestions, opens, and clicks
* LinkedIn post drafts, published posts, reactions, and comments
* Quotes, objections, next steps, and other insights
* Full-call search moments
* Zu-generated next actions and completed actions
* Manual notes, uploaded files, and pasted transcripts
## Merge and assignment
Merging deals does not delete source records. It only changes the grouping so the deal thread, search, insights, and future recap context use the combined history.
Use merge when:
* A notetaker could not identify the customer.
* Two customer names normalize differently.
* A buyer changed domains or showed up through a different source.
* A manual upload belongs to an existing deal.
Use assignment when a single unassigned call belongs to a known customer. Use merge when two buyer threads are really the same conversation.
## Pipeline fields
Deals can carry pipeline stage and status so the list can be filtered by in-flight, stalled, closed-won, and lost work. These fields are lightweight Yuzu fields, not a full CRM replacement.
Deals can also carry a deal type, such as customer opportunity, internal, investor, partner, or hiring. Use the **All types** filter on the list or pipeline view to narrow the workspace. The List/Pipeline switch preserves the active filters in the URL so the view can be refreshed or shared without losing context.
### VC and investor calls
Yuzu classifies fundraising, investor diligence, board updates, and capital-raising conversations as investor work instead of normal buyer deals. Those records can still be useful, but they should not rewrite buyer-facing GTM strategy, pricing, objections, TLDRs, or business-case pages unless the same fact is also supported by buyer or customer evidence.
Use the **VC / investors** type filter when you need to review that activity without mixing it into the sales pipeline.
## Signal and next actions
The deal agent reads the deal thread and writes a signal level, signal reason, next actions, and prior completed actions.
When a deal has buyer-package work, the package is grouped into one card with one row per artifact:
* **TLDR recap**: the short recap video the buyer can replay or forward.
* **Business-case page**: the buyer-facing page that packages the recap, summary, CTA, transcript, and product assets.
* **Follow-up email**: the short seller-reviewed send that shares the package with the buyer.
* **LinkedIn post**: shown only when the deal has a relevant post or post draft.
Each package row has its own action and state: generate, generating, review, retry, after TLDR, or done. The package card does not mean Yuzu re-renders a TLDR on every event. New TLDR generation runs from transcript intake or an explicit click. The deal page keeps the review/send actions visible so the seller knows what package is ready and what still needs work.
The required next action is contextual. It should point at the current step in the path to close, not force a package action into every agent run. It usually becomes an email draft, and can become a LinkedIn post when there is a clear LinkedIn reason. Internal requests and missing-context asks are also routed through email because that is the usable seller surface.
Email and LinkedIn actions can be sent immediately after review or scheduled for later. Scheduled assets stay editable while they are still drafts.
Use **Regenerate** when a deal has changed and you want the agent to re-read the current state. Rapid clicks are coalesced so one double-click does not create duplicate agent runs.
Meeting next actions can open a calendar invite dialog. If Yuzu already sees an upcoming meeting with a deal contact, the action can resolve after the calendar sync. Cross-deal work that belongs to you can also appear on [Tasks](/product/tasks).
## Summary and path to close
When the deal agent has enough evidence, the deal header includes a one-line summary. The most important phrase is emphasized so sellers can skim the current reason the deal matters.
The path-to-close timeline turns the deal plan into ordered steps. Completed steps show as done, one current step is marked `now`, and future steps remain upcoming. This makes older meeting history easier to understand without reading every transcript.
## Deal briefs and account memory
Deals can include a timestamped brief above the action area. The brief is generated from recent events plus per-deal account memory, so it can summarize the current state without forcing the seller to read every transcript, email, and note.
Account memory is not a buyer-facing artifact. It is the stable internal record that helps Zu and the deal agent remember what changed, what is still true, and what should happen next.
## Archive and delete
Archive removes a deal from active lists but keeps the direct URL available for review. Delete is a soft-delete path: the deal should disappear from lists and agent search, while direct visits resolve to a safe not-found state instead of a broken page.
## Member visibility
Admins can triage the full workspace. Members see deal activity that belongs to them. If a teammate has their own calls on the same buyer, Yuzu keeps member-scoped views limited to the records that user is allowed to see.
# Email drafts
Source: https://docs.yuzulabs.io/product/email-drafts
Suggested and tracked emails generated from calls, people, and deal context.
Email drafts are still seller-controlled, but they are now part of the connected email workflow. With Gmail connected, Yuzu can create drafts, queue them for approval, send tracked replies, and persist sent or received messages back into the app.
## What Yuzu creates
After a call is processed, Yuzu can draft follow-up copy using:
* The current transcript.
* Previous calls in the same deal.
* Captured next steps and objections.
* The generated TLDR video or Yuzu Link, when available.
* Existing email thread context when a reply is being drafted.
## How to use a draft
Review the draft, edit it, and send it from the app when Gmail is connected. Deal next-action cards can open drafts in context, so you can edit the recipient, subject, and body without leaving the deal.
Buyer-package email rows should open the existing reviewable draft when one exists. If the package has not produced a draft yet, the row creates one and then returns the seller to review. The expected workflow is edit, save, approve, send, or schedule from the deal, not ask Zu where the email went.
If email autopilot is off, agent-created sends wait for human approval before they leave the mailbox. If autopilot is on, the same draft and tracking path can send directly.
## Scheduling
You can schedule an email draft after review. Pick a future send time from the email editor, then click **Schedule**. Yuzu stores the schedule on the draft and sends it later through the connected Gmail account.
Scheduled emails stay editable until the scheduled time. If you change the copy, save the draft before scheduling again. Use **Clear schedule** when the email should stay as a draft.
Scheduled sends require the same Gmail connection and `gmail.send` scope as immediate sends.
The reply composer supports rich formatting:
* Bold and italic text
* Bulleted and numbered lists
* Links
* Inline pasted images
* File attachments within the composer limits
Sent replies are stored in Yuzu and threaded with the original Gmail conversation.
## Slack review and Gmail drafts
When Slack notifications are connected, Yuzu can send a video-ready package notification with the TLDR, business-case link, and proposed follow-up email. Sellers can open an email review modal from Slack, edit the message, and send it without opening the app first.
The same review flow can save a Gmail draft instead of sending immediately. That is useful when the seller wants the message in their mailbox, wants to make final edits in Gmail, or needs to route the draft through a team process before sending.
Slack actions still use the same ownership and approval checks as the in-app editor. A Slack button should not let one user send another user's draft.
## Why drafts are deal-aware
When a call belongs to a deal, drafts can reference earlier context without making the seller re-explain the whole relationship. If a call is unassigned, assign or merge it first for better context.
Business-case actions can also draft a short send email. That message is meant to share the TLDR and business-case page with the buyer, not to replace the buyer-facing page itself.
Deal and people pages show conversation threads so sent replies do not disappear after Gmail accepts them. The app should show both inbound and outbound rows in order, with enough From, To, and Date context to understand the thread.
## Tracking
Tracked sends can record opens, clicks, and replies. Those events feed deal activity and can influence signal, triggers, and Zu's next recommendation.
# GTM digests
Source: https://docs.yuzulabs.io/product/gtm-digests
Daily, weekly, and team email digests that turn deal signal into an inbox-ready operating view.
GTM digests bring Yuzu's deal signal back to email. They are useful for sellers and founders who do not want to open every deal page just to know what is hot, what needs movement, and what is waiting for review.
When digests are enabled for a workspace, Yuzu builds them from active buyer deals, buyer-package state, deal signal, close progress, and recent activity.
## Digest types
Yuzu can produce three digest views:
* **Daily GTM digest**: new buyer deals plus buyer packages that are ready to review or share.
* **Weekly GTM digest**: active buyer deals grouped into Hot, Get it going, and Stale.
* **Team digest**: a manager view grouped by seller, with deal count, pipeline, hot deals, and stale deals.
Each digest links back into Yuzu so the next step can happen in the deal page, the buyer package review surface, or the public business-case preview.
## Weekly buckets
The weekly digest keeps the inbox view simple:
* **Hot** deals have strong signal or meaningful close progress.
* **Get it going** deals are active but need the next seller move.
* **Stale** deals are quiet, low-signal, stalled, or at risk.
Closed-won, closed-lost, archived, deleted, merged, and non-buyer work is excluded from the seller digest. Fundraising, internal, customer, and other non-buyer records still belong in Yuzu, but they should not pollute buyer pipeline reminders.
## Daily review queue
The daily digest focuses on what changed recently:
* Newly created buyer deals.
* TLDR videos, business-case pages, or buyer packages that are ready to review.
* Share links that are ready to copy or send.
If there is nothing new and nothing waiting for review, the daily digest can skip the send instead of creating noise.
## Team view
The team digest gives leaders a weekly view of seller coverage. It summarizes rep-level pipeline value, hot deals, stale deals, and the top deals that need attention.
Rep attribution uses the latest known seller context from calls and workspace activity. As ownership data gets richer, the digest can become a cleaner manager cockpit without changing seller workflows.
## What to do from a digest
A digest is not meant to replace the deal page. Use it to decide where to go next:
* Open the deal when the next action needs context.
* Open the business-case page when a buyer package is ready for review.
* Open the share link when the asset is ready to send.
* Let low-signal or stale deals fall out of the main working set until there is new buyer activity.
# Home
Source: https://docs.yuzulabs.io/product/home
The GTM signal view for the week: work waiting on you, call activity, quotes, patterns, and autopilot status.
Home is the daily operating view for Yuzu. It shows what needs action now, what changed recently, and whether enough call data exists to turn the week into useful GTM signal.
## What you see
* **Needs me** shows deals and setup tasks waiting for human action.
* **All deals** shows the broader active deal list.
* **Stalled** isolates deals that need attention.
* **GTM signal** shows weekly activity, indexed calls, and the state of autopilot.
* **Patterns this week** summarizes repeated signals once enough calls are indexed.
* **Quote of the week** highlights a recent customer quote from the current week.
* **Activity** lists important background work, such as generated TLDRs, indexed calls, captured quotes, and email drafts.
* **Your business page** prompts you to create or publish a master overview page when one is not live yet.
## Quick video
Use **Quick video** or **New from call** to paste a transcript, upload a call, or start a sales recap from a connected meeting source.
## Your business page
The business-page card creates a master TLDR and shareable overview page for what you sell. Paste a short product description and one real call transcript. When generation finishes, publish the page to get a readable `/v/[company-firstname]` link.
This page is not tied to one buyer deal. It gives you a general share link for low-context introductions and gives Yuzu better source material for future recap work.
## Zu from Home
Open Zu from the bottom-right rail to ask workspace-level questions like "what deals need attention?" or "summarize my latest calls." Zu is route-aware, so questions from Home default to workspace context instead of a single deal.
## Calendar and tasks
Use [Calendar](/product/calendar) when you need to review meetings, create invites, or manage your booking link. Use [Tasks](/product/tasks) when you want a cross-deal view of manual work and Zu-generated approvals waiting on you.
## Autopilot status
Autopilot only generates work when your workspace settings allow it. If autopilot is off, Yuzu still indexes calls and prepares context, but it waits for a manual start before creating videos.
# Intelligence
Source: https://docs.yuzulabs.io/product/intelligence
The overview for weekly GTM signal: KPIs, patterns, quotes, case-study candidates, and content ideas.
Intelligence turns indexed calls into signal you can act on. It is the hub for call analytics, repeated patterns, customer language, and suggested follow-up work.
## Sections
* **Analytics** shows activity, engagement, and team coverage KPIs.
* **Patterns** groups repeated themes across calls.
* **Quotes** collects customer language with speaker and source context.
* **Case studies** surfaces potential proof points from call evidence. See [Case studies](/product/case-studies).
* **Content** is where repeatable call signal will become reusable GTM content. See [Content suggestions](/product/content-suggestions).
* **GTM digests** bring active deal signal back to email so sellers and managers can see what is hot, stale, or ready for review. See [GTM digests](/product/gtm-digests).
Content and case-study suggestions are still evolving. The current system focuses first on reliable call indexing, quotes, KPIs, and pattern detection.
## How signal appears
Yuzu needs indexed calls before it can build weekly signal. Calls from connected notetakers, uploads, and manual transcripts flow into the knowledge base when they are eligible for analysis.
Digest emails use the same deal signal as the in-app Intelligence views. They do not create a separate source of truth; they are a way to route attention back into the right deal, buyer package, or public page.
# KPIs
Source: https://docs.yuzulabs.io/product/kpis
What the Yuzu analytics page measures and how to read it.
KPIs turn calls, insights, recap videos, links, and team coverage into a small set of operating metrics.
## Workspace metrics
* **Clients touched**: distinct buyer accounts or deals with recent activity.
* **Calls indexed**: completed calls that have been classified and indexed.
* **Next-step coverage**: how often indexed calls include a clear next step.
* **Classification rate**: the percentage of calls classified into useful call types.
## Buying signals
* **Objections and blockers**: concerns, blockers, or risk signals captured from calls.
* **Unanswered questions**: education gaps or open customer questions.
* **Next steps**: explicit follow-up items captured from the conversation.
## Client momentum
* **Stalled clients**: buyer contexts with no recent buyer touch or engagement after the latest call.
* **Link views**: public Yuzu Link views.
* **Engagement score**: a combined signal from link views, video plays, completions, CTA clicks, and recent activity.
## Team coverage
Team coverage compares activity and customer coverage across reps without showing another rep's private call moments to a scoped user.
Metrics include average coverage, recap count, CTA clicks, and classification coverage.
# Library
Source: https://docs.yuzulabs.io/product/library
Browse generated assets and reusable GTM materials.
Library is the place to browse reusable Yuzu output across the workspace.
## What belongs in Library
Depending on your workspace setup, Library can include:
* Generated videos.
* Business-case pages, Yuzu Links, and other public pages.
* Captured quotes.
* Case-study candidates.
* Reusable content ideas.
* Other generated GTM artifacts.
Draft scripts stay in the video review flow. Library is for output you can reuse, share, search, or open later.
## How Library differs from Home
Home tells you what needs attention now. Library is for finding and reusing what already exists.
## Opening links
Library keeps navigation tied to the thing you are trying to manage:
* Deal-backed business cases open the internal deal page or business-case editor.
* Standalone Yuzu Links open the link-management page.
* Public copy actions copy the buyer-facing URL.
That means a manually-created link without a buyer account stays reachable even when there is no deal page behind it.
## Search
Use Cmd-K or the page search to find assets by title, customer, call phrase, quote text, or related deal context.
# Master Vault
Source: https://docs.yuzulabs.io/product/master-vault
The editable workspace knowledge base for strategy docs, account notes, and Zu's read-only memory.
Master Vault is the workspace file system for GTM knowledge. It stores strategy docs, account docs, and agent-maintained notes that should outlive any one conversation.
## Strategy docs
Strategy docs are living workspace references. Teams use them for:
* ICP and positioning
* Buying committee patterns
* Objection playbooks
* Pricing rules
* TLDR style guidance
* Tone of voice
* Win and loss themes
* Sales process
* USPs
* Industries
* Fundraising, when investor evidence exists
The master agent can review these docs against recent workspace signal and write versioned updates when the evidence has materially changed. Workspaces with enough classified customer calls can bootstrap drafted docs such as ICP, Sales process, Buying committee patterns, Positioning, Objection playbook, Pricing rules, Win themes, USPs, and Industries.
Some docs intentionally remain placeholders until Yuzu has enough evidence. For example, Tone of voice, TLDR style guide, Loss themes, and Competitive stance should not be filled with generic guesses just because the file exists.
## Evidence boundaries
Vault docs should stay honest about where their evidence came from. Buyer, customer, and prospect conversations can update GTM docs such as ICP, positioning, pricing rules, win themes, and objection playbooks.
Fundraising, investor diligence, board updates, and capital strategy belong in fundraising or investor context. They should not rewrite buyer-facing GTM docs unless the same fact is also supported by customer or prospect evidence.
## Zu's notes
**Zu's notes** is a system document written by the chat agent. It is read-only for humans and exists so Zu can preserve durable workspace facts it learns through conversations.
Humans can:
* Read the doc.
* Open the version rail.
* See which agent wrote each revision.
* Duplicate content into a normal editable doc when needed.
Humans cannot directly edit the system doc. That keeps agent memory auditable and prevents accidental manual edits from being treated as agent-authored memory.
## Version rail
The version rail shows each saved change, author type, timestamp, and summary. Prior system versions are visible for inspection, while restore actions are disabled on protected agent-memory documents.
## Accounts
Account docs let the workspace keep durable context outside the deal page. Use them for account-level notes that should apply across multiple conversations or opportunities.
# Patterns
Source: https://docs.yuzulabs.io/product/patterns
How Yuzu clusters repeated call signals into reusable GTM patterns.
Patterns are repeated call signals that show up often enough to treat as a rule, not an anecdote.
## How patterns are built
Yuzu extracts structured insights from calls, then clusters similar insights across the workspace. A pattern can come from repeated objections, repeated pain, repeated requested features, or repeated language buyers use to describe value.
## What makes a pattern useful
A useful pattern has:
* Multiple supporting call moments.
* Recent evidence.
* A clear buyer-facing theme.
* Enough specificity to change a follow-up, recap, or content idea.
## Pattern status
New workspaces may show no patterns until enough calls are indexed. Pattern clustering runs after knowledge-base indexing and is debounced so repeated call updates do not overload the queue.
## What comes next
Patterns will feed stronger content suggestions, case-study candidates, and outbound ideas as the content section matures.
# People
Source: https://docs.yuzulabs.io/product/people
Manage buyer contacts, connect email history, and correlate LinkedIn engagement back to deals.
People is the contact layer for Yuzu. It keeps buyer identities, emails, LinkedIn profile URLs, deal membership, and engagement history in one place.
## Adding a person
When you add a person, Yuzu dedupes by email address. If the contact already exists, the add flow merges into the existing person instead of creating a duplicate row.
People can exist with or without a deal. A standalone person becomes useful later when you attach them to a deal, backfill Gmail history, or match LinkedIn engagement.
When a meeting transcript includes a buyer email, Yuzu can create the primary person on the related deal automatically. If the person was added from Gmail first, Yuzu can still infer related deals from sent or received email rows so the contact does not look disconnected.
Deal contact chips use the same person records. Removing a contact from one deal should only remove that association; it should not delete the person or their Gmail history.
## Gmail backfill
If Gmail is connected with readonly access, opening a person's **Emails** tab can search your mailbox for relevant history with that contact. The backfill is user-scoped: it reads and persists the signed-in seller's mailbox history, not every mailbox in the workspace.
The Emails tab can show:
* Historical threads from Gmail backfill
* Sent emails created through Yuzu
* Inbound replies received through Gmail sync
* Threaded conversation views with sent and received messages in order
* Rich replies with formatting, inline images, and attachments when Gmail send access is connected
The person email view is intentionally broader than a deal email view. People shows your history with that contact. Deal pages show deal-scoped email rows.
When you send from a person thread, the outbound message should persist in Yuzu after Gmail accepts it. The app should not only rely on Gmail Sent as the record of what happened.
## LinkedIn profile URL
Add a LinkedIn profile URL when you know the buyer's profile. Yuzu uses that URL to correlate LinkedIn post reactions and comments back to the person and any deals they appear on.
This lets Yuzu tell the difference between generic social engagement and activity from a buyer, champion, or stakeholder.
## Activity
The Activity tab is the chronological feed for the person. It can include email sends and replies, LinkedIn engagement, and deal-related events when those sources are connected.
# Quotes
Source: https://docs.yuzulabs.io/product/quotes
Find customer language captured from calls, with speaker, date, and source context.
Quotes preserve the words buyers actually used. They help you write recaps, follow-ups, case studies, ads, and internal summaries without flattening the customer's language.
## Where quotes come from
Quotes are extracted from indexed calls. Yuzu keeps source context such as speaker, transcript, meeting date, and related buyer account or deal when available.
## Quote of the week
The quote of the week uses the source meeting date, not the date the quote record was indexed. That keeps the weekly view tied to when the conversation actually happened.
## Voice of customer
Use Quotes when you need:
* A customer proof line for a recap.
* Real objection language.
* A case-study seed.
* Messaging that sounds like buyers, not internal shorthand.
# Search and ask anything
Source: https://docs.yuzulabs.io/product/search
Use Cmd-K to search Yuzu or ask natural-language questions across calls, insights, videos, links, and analytics.
Cmd-K is both a launcher and a question box.
## What it searches
Yuzu combines multiple indexes:
* **Typesense** for fast keyword search across app records.
* **Mongo vector search** for extracted call insights and full-call moments.
* **ClickHouse** for analytics records and KPI-style search hits.
* **Convex** for recent transcript context and workspace-scoped records.
## Asking questions
When your query looks like a question, Yuzu gathers evidence and returns a short answer with citations. You can click the cited records to inspect the source.
Good questions include:
* "Who did I talk to recently?"
* "Who asked us to build the HubSpot sync?"
* "Which customer mentioned security review?"
* "What objections came up last week?"
## Scope and privacy
Answers are scoped to the current workspace and your role. Member-scoped users only receive evidence they are allowed to see.
## When to use keyword search
Use shorter terms when you want a list instead of an answer, for example a customer name, video title, quote text, or integration name.
# Signals and triggers
Source: https://docs.yuzulabs.io/product/signals-and-triggers
How meetings, email, LinkedIn, links, and videos become deal signal and agent next actions.
Yuzu turns GTM activity into deal signal. A signal is an observed event with enough context to affect a deal, a trigger, or a generated follow-up artifact.
## Signal sources
Yuzu can collect signal from:
* Notetaker transcripts and manual transcript uploads
* Gmail sends, opens, clicks, and replies
* Google Calendar meetings, created invites, and scheduled buyer follow-ups
* LinkedIn post reactions and comments
* Public Yuzu Link views
* Rendered-video views, completions, and CTA clicks
* Manual deal events and notes
* LinkedIn and company enrichment from verified profile or company-signal sources
## How signal reaches a deal
When a new event lands, Yuzu tries to resolve the workspace, user, deal, contact, and source artifact. If it can attach the event to a deal, the deal activity feed updates and the deal agent can re-evaluate the next actions.
Signals are normalized before they reach the deal agent. That keeps the model focused on what happened instead of making it infer event meaning from raw webhook payloads.
Enrichment jobs are treated as supporting evidence. LinkedIn, company, and PredictLeads-style signals can improve routing, people matching, company context, and deal briefs, but buyer-facing claims still need to be grounded in calls, emails, calendar events, public engagement, or saved deal material.
## Triggers
Triggers are recurring patterns or conditions that should change the seller's behavior. Examples:
* Buyer asks for a timeline and pricing.
* A meeting is scheduled with a buyer contact.
* A stakeholder engages with a LinkedIn post.
* A public page is viewed after a period of silence.
* A video is watched to completion and the CTA is clicked.
* A contact replies with a concrete objection or request.
Triggers can feed next actions, content suggestions, and agent-generated work.
Signals can also feed [GTM digests](/product/gtm-digests). Digests package active buyer deals, buyer-package review work, and stale opportunities into email so sellers can get pulled back into Yuzu without treating the inbox as the system of record.
For deal next actions, Yuzu keeps buyer-package work visible when it exists: TLDR recap, business-case page, and follow-up email, with LinkedIn included when there is a relevant post. The trigger decides the current path-to-close move, such as drafting a procurement email, preparing a LinkedIn post, sending a calendar invite, or asking for missing context through an email draft.
Not every signal should trigger a new TLDR render. Meeting intake and explicit seller actions create or refresh the package. Later opens, clicks, replies, or LinkedIn engagement should usually update signal and next actions without reprocessing the same video unless the deal has materially changed.
## Deal signal level
Deal pages show signal level and reasoning when the agent has enough context. The current levels are:
* **High**: recent multi-party motion, direct engagement, or urgent buyer action.
* **Medium**: normal active motion with a clear next step.
* **Low**: stalled, silent, or waiting on seller action without strong buyer engagement.
## Regeneration
Click **Regenerate** on a deal when you want the deal agent to re-read the current state. Rapid clicks coalesce so a double-click does not create duplicate agent runs.
When multiple events arrive close together, Yuzu queues one follow-up agent run instead of dropping the later signal or creating duplicate traces.
## Tasks are not signal by default
[Tasks](/product/tasks) is the seller work queue. Creating or moving a personal task does not automatically mean the deal changed. If a task represents real buyer activity, add the activity to the deal or let the connected source, such as Gmail or Calendar, create the signal.
# Tasks
Source: https://docs.yuzulabs.io/product/tasks
Use Tasks to manage personal seller work and Zu-generated approvals across deals.
Tasks is the workspace queue for seller work that should not be buried inside a deal page. It combines your manual tasks with pending work Zu already knows about, such as reviewable buyer-package assets, email drafts, and meeting invites.
## What appears in Tasks
Tasks has two sources:
* **Manual tasks** you create for yourself.
* **From Zu** items generated from deal next actions and pending approvals.
Manual tasks are personal. They are scoped to the creator and behave like notes-to-self, not workspace-wide assignments. Zu items come from active deal recommendations and approvals, so they stay connected to the deal that created them.
## Board and list views
Use the view switch to work in:
* **Board**: drag manual tasks between columns.
* **List**: scan more rows at once.
Open tasks are grouped into **Todo** and **In progress** by default. Turn on **Show done** to include **Done** and **Canceled**.
Each manual task also has a status selector, so keyboard users can move work without drag and drop.
## Filters
Tasks can be filtered by:
* **Source**: All, My tasks, or From Zu
* **Due**: Any time, overdue, today, or this week
* **Search**: task title, task body, or deal name
Use **Export** when you need a CSV of the current task set.
## Manual task details
Manual tasks can carry more than a title:
* Deal association
* Description
* Due date
* Checklist items
* Comments
* Files
Updating a manual task does not trigger the deal agent by itself. Use deal notes, events, or a direct regenerate when the change should affect deal reasoning.
## Zu task cards
Zu task cards open the surface that can complete the work:
* TLDR review opens the video editor or package review.
* Business-case review opens the business-case review page.
* Email review opens the editable email draft.
* Meeting next actions open the calendar invite dialog.
* Link actions open the target URL or deal page.
Approval tasks stay tied to the underlying asset. Completing the task should mean approving, sending, scheduling, or otherwise finishing the actual work, not only hiding a reminder.
## Relationship to deal next actions
Tasks does not replace deal pages. Deal pages remain the source of truth for deal signal, buyer package state, and path to close.
Use Tasks when you want one cross-deal view of work waiting on you. Use the deal page when you need the evidence, contacts, emails, and assets behind a recommendation.
# Transcripts
Source: https://docs.yuzulabs.io/product/transcripts
Upload, review, classify, assign, and index calls.
Transcripts are the raw material behind Yuzu's videos, search, deals, and intelligence.
## Sources
Transcripts can come from:
* Connected notetakers.
* CRM/provider imports.
* Zapier or webhook sources.
* Manual upload or pasted transcripts.
## Processing steps
After a transcript arrives, Yuzu can:
1. Classify the call type.
2. Resolve the buyer account or deal when metadata is available.
3. Extract insights, quotes, objections, and next steps.
4. Index full-call chunks for moment search.
5. Trigger eligible TLDR or draft workflows based on autopilot settings.
Classification separates sales calls from investor, pitch, webinar, customer success, support, internal, networking, interview, and non-sales calls. That lets Yuzu keep VC or board conversations visible without treating them as buyer-package evidence by default.
## Assignment
If Yuzu cannot confidently identify the customer, the transcript remains visible as unassigned. Assign it to a new or existing deal so future search, recaps, and drafts use the right context.
If Yuzu cannot confidently identify the owner, the transcript stays with the workspace admin or integration owner. Admins can assign it to the right member from the transcript workflow.
Yuzu keeps one canonical transcript per provider meeting. If a notetaker sends the same meeting through more than one path, Yuzu dedupes it instead of creating a copy for every matching teammate.
## Older transcripts
Historical imports are safe by default. Yuzu indexes older transcripts and keeps them visible, but it does not automatically create new deal records for every old meeting outside the recent-meeting window.
Use manual assignment when an older transcript belongs to an active deal. Use recent transcript recovery when you want the deal agent to re-read meetings from the last few days and write the current next-action package.
## Visibility
Admins can see workspace transcripts. Members see transcripts assigned to them. This same ownership scope is used by Library, Deals, TLDR videos, and Cmd-K answer evidence.
# Videos
Source: https://docs.yuzulabs.io/product/videos
Create, review, approve, share, and archive Yuzu videos.
Videos is where generated TLDRs move from draft to shareable asset.
## Video states
* **In progress** means the video is still being generated or is waiting for approval.
* **Completed** means the video has a rendered asset and can be shared.
* **Archived** keeps old or abandoned work out of the active queue without deleting history.
Completed and archived lists are separated. Archiving a stale approval flow hides it from the completed tab while preserving its history.
## Creating a video
Start from **Create**, **Quick video**, or a transcript. A sales recap can use one call, a pasted transcript, or a connected notetaker source.
Yuzu can now generate recap videos for more meeting types than pure sales calls. Autopilot still respects your workspace settings before creating drafts automatically.
Home can also create a master TLDR for your business page. That overview video is generated from product context and one real call transcript, then attached to a shareable business page.
## Review and approval
Some workspaces auto-approve. Others stop at a review step so you can edit the script before render. If approval is required, the video remains in **Awaiting approval** until someone approves it.
## Sharing and public pages
Completed videos can be shared as Yuzu Links. Public pages can include the video, source context, moments or chapters, CTA links, and a lightweight business case.
For deal work, the TLDR is one row in the buyer package. Generate or review it from the deal page when the video belongs to a buyer thread, then use the business-case page or follow-up email to share the full package.
Non-sales-call videos can also have public pages with moments, so useful call sections remain easy to reference even when the meeting is not a sales recap.
When a video belongs to a deal, the video page links back to the deal thread. Use the deal page for customer context and the public Yuzu Link for sharing externally.
## Thumbnails and brand
Video thumbnails, logo treatment, brand colors, presenter avatar, and voice selection come from your workspace brand and voice settings. You can also use cloned voices across supported video types.
The presenter avatar is optional. If it is enabled and ready, Yuzu can place a talking version of you into supported recap videos. If it is disabled or not ready, videos can render as voice-over slide videos.
See [Presenter avatar](/product/avatar) for the photo-based avatar setup.
# Zu agent
Source: https://docs.yuzulabs.io/product/zu-agent
Use Zu to ask about deals, inspect context, draft work, and search uploaded files from inside the workspace.
Zu is the workspace chat agent. It lives inside authenticated workspace routes and answers from the context you are already looking at.
## What Zu can see
Zu receives workspace context, the current route, and the current deal when you are on a deal page. It can use tools to fetch the records it needs instead of guessing from the visible page.
Common questions:
* "What deals need attention?"
* "What's the latest on this deal?"
* "Who should I follow up with?"
* "Draft a recap for the buyer."
* "Find the pricing objection from the last calls."
On a deal page, Zu should know the current deal name and workspace. It should not answer as if the user is in a generic workspace when route context is available.
## Tools Zu can use
Zu can inspect workspace records and create work through scoped tools, including:
* Deals and deal details
* Contacts attached to a deal
* Recent emails and drafts
* LinkedIn posts and engagement
* Business-case content
* Buyer-package assets such as TLDRs, business-case pages, and follow-up emails
* Uploaded chat attachments
* Master Vault documents that are safe for agent use
Tool-call rows appear in the chat thread so you can see when Zu looked something up or created something.
When Zu creates buyer-facing work, the output should land in the same review surfaces as the rest of the product: deal email review, LinkedIn post review, business-case review, or video review. Chat is useful for requesting work, but the seller should still get a concrete draft or asset to inspect.
## Attachments
You can attach files to chat when the answer depends on material outside Yuzu. Supported files are indexed into searchable chunks so Zu can retrieve the relevant parts without pushing a whole document into the model context.
Supported intake includes common documents and media such as PDF, DOCX, XLS/XLSX, CSV, Markdown, HTML, PPTX, text, OTF font metadata, PNG/JPEG image text, and audio formats.
Ask Zu to search for a term or summarize the relevant section of an attachment. That keeps large files out of the context window while still making them usable.
## Where chat appears
Zu appears on authenticated workspace routes. It does not mount on public buyer routes such as `/v/...`, `/link/...`, sign-in, sign-up, checkout, or onboarding.
## Zu outside the app
Zu can also answer from connected team channels when the workspace has external chat configured. Slack and Telegram messages are routed to the right workspace, and replies show the workspace scope so a seller can tell which Yuzu account answered.
External chat is for quick questions and coordination. When Zu creates buyer-facing work, that work still goes through the normal review surface: the deal email editor, LinkedIn post review, business-case review, TLDR editor, or an approval flow in Slack.
## Observability
Admins can open `/admin/agents` to inspect recent chat turns, tool calls, compactions, model usage, token counts, and estimated cost. This page is meant for debugging and audit, not buyer-facing work.
# Quickstart
Source: https://docs.yuzulabs.io/quickstart
Send your first sales-call video from the Yuzu dashboard in five minutes.
This walk-through is for the **Yuzu dashboard at [app.yuzulabs.io](https://app.yuzulabs.io)**. If you'd rather drive Yuzu programmatically, jump to the [API quickstart](/api-reference/quickstart).
## 1. Sign in and pick (or create) a workspace
Sign in at [app.yuzulabs.io](https://app.yuzulabs.io). If your team already has a workspace, accept the invite from your inbox. Otherwise, create a new workspace from the welcome screen — pick a name and you'll land on **Home**.
## 2. Set up your brand, voice, and avatar
Open **Settings -> Brand & Voice**. You only need three things ready before your first video:
* **A presenter avatar** (optional). Upload a photo, choose realistic or cartoon, then generate the talking presenter Yuzu can place in recap videos.
* **A voice.** Pick a provided voice, or use a cloned voice if your workspace has one.
* **A logo and colors** (optional but recommended). The brand panel controls public pages, thumbnails, and generated video styling.
## 3. Connect your sources
Most teams skip the manual paste step entirely by connecting a notetaker. Then connect Gmail, Google Calendar, and LinkedIn so replies, meetings, and social engagement can return to the deal thread.
Open **Settings -> Integrations** and pick the sources you need:
Send tracked email and backfill contact history.
Sync meetings, create invites, and share booking links.
Draft posts and track buyer engagement.
API key + webhook.
API key.
OAuth.
OAuth — pulls call recordings from HubSpot.
Once connected, every meeting that matches your automation rules will trigger a video draft.
If you'd rather not connect anything yet, skip to the next step and just paste a transcript by hand.
## 4. Create your first video
From Home, click **Quick video** or **New from call**. You'll see two ways in:
* **Paste a call summary or transcript.** Anything 50+ words. Yuzu generates a script and continues automatically.
* **Pick from connected meetings.** Available once you've connected a notetaker — just click a meeting from the list.
## 5. Review (or skip review)
By default, Yuzu auto-approves the script and renders the video end-to-end. You'll see it appear in **Videos -> In progress**, and you'll get a notification when it's ready.
Want a human gate on every video? Toggle **Settings -> Automations -> Require script approval**. After that, every flow stops at the script step until you approve, edit, or reject it.
## 6. Share the video or buyer package
When the video finishes rendering, open it from **Videos**:
* **Copy a Yuzu Link** to send via email — viewers don't need an account, and you get plays/CTA analytics for each link.
* **Download the MP4** if you'd rather attach it directly.
* **Push to HubSpot** if you've connected HubSpot — the video gets attached to the matching deal.
For deal work, the TLDR is usually part of a buyer package. Open the deal page to review the TLDR, business-case page, and follow-up email together before sending.
## 7. Create your business page
Home can prompt you to create a master business page: a shareable overview page and master TLDR for what you sell. Paste a short product description and one real call transcript. Yuzu uses that source material to generate the page and make future recap work sharper.
## Next steps
Group calls, videos, links, and drafts into buyer threads.
Review synced meetings, create invites, and manage booking links.
Search records or ask questions across call context.
Notetakers, CRMs, Slack, Zapier — all under Settings -> Integrations.
For teams that want to wire Yuzu into their own automations.