A playbook defines one specific type of conversation: how to recognize it, what its objective is, and what diio should identify or evaluate when analyzing it.
Listening to a sales discovery call is not the same as a recruiting interview or a collections call. Each type of conversation needs its own criteria, and that is exactly what a playbook gives diio.
What you write in the playbook is the context diio will use to understand your conversations. That is why every configuration decision changes the analysis you get back.
Three levels: use case → conversation type → playbook
Playbooks are organized in a simple hierarchy. This makes them easy to find, maintain, and share across teams.
Use case. The area of work the conversation belongs to: Sales, Customer Support, Human Resources, Collections, Procurement, Internal Coordination, Prospecting, or Advanced.
Conversation type. The nature of the conversation within that use case. In Sales, for example: Discovery, Sales Presentation, Sales Follow-up, and Negotiation.
Playbook. The specific configuration applied to that conversation: "Inbound Discovery", "Enterprise Discovery", "Proposal Follow-up", "Renewal".
A use case groups several conversation types. Each type can have one or several playbooks. The playbook is where the configuration actually lives.
The conversation type does not identify the team — it identifies the nature of the conversation. A Discovery is still a Discovery whether Sales or Prospecting runs it.
Available use cases
Sales. B2B and B2C sales conversations: discovery, presentation, follow-up, and negotiation.
Customer Support. Support, customer success, retention, upsell, and cross-sell.
Human Resources. Recruiting and interviews.
Collections. Payment collection.
Procurement. Vendor and purchasing management.
Internal Coordination. Internal team conversations.
Prospecting. Inbound and outbound prospect qualification.
Advanced. Multi-purpose, flexible playbooks for any use case.
If your account predates this structure, you will also see a Legacy playbooks category. It groups playbooks that do not belong to any of the current use cases. They keep working, but they cannot be edited.
A playbook represents one type of conversation
Before creating one, decide how many you need. A playbook should have its own purpose, objective, relevant information, and evaluation criteria.
Create a new one when any of these change:
The objective of the conversation.
The success criteria.
The information that needs to be captured.
The methodology.
The way it should be evaluated.
Do not create a new one just because these change:
The country.
The office.
The person.
The rep.
A Discovery in Chile and a Discovery in Mexico, with the same objective, the same methodology, the same relevant information, and the same evaluation criteria, should use the same playbook.
Fewer well-configured playbooks analyze better than many playbooks that look alike.
What is inside a playbook
Every playbook is configured in four stages: context, fields, teams, and confirmation.
Context
Three decisions that are easy to confuse with one another, plus the channel:
Name. How you want to identify it. It is a label for people: it helps you find the playbook inside diio.
Description. What is happening in the conversation. diio compares what happened in the transcript against the descriptions of the available playbooks to recognize which one applies.
Objective. What should be achieved by the end. It is the lens diio uses to interpret the conversation and the reference for deciding whether it moved toward what was expected.
Channel. Which medium the playbook applies to: video call, phone call, WhatsApp, or LinkedIn. If it applies to all of them, you can leave Any.
Fields
A field defines a specific piece of information you want diio to identify, generate, or evaluate from a conversation. There are three groups:
Required. They are part of the playbook's baseline analysis and cannot be turned off.
Suggested. diio recommends them based on the conversation type. You can keep them or turn them off.
Custom. Specific questions for the information your organization needs. Each one is configured with a response type: open question, yes or no, quantity, list, or a response from a predefined list.
Custom fields can be linked to a property in your CRM, so the information travels on its own from the conversation to your HubSpot, Salesforce, Pipedrive, Zoho, or Odoo.
The number of fields per playbook depends on your plan:
Starter: up to 5 fields per playbook.
Business: up to 10 fields per playbook.
Enterprise: custom configuration.
If you need the quota for information specific to your process, you can turn off suggested fields that are not relevant. A playbook is not better for having more fields.
Fields with criteria
Some fields are not just switched on: they also let you configure the criteria diio uses to interpret the conversation.
Success Prediction. You write which signals indicate positive progress and which signals indicate a barrier to the objective, then choose how strict the evaluation should be (demanding, neutral, or optimistic). diio scores each conversation from 1 to 5 and explains its reasoning.
Overall Performance. You define what the rep should do and what they should avoid in this type of conversation, and at what level of rigor. diio scores from 1 to 10 and returns what they did well, what they can improve, and why they got that score.
Teams
You select the teams that should use this playbook. Playbooks assigned to a team become part of the context diio uses to analyze their conversations. Assign only playbooks that match the conversation types that team actually has.
Every part of the playbook describes the same conversation
The description, the objective, the success prediction, the performance criteria, and the fields are not independent settings: they are five dimensions of a single objective.
If the objective is "identify a relevant need that justifies moving forward", then the progress signals should describe a clear problem with relevant impact, the performance criteria should reward digging deeper and listening, and the fields should capture pain, impact, current solution, and next steps.
If the objective changes, review the prediction, the performance criteria, and the fields too. An inconsistent playbook produces contradictory analysis.
How diio decides which playbook to apply
Every conversation gets one playbook. The assignment happens in three ways:
By team. If the rep's team has a single active playbook for that channel and conversation type, diio applies it on its own.
By description. When the team has several possible playbooks, diio compares the transcript against each description. The better the description captures what happens in the conversation, the more accurately diio identifies the right playbook.
Manually. You can pre-assign the playbook from the Upcoming Meetings view before the conversation happens, or change it from the detail view once it has been analyzed.
If there is no playbook for a given channel, those conversations are not analyzed.
Who creates them, who assigns them, and who uses them
Settings Admin. Creates, edits, and deletes the account's playbooks. Global scope.
Team Coordinator. Maintains their own team's configuration: creates and edits its playbooks, assigns existing ones, and manages people. Not an Administrator, and does not touch account-level configuration.
Reps and Leaders. Use the playbooks assigned to them, but do not configure them.
Best practices
One playbook per conversation type, not one per person. If the whole team runs discovery with the same objective, one shared playbook is enough.
Describe what happens, not what the playbook is for. "First meeting" explains nothing; "initial conversation between a sales rep and a potential customer that explores their current situation, needs, and problems before presenting a solution" does.
Write an objective that is an outcome, not an activity. "Present the product" describes a task; "get the customer to confirm interest in evaluating the solution and agree on a next step" describes an outcome you can evaluate.
Start with few custom fields. Three to five well-chosen ones outperform twenty poorly defined ones. Before creating one, ask yourself what you will do with that information afterward.
Write observable signals. "The customer is interested" is not a signal. "The customer agreed on a date for the next meeting" is.
The final test
Imagine diio receives only the transcript. With the configuration you just created, it should be able to understand what type of conversation it is, what it was meant to achieve, what relevant information came up, what signals show progress or a blocker, how the rep performed, and what should happen next.