Support
Customer support
For organisations that already hold a service agreement with AAG Cloud Connect. Raise an incident or a service request, check severity definitions and response targets, and see how escalation works.
Channels
How to reach the service desk
Three routes in. Which one you should use depends far more on urgency than on preference.
Email and the form on this page create a ticket with a written record, which is what you want for anything that needs diagnosis, attachments, or a history somebody can read later. The telephone is for incidents where minutes matter. WhatsApp sits alongside both during business hours for quick questions and status updates, and is not a substitute for raising a ticket.
Email the service desk
Best for non-urgent requests, changes, and anything with screenshots or logs attached.
info@aagcloudconnect.comCall us
The fastest route for critical incidents — production down or a suspected security event.
+233 243 182 362Quick questions and status updates during business hours, via the button on this site.
Open WhatsAppStandard service desk hours are Monday – Friday, 08:30 – 17:30 GMT. Extended and out-of-hours cover is available as a defined tier; where you hold it, the covered severities and response commitments are set out in your agreement.
Severity and targets
What each severity means
Severity sets the response, the update cadence, and how much resource is pulled onto the problem. It is worth reading before you raise a ticket.
P1 – Critical
Production down or severe security incident
P2 – High
Major function impaired; workaround limited
P3 – Medium
Degraded service; workaround available
P4 – Low
General question or minor issue
Response targets by severity
These are the standard targets used for triage. Where your contracted agreement specifies different figures, the agreement is definitive. All intervals are measured in business hours and business days unless you hold an extended cover tier.
| Severity | First response | Updates | Target |
|---|---|---|---|
| P1 – Critical | 1 business hour | Every 2 business hours | Continuous effort until workaround or restore |
| P2 – High | 4 business hours | Daily | Resolution plan within 2 business days |
| P3 – Medium | 1 business day | Every 2 business days | Resolution within agreed change window |
| P4 – Low | 2 business days | Weekly | Scheduled with next maintenance cycle |
Open a support request
Include your account, tenant, or contract reference so the ticket routes to someone who already knows your environment. For a production outage or a suspected security incident, telephone first and raise the ticket afterwards — email is not a fast enough channel for a P1.
Practical
How to get a faster resolution
Most of the delay in a support ticket happens before anyone starts diagnosing it. Four habits remove nearly all of that.
The single biggest cause of slow tickets is a first message that does not contain enough to act on. “Teams is broken” requires a round trip of questions before work can begin, and each round trip costs hours of elapsed time even when everyone replies promptly. A ticket that arrives with the affected users, the time it started, the exact error, and what changed recently can often be diagnosed in the first sitting.
Screenshots and error text help more than descriptions of them. Where you can, paste the message rather than paraphrasing it — the exact wording and any correlation identifier frequently point straight at the cause, and they are what we need to raise a vendor case if it comes to that. If an issue affects some users and not others, telling us who is unaffected narrows the search as much as telling us who is.
Finally, keep one issue to one ticket. Bundling three unrelated problems into a single request means all three inherit the same severity, get worked by the same engineer, and stay open until the slowest one is finished. Separate tickets are triaged independently and usually all close sooner.
Include your account reference
Your account, tenant, or contract identifier lets us route the ticket to someone who already knows your environment.
Describe impact, not just symptoms
How many users are affected, and what can they no longer do? Impact drives severity, and severity drives response.
Tell us what changed
Recent changes are the most common cause of new incidents. Even an unrelated-seeming change is worth mentioning.
Call for P1 incidents
For production outages or suspected security incidents, telephone first. Email is not a fast enough channel for a P1.
Triage
How severity is decided
Severity is a measure of business impact, not of how urgent something feels. That distinction is what keeps the system usable for everybody.
Two questions decide severity. How many people are affected, and what can they no longer do? A payroll run that cannot complete on the day it is due outranks a reporting tool that is slow for the whole company, because the consequence is materially worse. A single executive locked out of a mailbox is disruptive but is not a production outage, and treating it as one means the next genuine outage competes for the same engineers.
We are aware this can feel unsympathetic when the problem is yours. The reason we hold the line is that severity is the mechanism that gets the right response to the right incident. If everything is critical, the classification carries no information and P1 handling stops meaning anything.
What we will not do is quietly downgrade a ticket. If you raise something as critical and our assessment differs, we will contact you, explain what we are seeing, and agree a level with you before the ticket is reclassified. The change and the reasoning are recorded on the ticket so it can be reviewed later. If new information changes the picture — the fault spreads, or a deadline turns out to be immovable — severity can be raised again at any point.
Boundaries
What is in scope
Scope is set by your signed service agreement, and we would rather be tediously explicit about it than have the conversation during an incident.
Vague promises of full support cause disputes at the worst possible moment, so our agreements state which systems are covered, which hours apply, which severities carry which targets, and what is chargeable. If you are unsure what your agreement includes, ask before you need it — we will send you the current scope summary rather than leaving you to interpret the contract.
Out-of-hours cover is a defined tier, not an assumption. We do not present round-the-clock availability as a standing fact, because for most agreements it is not one. Where you have taken extended cover, the covered severities and the response commitment outside business hours are written down. Where you have not, out-of-hours messages are picked up on the next business day.
Work outside scope is quoted before it starts. If a request turns out to be a project rather than a support ticket — a migration, a new deployment, a system we do not currently cover — we will say so, explain the reasoning, and give you a price. You decide whether to proceed. Discovering the edge of an agreement on an invoice is a failure of communication on our part, not a commercial technique.
Typically covered by an agreement
- The systems, sites, and user groups named in your service agreement
- Coverage hours as contracted, including any extended or out-of-hours tier you have taken
- Severity definitions and response targets as published below, unless your agreement states otherwise
- Vendor case management and escalation for the platforms we support on your behalf
- Change requests within the agreed maintenance and change process
Your own agreement is the definitive statement of scope. Where this page and your contract differ, the contract applies.
Escalation
If a ticket is not moving
You should never have to guess who to chase. Escalation is a defined path with named roles, and you are entitled to invoke it yourself.
Service desk
Every ticket starts here, whichever channel it arrived through. The service desk owns triage, initial diagnosis, and the first response against the target for the agreed severity. Most requests are resolved at this stage without going any further.
Default entry point for all incidents and service requests.
Practice lead
Where an issue needs deeper platform knowledge — identity, Azure architecture, backup, security, or networking — it is escalated to the lead for that practice. The original ticket stays open and the service desk remains your point of contact so you are not repeating the history to a new person.
Triggered by technical complexity, or when a P1 or P2 is not progressing within the first update cycle.
Service manager
The service manager takes ownership when an incident is breaching its targets, when several tickets point at the same underlying weakness, or when you tell us you are unhappy with how something is being handled. They can reprioritise internal resource and will give you a direct commitment on next steps and timing.
Triggered by a missed target, a repeat incident, or a request from your side to escalate.
Vendor escalation
Where the fault sits inside a vendor platform rather than your configuration, we raise and drive the case with Microsoft or the relevant vendor on your behalf, including severity escalation within their process. We stay accountable for the outcome and translate what comes back rather than forwarding it unedited.
Triggered when diagnosis points to a platform defect, outage, or a change only the vendor can make.
Escalation is not a complaint and it is not held against anyone. If a ticket matters more than its current handling suggests, reply on the ticket asking for it to be escalated, or telephone and say so. Your named contact and the current escalation matrix are listed in your service agreement and repeated in your monthly service report.
Communication
Status and planned maintenance
Two commitments: you hear about planned work before it happens, and you hear about serious incidents without having to ask.
Planned maintenance
Maintenance windows are notified in advance to your nominated contacts, with the systems affected, the expected impact, the window, and a rollback position. Routine patching follows the schedule agreed during onboarding; anything outside that schedule goes through the change process rather than being applied quietly.
Where a vendor announces maintenance that affects a platform we manage for you, we pass it on with an assessment of what it means for your environment specifically, rather than forwarding the notice and leaving you to work it out.
Incident communication
P1 incidents receive proactive updates at the cadence set out in the table above — every two business hours — whether or not there has been progress. An update saying that diagnosis is continuing and what is being ruled out is more useful than silence, and it means nobody on your side has to spend the morning chasing.
Lower severities follow the same principle at a slower cadence: daily for P2, every two business days for P3, and weekly for P4. After a P1 is resolved, you receive a written timeline covering what happened, what was done, and what we are changing to reduce the chance of a repeat.
Questions
Support questions
The things customers ask most often about how the service desk works.
Not through this page. The service desk supports organisations that hold a signed service agreement, because triage depends on knowing your environment, your contacts, and your contracted targets. If you are not a customer, use the contact page and describe the situation. If you are dealing with a live incident and want emergency assistance, telephone and say so — we will tell you honestly whether we can help at short notice and on what basis.
Not a customer yet?
This page is for organisations that already hold a service agreement with us. If you are looking for licensing, a cloud assessment, a migration, security work, or a managed service, use the contact page instead — new enquiries are answered within one business day.
Dealing with a live incident and not currently a customer? Get in touch or telephone +233 243 182 362 and say so — we will tell you plainly whether we can help at short notice and on what basis.