The playbook editor is where you decide how diio will understand a type of conversation. Anything you change here changes the analysis your team gets afterward.
This article explains what you are deciding in each section and what each change affects, so you can confidently edit a playbook that is already in use.
Two views of the same editor
When the playbook is new, the editor works as a wizard: it walks you through four stages in order, because each decision depends on the previous one. You cannot choose fields well if you have not defined the objective yet.
When the playbook already exists, the editor leaves every section open at once. That is convenient for small adjustments, but it also makes it easy to change one thing and forget what depended on it. Which is why it helps to know how they relate.
You reach the editor from Settings → Playbooks, opening the relevant use case and conversation type.
Each section answers a different question
Context: how does diio recognize this conversation, and from what criterion does it interpret it?
Fields: what should diio extract and evaluate in it?
Assigned teams: who uses it and, as a result, who can see those conversations?
All three describe the same conversation. When one stops matching the others, the analysis starts contradicting itself.
Context: what diio reads before analyzing
This is where the name, channel, description, and objective live. Each serves a different purpose and they are worth keeping distinct.
The name is for people: it only helps you find the playbook inside diio. Changing it does not affect the analysis.
The channel decides which conversations the playbook can apply to: video call, phone call, WhatsApp, or LinkedIn — or Any if it applies to all. This is the quietest change in the editor: if you narrow the channel on a playbook that was the only one of its type, conversations on the channels you left out stop being analyzed, with no warning. Before restricting it, check that another playbook covers the channels you are excluding.
The description is what diio compares against the transcript to recognize which playbook applies. If your team has several similar playbooks and diio keeps assigning them incorrectly, the description is the first thing to review: almost always the problem is that two descriptions do not differ enough from each other.
The objective is the lens through which diio interprets everything else. It is the widest-reaching field in the editor: changing it changes how the whole conversation is evaluated.
If you change the objective, review what depended on it. Say a renewal playbook starts covering upsell too. The new objective talks about spotting opportunities to expand the contract, but the progress signals still only say "the customer confirms the renewal", performance still rewards efficiency in handling the case, and no field captures interest in additional products. The playbook now asks for one thing and measures another.
Fields: what diio extracts and evaluates
This section lists the fields split into required, suggested, and custom. Required ones are the baseline of the analysis and cannot be turned off; the rest you enable or disable depending on what your process needs.
Expanding a field lets you configure its subfields and accepted values, and link it to a CRM property without leaving this section.
Turning off a field does not erase the past. Conversations already analyzed keep that field; new ones stop having it. If that field was feeding a CRM property, the property stops updating, so it is worth telling whoever was using it in their reports.
The quota is limited, and that is useful. Starter allows up to 5 fields per playbook, Business up to 10, and Enterprise is configured to order. When the quota fills up, the right question is not how to get more fields, but which of the current ones nobody is using. A field that has sat in the CRM for months without anyone looking at it is available space.
Fields with criteria are the ones that change the analysis most. Success Prediction and Overall Performance are not just switched on: they are calibrated. In Success Prediction you write the progress and barrier signals and choose how strict the evaluation is. In Overall Performance you define what the rep should do and should avoid, at what level of rigor, and with what level of detail.
These two are where your company's methodology makes the difference, and also where an inherited playbook usually needs the most adjustment. If your team feels the performance scores do not reflect what they value, this is where you fix it.
Assigned teams: who uses it and who sees it
Shows the teams that have this playbook active, and lets you add or remove teams without leaving the editor. Playbooks are assigned to teams, not to people: each rep uses the ones belonging to their team.
This section has a consequence that is not obvious: it also defines who can see the conversations.
A Leader sees the conversations of the reps who belong to their team, analyzed with that team's playbooks. If one of those reps also belongs to another team that has the same playbook assigned, the Leader sees those conversations as well.
Before assigning a playbook to a new team, it is worth asking who on that team should be able to follow and measure those people. And if you remove a team, it loses access to the playbook for future conversations: earlier ones are not modified.
What happens when you save
Click Save in the header after any modification.
Changes apply to future conversations. Conversations already analyzed keep the analysis they had, even if the playbook changed completely. This is deliberate: it stops last quarter's reports from shifting on their own every time someone adjusts a setting.
If you need a specific conversation analyzed with the new configuration, reassign its playbook from its detail view. That reprocesses it.
Edit, duplicate, or deactivate: which one applies
The actions menu in the header (three dots) offers deactivate, duplicate, and delete. Choosing well between editing and duplicating is the most frequent decision, and the one that keeps the account tidiest.
Edit when the conversation is still the same and what changed is how you want to analyze it: the team adjusted its methodology, the objective got sharper, a field is missing or unnecessary.
Duplicate when you need a variant that is analyzed differently and both will coexist. For example, an inbound discovery and an enterprise discovery with different objectives and success criteria. You start from the existing configuration and adjust what changes. If only the country, office, or rep changes, do not duplicate: it is the same playbook.
Deactivate when the playbook is no longer in use but you want to keep the history. A playbook with no assigned teams for more than a quarter is a good candidate. It creates no noise in the analysis, but it does in the configuration list.
When it is worth coming back to the editor
diio is assigning the wrong playbook to similar conversations → review the descriptions.
The team changed its process or methodology → review the objective, then the prediction, the performance criteria, and the fields.
Performance scores do not reflect what the team values → review the Overall Performance criteria.
There are fields in the CRM nobody consults → free them up from the playbook.
A new type of conversation appeared → you probably need a new playbook, not an edit to this one.
Before you save
Imagine diio receives only the transcript. With the configuration you just left in place, could it recognize 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?