Getting help and filing a ticket
Where the support dialog lives, when to use a ticket instead of chat or the knowledge base, how to file one that gets resolved fast, what the three statuses mean, and how you'll hear back.
Basic If something in Protocol is broken, missing, or just not working the way you’d expect, don’t let it sit in a WhatsApp thread where it’s easy to lose track of. File a ticket instead, and you’ll be able to see exactly where it stands until it’s done.
Where to find it
Every page has a “How can we help?” button. Open it and you’ll see three rows: browse the knowledge base, chat with the team, or go to My tickets. If you already have a ticket that hasn’t been resolved yet, that row shows a small count so you know something of yours is still open.
My tickets opens a dedicated page listing every ticket you’ve filed, with a New ticket button to start another one.
Who sees which tickets
If you own or administer the account, this page shows every ticket anyone on your team has filed, each labelled with who filed it, so nothing your staff reports is invisible to you. Everyone else on the team sees only the tickets they filed themselves, and their reports aren’t readable by their colleagues. Nobody outside your account ever sees any of it.
Which one to use
| Use | When |
|---|---|
| Knowledge base | You want to know how to do something Protocol already supports. |
| Chat | You have a quick question and want a fast answer, right now. |
| A ticket | Something is broken, missing, or worth tracking. |
The honest rule of thumb: if you’d otherwise want to follow up on this later, file a ticket. It’s the only one of the three that keeps a record, so it’s the right choice whenever “did anyone look at this?” is a question you might ask in a few days.
Filing a ticket
From My tickets, hit New ticket. You’ll fill in a subject, a description, and optionally an area, then attach anything that helps us see what you’re seeing.
Area is optional and just helps route the ticket to the right person: General, Clients, Programs, Nutrition, Chat, Billing, Mobile app, or Other. Leave it as General if you’re not sure.
What makes a good report
The faster we can reproduce something, the faster we can fix it. A good ticket tells us:
- What you did - the steps that led up to it.
- What happened - the actual, exact result, including any error message.
- What you expected - what should have happened instead.
- A screenshot - the single most useful thing you can attach. If it’s visual, show us.
Attachments
You can attach up to 25 MB per file. Images, video, PDFs, plain text, and CSV files are all accepted, so screenshots, screen recordings, and exported spreadsheets all work.
Filing one through your assistant
If you’ve connected an AI assistant to Protocol, you don’t have to open the dashboard to report something. Tell it what went wrong and ask it to pass it on. It also works the other way around: when your assistant hits a wall itself, a capability that isn’t there or a tool that keeps failing, it’s meant to say so plainly and offer to report it rather than quietly give up or fake a result.
Either way it asks you first. Once you agree, it files a real ticket, the same kind you’d file yourself, and it lands in My tickets alongside the rest, labelled as having come from your assistant. From that point on it’s an ordinary ticket: same three statuses, same thread, same notifications.
Your assistant can also read your tickets and reply on them, so “what’s the status of the thing I reported last week?” is a question you can ask without leaving the conversation. What it can’t do is change a status, that stays with us, exactly as it does for you.
The three statuses
Once it’s filed, a ticket moves through exactly three states. There’s no fourth:
| Status | What it means |
|---|---|
| Open | Filed, not yet picked up. |
| We are on it | Actively being worked on. |
| Shipped | Done and deployed. |
You can’t change a ticket’s status yourself, that’s on us as we work it. What you can always do is add a comment, whether that’s more detail, an answer to a question we asked, or another attachment.
The conversation
Open any ticket and you’ll see the full thread: your original description, then every reply back and forth after it. When we reply, it lands right there, and you can reply back with more detail or more attachments any time.
Notifications
When we reply, or a ticket’s status changes, you’ll hear about it two ways: a notification in your bell icon, and an email. The email links straight to that ticket, so you don’t have to go hunting for it.
You’re told the same way when someone else on your team replies on a ticket you filed, which usually means your account owner. That one is titled with their name rather than ours, so a colleague’s reply is never mistaken for an answer from Protocol. Nobody is ever notified about a comment they wrote themselves.
Good to know
A few limits and edges worth knowing before you hit them:
| Subject length | 200 characters. The field counts as you type, so you’ll see it coming. |
| Attachment size | 25 MB per file, checked in your browser and again on our side. |
| Shipped, but it isn’t fixed | Reply on the ticket and say so. We can move it back out of Shipped. |
| Replying to the email | Doesn’t reach us. The email links to the ticket, and the reply has to go there. |
| Nothing is private on a thread | There are no hidden notes. Everything written on a ticket is readable by everyone who can see that ticket. |
| No search yet | Your own list is short enough to scan, so there’s no search box on it. |
| Changing the area later | Not possible yet. If you picked the wrong one, just say so in a reply. |
That’s the whole loop: file it, watch it move from Open to We are on it to Shipped, and reply whenever you have more to add. No more digging through old messages to remember if anyone ever got back to you.