Support routed through the right channel.
Getting to the right route first is most of what determines how quickly something is resolved. This page sets out the three ways to reach us, what to include so the first reply is useful, and what to do if you have a security incident rather than a fault.
Choose a route
Three ways in, depending on who you are.
Existing clients
Use the portal, support address or escalation path agreed for your service. That route already knows your environment, your agreement and who can approve changes, which is why it resolves faster than a general enquiry.
New to CYVRIX
Tell us what has happened and what it is stopping you doing. If the honest answer is that another supplier is better placed, we will say so rather than take the work.
A project rather than a fault
Migrations, office moves, cabling, new sites and platform changes are scoped rather than ticketed. A conversation about dates and what has to keep running beats a support request.
Before you write
Six things that turn a report into a diagnosis.
Most first replies from any support desk are a request for more information. Including these removes that round trip entirely.
What you were doing
The action that led to the problem, and whether it used to work. Something that broke yesterday is a different investigation from behaviour that has never worked.
Who is affected
One person, a team, or everyone. Named users and their email addresses help more than a count, because we can check those accounts directly.
The exact wording of any error
A screenshot or the text itself. Paraphrased errors send investigations in the wrong direction more often than any other single thing.
When it started
An approximate time is enough. It lets us line the problem up against sign-in records, updates and configuration changes.
What the business impact is
Whether people can still work, and what they cannot do. This is what determines the order things are picked up in.
Anything that changed recently
A new device, a password reset, an office move, a supplier update, a new starter. Recent change is the usual explanation.
If you think you have been compromised, say so first
A suspected compromise is handled differently from a fault. Say in your first sentence that you believe this is a security incident, because it changes who picks it up and what they do first.
Do not wait until you are certain. A false alarm costs an hour. A real incident left for a day while somebody decides whether it counts is considerably more expensive, and the early hours are the ones where containment is still cheap.
Signs this is an incident: you entered credentials into a page you now doubt; you approved a multi-factor prompt you did not initiate; colleagues report email from your address that you did not send; files have been renamed or encrypted; a payment or bank detail change was requested by email; an account is signed in from a location nobody recognises.
While you wait: leave affected machines switched on but disconnect them from the network, because powering off destroys evidence held in memory. Do not delete suspicious email; forward a copy and keep the original. Tell colleagues not to act on any payment request until it has been confirmed by phone on a number they already had.
Never send credentials. Do not include passwords, multi-factor codes, API keys or recovery codes in a support request. We will never ask you for a password, and any message that does is not from us. If you have already sent a credential to anyone, change it now and tell us.
Open a support request
Tell us what has happened and what it is stopping you doing. Do not include passwords, access tokens or sensitive configuration data.