Playbooks
Teach Skavelo how your team troubleshoots common problems, test it, and review the playbooks it suggests.
When a user reports a problem, Skavelo already looks at the errors on their screen and the requests that failed. A playbook adds your team's own knowledge: what to check, in which order, and what each finding means. Write them on the agent's Playbooks tab. Only owners and admins can change them.
What a playbook has
| Part | Example |
|---|---|
| Name | Broadcast didn't send |
| When to use it | A user says a broadcast didn't send, is stuck, or shows Sending failed. |
| What to check, in order | 1. Ask: which broadcast it was. 2. Look up: the sending domain's status. 3. On screen: an error that mentions credits. |
| What it means, and what to do | If the domain is pending: explain that it has to be verified first, and walk them through verifying it. If credits are 0: explain, and show where to buy more. |
| When to hand off | Anything else, or if the domain is verified and credits are available. |
Each check is one of three kinds:
- Something on their screen, like an error message or a switched off button.
- A lookup of their data, picked from the agent's lookups. Only lookups you've switched on are used.
- A question to ask them, like which invoice it was. Skavelo asks it, waits for the answer, and carries on with the same playbook.
An outcome can link a walkthrough, so the fix is shown on screen, not only explained.
How Skavelo uses it
Skavelo compares each question with every playbook's When to use it. When one fits, it works through the checks, skipping any the screen or the conversation already answered, and replies with the outcome that matches what it found, in its own words. It never reads the playbook out to the user.
When no outcome fits, or the handoff rule applies, Skavelo says what it checked and offers Talk to a person, with the checks and results passed on to your team.
Writing a good playbook
- Describe When to use it the way users put it: "my broadcast didn't send", "it's stuck on Sending". Skavelo matches their words against it.
- Keep one problem per playbook. Two problems with different causes make two playbooks.
- Put the cheapest check first: something on the screen before a lookup, and a lookup before a question.
- Write each outcome as you'd explain it to a user, including where to click.
Test before switching it on
New playbooks start Off. Set one to Testing, and Skavelo uses it only when your team uses Try it, here in Skavelo or on your own app. Ask the questions your users ask, then open the conversation in Conversations: each answer shows the playbook it followed and what Skavelo checked. When it works, switch it On.
Each playbook shows how it has done over the last 90 days: the conversations it was used in, how many were settled, how many were handed off and how many were rated not helpful.
Suggested playbooks
When three or more users report the same problem, Skavelo drafts a playbook from those conversations: what it checked, how each one ended, and any team notes written for them. Every check and outcome comes from those conversations, and Where it came from links to each one. Skavelo looks every Monday, and you can click Suggest from problems to look now. The weekly summary mentions new suggestions.
Suggestions aren't used until you review them. Accept and test sets a suggestion to Testing; Dismiss turns it down, and the same reports won't suggest it again.
Plans
| Plan | Switched on playbooks |
|---|---|
| Free | 1 |
| Starter | Up to 3 |
| Growth and Enterprise | Unlimited |
Playbooks that are off or in testing don't count, so you can write and try more before choosing.
Safety
Playbooks can only use lookups you've switched on and walkthroughs your agent already has, and any action still needs the user's approval, so a playbook can't change anything new. Text in a playbook is an instruction from your team; text from the page, your files and lookups stays information only.