Troubleshooting
When something breaks, Skavelo finds out why
A help chat can only ask users to describe what went wrong. Skavelo runs inside your app, so it can see the error they’re looking at and the request that failed. It explains the likely cause in plain words, then the fix, and follows the troubleshooting steps your team writes down. When it can’t solve it, it hands off with everything it checked.
HelpI can’t save my billing settings, it keeps failing
It looks like your role doesn’t allow changing billing settings. Ask an admin on your account to make the change, or to give you the Admin role under Settings, then Team.
Passed on if a person takes over
Checked: the error on screen; saving billing settings was refused (403).
Likely cause: the user’s role.
Invoice reminder didn’t send
When a user says a reminder didn’t go out, or their customer wasn’t reminded
Check, in order
- Ask which invoice it was
- Look up the invoice: its status and reminders sent
What it means
- Paid or a draft: no reminders are due
- Overdue, none sent: reminders are off; walk them through turning them on
- Reminders sent: give the dates; check the customer’s email
What happens when a user reports a problem
Step 1
They say it isn’t working
“Why won’t this save?”, “the export is broken”, or just “something’s wrong”, in their own words.
Step 2
Skavelo looks first
At the error on screen, the requests that just failed, switched off buttons and, with lookups, their own data.
Step 3
It follows your playbook
If your team wrote one for this problem, Skavelo works through its checks in order, asking the user only what it can’t see.
Step 4
It fixes, or hands off
It explains the cause and shows the fix. If the cause isn’t clear, it says what it checked and offers a person with that summary.
Built for real support work
Reads what went wrong
A refused save points to permissions, a payment error to the plan, a missing page to something deleted. Skavelo turns that into “your role doesn’t allow this”, never a status code.
Playbooks in plain language
Write when to use it, what to check in order (something on screen, a lookup, or a question to ask), what each finding means and when to hand off. No code, and no flowchart to maintain.
Tested before users see it
New playbooks start off. In Testing, only your team’s Try it uses them, and each conversation shows the playbook followed and what was checked.
Suggests playbooks for you
When three or more users report the same problem, Skavelo drafts a playbook from those conversations and how they ended. Every line links to its source, and nothing is used until you accept it.
Handoffs that start informed
Your team gets what Skavelo checked and the likely cause, in the email, in the message typed into Intercom, Zendesk or your chat, and in the handoff event.
See what keeps breaking
Needs attention and Conversations label reported problems with their diagnosis, and the Monday summary lists the problems reported most, so repeated failures stand out.
What Skavelo looks at
Gathered in the user’s browser and sent with their question. Request content, headers and query strings are never read, IDs in paths are removed, and anything you mark with data-sk-sensitive stays out. You can switch failed requests off in code.
- Error messages on the page
- “Due date must be after the issue date”
- Requests that failed in the last 2 minutes: method, path and status
- PUT /settings/billing was refused (403)
- Switched off buttons, with the reason your app gives
- Late fees: “Available on Growth and above”
- The user’s own data, through lookups you set up
- INV-1042: overdue, 2 reminders sent
Questions
Set it up with Playbooks in the help center.
- Does it wait for the user to ask?
- Not always. When someone presses a switched off button twice, sees the same error come back, or presses one button again and again, Skavelo offers help above the launcher. Nothing is sent unless they click it, and you can switch it off.
- Does Skavelo read our API responses?
- No. For a failed request it keeps only the method, the path with IDs removed, and the status code, in the browser, for 2 minutes. Bodies, headers and query strings are never read, requests to other sites that never completed are ignored, and you can switch it off with diagnostics: { network: false }.
- What if the evidence is misleading?
- Skavelo only uses requests from the last 2 minutes, ignores evidence unrelated to what the user describes, and says “it looks like” when the cause isn’t proven. Your team sees exactly what it checked in Needs attention.
- Can a playbook change data in our app?
- Not on its own. Playbooks can only use lookups you’ve switched on, which only read, and walkthroughs your agent has. Any action still needs the user’s approval, and the last click is always theirs.
- Which plans include playbooks?
- Every plan works out problems from the screen. Free includes your first playbook, Starter up to 3 switched on, and Growth and Enterprise are unlimited. Playbooks in testing don’t count.
- Does it claim to fix things?
- Never. It explains the cause and how the user can fix it, or shows them. It doesn’t say it fixed, retried or reported anything, and when handoff is on it offers a person instead of guessing.
See how Skavelo handles your product’s common problems, on your own app, before you add any code.
Start free