Every Third Octopus client, whether they use OctoVault, OctoAssist, OctoFlow, OctoForge or an advisory engagement, raises support through the same place: OctoDesk, our client support and ticketing portal. This is what happens to a request once it is in.
Raising the request
A client signs in at support.thirdoctopus.com, picks the product or area, the type of request (issue, query or service request) and a priority. The SLA for that priority is shown next to it as they choose, so there is no ambiguity about the response they should expect. They add details, the environment, and attachments if useful. The portal replies with a ticket reference in the form TO-00042 and sends an acknowledgement email.
Requests that come by phone or WhatsApp
Not everything starts in the portal. When a client calls or messages, our team logs the ticket on their behalf. It appears in their portal with the same reference, tracking and notifications as if they had raised it themselves.
What our team sees
On our side the service desk shows open tickets, SLA-breached tickets, unassigned tickets, new tickets and tickets waiting on the client, with average first-response and resolution times over the last 30 days, resolved versus created over the last 7, and breakdowns by product, client, priority and agent. A "needs attention" list surfaces anything close to breach.
The first public reply auto-assigns the ticket to the agent who wrote it and stamps the first-response time. Internal notes stay internal; clients never see them.
How the SLA clock works
SLA targets are set per priority. The clock pauses while a ticket is waiting on the client, for example when we have asked for logs and are waiting for them, and resumes when they reply. Both sides see the same SLA timeline on the ticket.
Closing the loop
When we believe the issue is resolved, the client confirms and closes the ticket with a rating from 1 to 5, or reopens it if the problem returns. Every staff reply and status change is emailed to them, so nobody has to check the portal to know what is happening.
Why we built it rather than buying it
We wanted per-organisation scoping so each client sees only their own tickets, SLA tracking that pauses correctly, an audit note on every change, and the security basics done properly: cookie sessions with bcrypt, CSRF protection on every action, login throttling and an attachment allow-list. Building it on the same stack as our products meant we could have all of that without a per-agent licence bill.
A ticket is a promise with a clock on it. The portal exists so the promise and the clock are visible to both sides.
If you are a client and do not yet have a portal login, ask your Third Octopus contact. If you run a services business and want the same discipline for your own clients, OctoDesk is available as a product.
