A message that says "email is broken" is enough to flag a problem, but it leaves several questions open. Is sending affected, receiving, signing in, or opening the application? Does it affect one person or a whole team? A few observations can help support choose a useful first investigation.
A clearer request explains what stopped working, who is affected, when it started, what the screen says and what has already been checked. Include the business impact as well. Those details support triage; they do not guarantee immediate service or remove the need for further questions.
Begin with a status check when it is practical. If the issue is urgent or appears to involve a security incident, use your organization’s established reporting process promptly.
Step zero: check the status page
ALCO publishes a public service-status page, and our short training video shows exactly where to look and how to read it. It requires no sign-in, so you can consult it without first accessing a customer account.
Checking it first changes your ticket in a genuinely useful way. If a declared incident matches your symptoms and service, include that context in your request and follow any posted guidance. If the page is clear, report what you are seeing anyway. An unpublished or newly developing wider incident remains possible, as does an issue limited to your account or environment.
The check gives the support team one more observation to work with.
What to check while you are there
- Is there an open incident, and does its description match what you are seeing?
- Is the affected component the one you actually depend on, rather than one with a similar name?
- When was the page last updated, and does the timestamp look recent relative to your problem?
- Is there scheduled maintenance in progress or recently completed?
- Can you subscribe to updates so you stop refreshing the page?
Writing the ticket that gets answered
Whether or not an incident is listed, describe the problem using six points. Send the information you have rather than delaying an important report to complete every field.
What exactly stopped working, in the terms you would use to a colleague. "Outlook shows a password prompt that will not accept my password" is a report. "Email is down" is a headline.
Who is affected. One person, one department, or everyone? The scope helps identify what to compare next. A shared cause may affect only some users, so report the observation without treating it as a diagnosis.
When it started, and whether it is constant or intermittent. Intermittent problems are harder, and saying so early prevents a support engineer from concluding it is fixed the first time it works.
The exact error text. Copy it, or take a screenshot with enough context to identify the application and error. Remove unrelated confidential information and use the approved support channel. Never include passwords or recovery codes.
What changed. New laptop, new password, new office, new software, a Windows update, a move to a different network. Mention a recent change even if you are unsure whether it is related. Support can assess that connection.
What you have already tried, and what happened when you did. This helps avoid repeating a step unnecessarily and preserves the result of each check.
A worked hypothetical
Two tickets, same underlying problem.
The first says: "Can't get to the client portal. Please fix."
The second says: "Since about 9:15 this morning, three of us in the accounts office cannot load the client portal — the browser shows a connection timeout, no error page. The fourth person in the same room can load it fine on her laptop. Status page shows no incident. We have tried a different browser and a phone on mobile data, and the phone works. Nothing changed on our machines that we know of, but the office switch was replaced yesterday."
The second ticket provides comparisons to investigate. The recent switch replacement is one possible lead, but the evidence does not prove it caused the problem. Support can check connectivity, configuration and differences between the working and affected devices before drawing a conclusion.
Urgency, stated honestly
Say what the business impact is, plainly. "This blocks invoicing and month-end is Friday" is information. Marking everything urgent is not, and it degrades quickly: once a queue is entirely urgent, urgency stops carrying any signal and genuinely critical work waits behind routine requests.
The same honesty helps in the other direction. If something is annoying but not blocking, saying so helps support assess it alongside other work.
What a status page cannot tell you
A green status page is evidence, not proof. It reflects what the operator currently knows and has published. Incidents take time to be detected, confirmed and posted, and a problem affecting a small subset of customers or one specific network path may never be declared at all.
So treat a clear status page as "no wider issue is currently known", not as "nothing is wrong". If your evidence says otherwise, trust your evidence and report it. Customer reports can help reveal an emerging incident.
Keep the request useful as the situation changes
Reply in the same ticket with new observations so the investigation has a continuous record. Include a timestamp and time zone when a test starts working again, and distinguish a single successful attempt from a sustained recovery. If a colleague is still affected, say so rather than assuming everyone has recovered.
Avoid making several configuration changes at once while waiting for help. They can change the evidence and introduce another issue. If you need to use a workaround, record what it is and whether it restores the full task or only part of it. Follow your organization’s guidance about sensitive information and approved applications even during an interruption.
Your next step
Watch the short walkthrough, then find your service-status page and bookmark it now, while nothing is broken. Put the link next to your support contact details, in whatever document your team actually reads.
Then borrow the six questions above as a ticket template. Use the parts you can answer, and keep the request updated if the symptoms or impact change.
Sources and further reading
ALCO training on checking service status: https://alcohq.com/training/checking-service-status
Video walkthrough: https://youtu.be/OLNnIAY7U3U
ALCO help desk services: https://alcohq.com/services/help-desk