Fields are the core of what diio analyzes in each conversation. They define what information you want diio to identify, generate, or evaluate from what was said.
Adjusting a playbook's fields is the most direct lever for improving the quality and relevance of the analysis your team receives.
The three types of field
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 depending on what your process needs.
Custom. Specific questions your organization needs answered in every conversation of that type.
How many fields you can have
Starter: up to 5 fields per playbook.
Business: up to 10 fields per playbook.
Enterprise: custom configuration.
The quota includes any suggested fields you left active. If you need room for information specific to your process, turn off the suggested ones that are not relevant.
Before enabling or creating a field, ask yourself one question: what am I going to do with this information afterward? A good field helps you evaluate the conversation, fill in the CRM, trigger an alert, or define a next step. A playbook is not better for having more fields.
Enable a suggested field
Go to Settings → Playbooks and open the playbook.
Go to the "Fields" section.
Check the box for the field you need. Fields that are already active are marked in blue.
Expand it to adjust its subfields, accepted values, or CRM link, if applicable.
Save.
Create a custom field
A custom field is a question diio will have to answer by reading the conversation. When you create it, you choose the response type and write the question.
Choose the response type based on the data you want
Open question. For narrative answers. "What is the main problem the customer mentioned?"
Yes or no. To verify whether something specific happened. "Did the customer request a quote?"
Quantity. When you expect a number. "How many users did the customer say would use the solution?"
List. When there can be several answers. "List the objections the customer raised."
Response from a list. When the answer must be chosen from options you define in advance.
Yes/no and quantity fields are the ones that work for alerts, because they return a response you can build a condition on. If you want diio to notify you about something, first turn it into a concrete, measurable signal.
The transcript test
Before saving a custom question, run it through this test: if someone read only this transcript, could they answer the question without needing any additional information?
If the answer is no, the question needs work. These are the eight criteria that help most:
Ask one thing only. If you need the problem, the tool, and the budget, use three fields.
Answerable with this conversation. Do not ask about something that happened in an earlier meeting that is not in the transcript.
No outside knowledge required. "Which competitors were mentioned?", not "which competitors are relevant?".
Avoid ambiguous concepts. "Did they express intent to continue?" rather than "are they interested?".
Say who said or did something. "What objections did the customer raise?" is better than "what were the objections?".
Ask for explicit information. "What budget did the customer explicitly state?" keeps an assumption from becoming a data point.
Choose the right format. Make sure the response type matches the data you want.
Do not mix facts with evaluation. "What objections did they raise?" and "how well did they handle them?" serve different purposes and belong in different fields.
A label is not a question
The most common mistake is putting a label where a question should be. Here are the same fields, poorly and well framed:
"Partners" → "Which partners did the rep explicitly mention as integration alternatives?"
"Budget" → "What budget did the customer explicitly state they have available?"
"Competition" → "Which competitors did the customer explicitly mention?"
"Decision maker" → "Which people did the customer say are involved in the decision, and in what role?"
"Timing" → "What timeframe did the customer give for making a decision?"
Edit an existing field
Click the field to expand its configuration. From there you can adjust the subfields that make it up, the accepted values (on response-from-a-list fields), and the link to CRM properties.
If the field has calibratable criteria, such as Success Prediction or Overall Performance, the evaluation parameters are also adjusted here.
Remove a field from the playbook
Uncheck the field's box or use its options menu → "Remove from playbook". The field disappears from the analysis of future conversations, but it still exists in the account and you can add it back whenever you need it.
Removing a field does not erase the past. Conversations already analyzed keep that field. What does happen is that, if the field was feeding a CRM property, the property stops updating — worth telling whoever was using it in their reports.
Avoid duplicating information across fields
Two fields capturing the same thing use up quota and add nothing. Before creating one, check whether a required or suggested field already covers that information.
This happens often with Key Notes: if you already configured the summary to include the main problem, you do not also need a custom field asking for the main problem.
When to review a playbook's fields
A field has been in the CRM for months and nobody consults it to make decisions → remove it.
The team changed its process and now captures different information → add what is new and drop what no longer applies.
A field's answers keep coming back empty or inconsistent → the question probably does not pass the transcript test.
You hit your plan's limit and need room → start with the suggested fields you are not using.