Mercury, service desk
Help people, with clear rules about who sees what.
Mercury handles requests, incidents, problems and changes. Requesters get a portal, agents get queues and SLAs, and visibility is strict by default.
Early development.
Requests, incidents, problems and changes
Work arrives in the shape ITIL-style teams expect, with queues for each team and SLAs on the clock.
- Requests, incidents, problems and changes
- Change approvals by a CAB
- Queues per team
- SLAs
- Full email in and out
A portal for requesters
People can raise and follow requests, and fix common sign-in problems themselves. Password reset, account unlock and MFA re-enrolment are handed off to your identity provider. Mercury never handles passwords.
- Requester portal
- Self-service password reset, account unlock and MFA re-enrolment through your identity provider
- Knowledge base articles published from Caelus
- Live chat that becomes a ticket
Strict visibility
Agents see their team's queues, tickets assigned to them, and tickets the requester has validly linked. Nothing else.
- Visibility follows team and assignment
- A guessed ticket reference creates no link
- A guess raises an audit exception
Works with the rest of Castra
Smart links show a Minerva issue or Caelus page as a live preview inside a ticket.
Agent roles come from directory groups mapped by project admins.
Link tickets across teams without exposing the rest of either queue. See the example on the security page.
Part of Castra
Mercury shares sign-in, access rules, audit and smart links with the other two tools. Use one, or all three.