Guide G2 Day-to-day support
When work is blocked, route the issue before expanding the scope.
A support conversation should begin with the person and workflow affected-not a broad promise to fix every technology problem. This guide shows what belongs in immediate support, what evidence shortens the first exchange, and when the pattern points to ongoing ownership instead.
G2 · Entry 01 A useful support sequence
Describe impact, isolate scope, then choose the door.
- Step 01
Name the blocked outcome
State what the person cannot complete and what business activity is affected. “Email is down” is less useful than naming the account, device, application, and last known successful action.
- Step 02
Record safe observations
Capture the exact error, timing, affected users, recent changes, and troubleshooting already attempted. Do not send credentials or private access.
- Step 03
Choose language and service fit
Select a public support door that matches the working language and issue category, then verify its current scope and contact path.
G2 · Entry 02 Practical scenarios
Similar urgency does not mean identical responsibility.
A phone-system change is a common example: see the VoIP and business-telephony guide.
One user cannot work
Begin with support. Bring the user, device, service, exact symptom, and impact. Avoid turning an isolated problem into an unrequested environment assessment.
The same failure keeps returning
Resolve the immediate blocker, then document the pattern. Repeated permissions, onboarding, device, or vendor issues may reveal missing recurring ownership.
Several systems fail together
Name the shared dependency if known and the sequence of symptoms. A support provider can then decide whether vendor coordination or a specialist escalation is required.
There may be a security event
Do not rely on a general directory for emergency response. Follow existing incident, insurer, legal, and vendor procedures where they exist; avoid sharing sensitive evidence publicly. For a non-emergency review of endpoint protection, phishing readiness, or incident-response planning, see the email security and incident response guide instead.
G2 · Entry 03 The brief’s boundary
What a first support request should and should not promise.
- In scope for the brief
- Observed symptom, affected workflow, people, timing, device or service, and safe troubleshooting history.
- Outside the brief
- Passwords, recovery codes, private keys, unsupported guarantees, or assumptions about root cause.
- Possible next decision
- Whether the issue is resolved, needs specialist escalation, or reveals a recurring responsibility gap.
G2 Next
Choose immediate support without losing the larger pattern.
The service comparison separates a current blocker from recurring care and specialist work. The directory discloses common ownership and does not rank providers.