A useful phone fault report records when the problem happened, the site and device, who is affected, what happens on calls in and out, any error wording and recent changes. Send the observations you have rather than waiting to complete every field. This is a general starting point; your provider may need other details.
For example, reception in a hypothetical Keysborough office might miss incoming calls while nearby phones still ring. Report that difference without assuming the handset is broken. It gives the provider something specific to investigate.
A fault report describes what happened. These six headings organise the observations; they do not prove a cause or replace your provider’s reporting instructions.
Use a time zone even when reporting locally, such as Australian Eastern Daylight Time (AEDT). It helps the provider compare your note with its records. If a device clock looks wrong, report that rather than silently correcting the time.
Keep observations separate from possible explanations. You can report that a handset did not ring without knowing whether the cause lies in the phone, its settings or another part of the service.
“One phone” and “the whole office” describe different affected groups, not different proven causes. If colleagues report the same symptom, include that. If nobody has checked another site, say its status is unknown. A provider can then investigate without mistaking an assumption for an observation.
Instead of writing “the internet must be down”, describe the phone problem and any internet interruption you noticed. If you include a theory, label it as a possibility. Do not treat a recent change as a confirmed diagnosis.
You do not need to prove the fault before asking for help. Rebooting the router, unplugging lines or changing settings are not steps you have to take first. Emergency numbers are never a test line. If you have already tried something, say what you did and what happened.
This hypothetical report uses a placeholder site and extension, with no real customer numbers. It records ordinary calls already observed, not tests the reader must perform.
The example separates a caller’s account from what reception observed. It does not rule out a handset, configuration or wider service fault. If only one of those observations is available, send that rather than inventing the rest.
| Detail | Example observation |
|---|---|
| Time | First noticed Wednesday 14 October 2026, about 9.15 am AEDT; still happening at 11 am |
| Site and device | Head office reception, extension 101, desk handset |
| Affected group | Reception handset affected; two nearby handsets observed receiving calls; other sites not checked |
| Calls in and out | External caller reported hearing ringing, but reception handset stayed silent; an internal call rang; an outgoing call connected with two-way sound |
| Message | No error message noticed on the handset screen |
| Recent change | Network switch replaced on Monday afternoon; connection to this fault unknown |
Send the report the way your provider asks. Published routes differ. Telstra’s enterprise support, as one Australian example, takes faults by phone or through a signed-in portal. It also says you do not need to be an authorised representative to submit one. Your own provider’s instructions are the ones to follow.
Do not put customer numbers, recordings or account details in public comments or an open discussion. A provider’s verified private support form is different from a public page. Use the route your provider specifies and share only the information relevant to the fault. Never include your password or passphrase in the report, including through a private channel.
A call already made during normal work can provide an example. Note its date, time, direction and the extension involved. Keep any customer number out of public material; if the provider needs the full number to locate a call, follow its secure submission instructions. Do not create a test call, recording or network capture just to complete this checklist.
The provider may request more information suited to your system. Follow its authorised support process for any later technical work. This checklist does not require you to open an administrator account, change logging or collect network traffic. It also carries no promise about response or repair times.
Keeping calls answered during an outage is a separate planning question. The guide to what happens to business phones when the internet goes down covers continuity options and planning for future interruptions.
For help with a current fault, Sixfam publishes its support contact details on its support page. Use that published route to discuss the problem and any further information needed. The team supports business telephone and network systems. Call 03 9200 2800.
No. Report what you can see and hear, and leave the diagnosis to whoever can look inside the system. A clear description of the symptom is worth more than a confident guess at the cause.
Write down when the problem appeared and when it cleared, with the same time zone each time. Record any repeated symptom or recent change without assuming the two are connected. Send what you have even if there is no clear pattern.
A recording is not required for this general checklist. Start with observations from a call that happened during normal work. If support later requests sensitive material, check the request and its secure submission route before sending anything.
Designed & Developed by CJ Digital