A better start
to a support call.

01 / What is happening?

Describe what people experience.

• Is service completely unavailable, intermittently interrupted, or slower than expected?
• Which offices, users, applications, or destinations are affected? Is anything working normally?
• Is the problem occurring in both directions, or mainly during downloads or uploads?
• Does it affect wired devices, Wi-Fi, remote users, or more than one? Record what has actually been tested.
• What does the disruption prevent the business from doing? Is there an existing incident or ticket reference?

Distinguish an observation from a conclusion. For example, “video calls drop every few minutes” is useful even when the cause is unknown.

02 / When did it happen?

Give a time and time zone.

Record the first known occurrence, whether the issue is still happening, and one or two recent examples. Include the date and time zone, such as Eastern Time or UTC. If the start time is uncertain, say so; a best estimate is still useful.

For an intermittent issue, record a few separate occurrences and their duration. An engineer can compare those times with measurements and relevant events on the path.

03 / Where to look

Identify the service and the test path.

Provide the service location and circuit or account reference when available. If there are multiple circuits, say which connection was in use and whether a backup was active. A simple description of the path helps: device → office network → firewall → provider handoff → destination.

Note the affected destination or application and, if relevant, its hostname or public IP address. Where safe and appropriate, compare another destination or a wired device. Do not change an active network simply to make a comparison; coordinate tests with the responsible team.

04 / Evidence

Share the test, not just the result.

If you already ran a test, include its timestamp, source device or location, destination, direction, and the complete relevant output. Mention whether the result was measured over Wi-Fi, Ethernet, or a VPN, and whether the issue was happening at the same time.

See our guides to troubleshooting a slow connection, latency, jitter, and packet loss, and Internet speed testing for methods and limitations. Run substantial throughput tests only when appropriate and coordinated; they can consume significant capacity.

05 / Interface health

Check for changes in counters.

If you manage the equipment and can safely do so, record link status and interface error or discard counters at the connected adapter, firewall or router, and other relevant interfaces along the path to the provider handoff. Include the interface name, timestamp, uptime or last counter reset if available, and a second reading after a known interval.

An increasing counter can help narrow the investigation. A historical total alone does not establish a current fault, and counters may describe different events on different devices. Do not clear counters or restart equipment before preserving evidence unless your incident procedure or the responsible engineer directs it.

06 / What changed?

Include relevant changes and comparisons.

Note recent configuration changes, maintenance, power events, new equipment, or a failover, including approximate times if known. A change near an incident is useful context; it is not proof of cause.

Tell support what has already been tested and what happened. If available, share a known-good result from the same device and path. Avoid disruptive changes during an active incident unless they are coordinated with the responsible teams and a rollback plan exists.

07 / Protect your information

Share only what the investigation needs.

Do not send passwords, private keys, API tokens, session cookies, or other secrets. Screenshots, full configurations, and logs may contain customer data, internal addresses, usernames, or sensitive topology. Review and redact them according to your organization’s policy; use an agreed secure channel for sensitive material.

If redaction removes addresses or details needed to understand the test, label the replacements consistently and tell the engineer what has been omitted. Agree on a safe way to share any necessary original information.

08 / An example

A useful first message.

The following is illustrative. Replace the details with your own observations; you do not need every item to request assistance.

Keep the ticket reference and update support if the impact changes, service returns, or you find new evidence. Ask how updates and escalation will be handled if the issue remains unresolved.