What we need to know when something breaks
Nearly half the fault reports we receive arrive without enough detail to start work, which means a phone call before anything gets fixed. Ninety seconds of detail at your end regularly saves an hour at ours — and gets your problem solved the same day instead of the next one.
On this page
On this page
When a report says "printer not working", the first thing that happens isn't a fix — it's us ringing to ask which printer, what it's doing, and whether anyone's tried anything. That round trip is where most of the delay in a support job lives, and it's entirely avoidable.
If you only read one thing
- Name the thing and where it is. "The printer" could be one of eight. "Reception printer, admin office" can be worked on immediately.
- Say what it's actually doing, not just that it isn't working. Error message, light, noise, blank screen — the symptom is the diagnosis.
- Tell us what you already tried. Stops us repeating it, and tells us a lot about the fault.
- Give us the time it happened — especially for anything intermittent. Times let us go straight to the logs.
- Say whether it's still usable. "Working but slow" and "dead" are different jobs with different urgency.
01 — The essentialsThe five things we always need
Whether you use the fault form, send an email or ring, these five get a job moving. Everything else is a bonus.
| What | Instead of | Try |
|---|---|---|
| What it is | "The computer" | "The reception PC" · "the bistro till" · "Mic 2 in the function room" · "the TV above the bar". If there's an asset label or sticker on it, that's even better. |
| Where it is | "Out the back" | Name the room the way your staff name it. We know your venue, but we don't know which of four back offices you mean. |
| What it's doing | "Not working" | "Says offline in the print queue" · "powers on, no picture" · "crackles when you get more than 3 m away" · the exact error message, typed out or photographed. |
| When it started | "A while ago" | Date and, if you can, the time. Add anything else that happened around then — a blackout, a storm, a tradesperson on site, a new TV, someone moving furniture. |
| What you tried | Blank | "Turned it off and on" · "changed the paper tray" · "swapped batteries" · "nothing yet". All three are useful answers, including the last one. |
Take a photo of the error message, the screen, the flashing light, the blank display. It removes all the guesswork about what the message actually said, and it takes five seconds. Attach it to the request. For anything on a screen, photograph the whole screen rather than cropping to the error — the surrounding context often tells us more than the message does.
02 — SymptomsHow to describe a fault usefully
You don't need the right technical words. You need the observable facts — what you can see, hear and press. A good report reads like a witness statement, not a diagnosis.
- Describe rather than interpret. "The screen is black but the box behind it has a blue light on" beats "the player's died" — the second is a conclusion, and it's often the wrong one.
- Say how often. Once? Every time? Only on Fridays? Only when the function room is in use? Frequency narrows a fault faster than almost anything else.
- Say how many. One till or all four? One screen or the whole venue? One staff member or everyone? That single detail decides whether we're looking at a device or something upstream of it.
- Say what changed. New equipment, moved furniture, a power outage, an electrician in the roof, a delivery driver who unplugged something to charge a phone. Faults rarely appear from nowhere, and this is the single most useful sentence in any report.
- Quote the message. "Cannot connect to server" and "no signal" send us to completely different places. Don't paraphrase.
- Tell us who noticed. With a phone number if it isn't you. We often just need one clarifying question answered by the person who actually saw it.
03 — The hard onesFaults that come and go
Intermittent faults are the most frustrating kind and the most dependent on your notes. A dropout that has already fixed itself leaves us with nothing to look at — unless we know when it happened, because then we can go to the logs for that window and see what the equipment saw.
If something is dropping out, keep a scrap of paper next to it for a week:
Worth writing down each time it happens
- Date and time
- To the nearest five minutes. "Fri 18th, about 6:15pm"
- How long
- "Out for two or three minutes, came back on its own"
- What else was going on
- "Bingo was running, function room in use, raining hard"
- What was affected
- "Just the two tills at the bistro end, the others were fine"
- Who saw it
- "Reported by the duty manager"
Three entries like this are worth more than a fortnight of "it keeps dropping out". Send the whole lot in one request and we can usually find the pattern without setting foot on site.
A fault that drops out twice a week for a month usually had a cause we could have found in the first week. By the time it's constant, the equipment may have failed properly — which is a bigger job and often a bill for hardware instead of a remote fix. Report the second occurrence, not the twentieth.
04 — ChannelRing us, or log it?
Ring 1300 755 242
- You can't take money — tills or EFTPOS down
- Phones or internet out across the venue
- Anything stopping trade right now
- A function or event on today is affected
- Anything with a safety or security angle
- Water, smoke or a burning smell near equipment
Log it in writing
- Anything that isn't stopping trade today
- Intermittent faults with your notes attached
- A device that works but is annoying
- New equipment, moves and changes
- Access and account requests
- Anything you want a record of
If you ring for something genuinely urgent, put it in writing afterwards too — or ask us to. A phone call fixes tonight; the written record is what stops the same thing happening in three months with nobody remembering what was done.
And if you're not sure which it is: ring. We would much rather take a call that turns out to be routine than find out on Monday that Saturday's function ran without microphones.
05 — PriorityWhat "urgent" actually means
Marking everything urgent has exactly the same effect as marking nothing urgent. Here's how we read it:
| Priority | Means | Examples |
|---|---|---|
| Urgent | Trade has stopped or is about to | No EFTPOS, no tills, no internet, no phones. A function tonight with no sound. Anything unsafe. |
| High | Real operational pain, work continues | One of three tills down. Kitchen printer out. A screen dark in a prominent spot. One staff member unable to work. |
| Normal | Needs doing, not today | A slow computer. New account for a starter. Second monitor to connect. A speaker that's too quiet. |
| Low | When we're next on site | Cable tidy. Relabelling. "While you're here" items. Nice-to-haves. |
If something has a deadline that isn't obvious from the fault itself — a function on Saturday, an audit on Monday, a board meeting Thursday — say so in the request. We can't prioritise around a date we don't know about.
06 — CompareGood and bad, side by side
These are the shapes we actually receive. Same faults, different outcomes.
Poor — needs a phone call before anything happens
- Report
- "Printer not working"
- What happens
- We ring to find out which printer, what it's doing, whether it's the one on the server, whether anyone else can print, and whether it's ever worked. Half a day gone.
Good — can be worked on straight away
- Report
- "Reception printer (the big HP in the admin office) shows Offline in the print queue since this morning. Admin printer is fine and prints normally. Turned the printer off and on and restarted the PC — no change. Nothing was moved that I know of. Photo of the screen attached. Not urgent, but the membership renewals need to go out Thursday. — Sam, reception, 0400 000 000"
- What happens
- Remote session, checked and usually fixed before lunch — because every question we would have asked is already answered.
Poor — an intermittent fault with nothing to work from
- Report
- "Internet keeps dropping out"
- What happens
- Nothing is wrong when we look, because it isn't dropping out right now. We either wait for it to happen again or attend site and find nothing.
Good — same fault, solvable
- Report
- "Bistro tills dropping offline. Happened Fri 18th ~6:15pm for about 3 minutes, Sat 19th ~7pm for 5 minutes, and again Tue 22nd ~6:30pm. Both bistro tills each time; front bar tills unaffected. Busy service each time. Nothing new installed. Duty manager noticed it first."
- What happens
- Three timestamps and a pattern — busy evening service, one area only. We can check the logs for those exact windows before going anywhere near site.
Every good example above is written in completely ordinary language. There's no jargon in any of them. The difference isn't expertise — it's the five facts.
07 — QuestionsThe ones we get asked
Should I try to fix it myself first?
Try the safe basics — turn it off and on, check it's plugged in and switched on at the wall, check the obvious. Then stop and tell us what you tried. What we'd ask you not to do is pull cables out of network gear, reinstall software or start changing settings; that turns a small fault into a longer one. We have short guides for the common ones — printers, internet and tills, slow computers and signage screens.
Who should be logging faults?
Anyone who spots one, ideally the person who saw it. What we'd avoid is a chain — a bartender tells a supervisor who tells the duty manager who emails us three days later with a paraphrase. Detail evaporates at every hop.
What if I don't know what the thing is called?
Describe it and photograph it. "The grey box behind the TV in the sports bar with three cables in it" is a perfectly good identifier. Never guess at a name — a wrong name sends us to the wrong device.
Should I report something that fixed itself?
Yes, please — with the time it happened. Self-resolving faults are usually the early warning for something that will fail properly later, and the time stamp is what lets us find the cause while it's still cheap.
Can I just send a photo with no words?
It's better than nothing and we'd rather have it than not. Add one line about which device and where, though — a photo of an error message doesn't tell us which of your machines it's on.
Will you tell us what was actually wrong?
Yes. Every job gets written up, and if a fault is likely to recur or points at ageing equipment we'll say so rather than quietly patching it again. If you ever want the history on a particular piece of kit, just ask.
08 — Print thisKeep it by the phone
Print it for the duty manager's folder or next to the office computer. It's the five facts and the ring-or-log call.
Reporting a fault — what to include
Cyberry Know-How · cyberry.com.au/know-how
Always include
- What it is — name it specifically
- Where it is — the room your staff call it
- What it's doing — the exact message or symptom
- When it started — date and time
- What you already tried
- Is it still usable?
- One device or several?
- Anything that changed recently
- Who noticed, and their number
- A photo of the screen or error
Ring, don't email
- Tills or EFTPOS down
- Internet or phones out venue-wide
- Anything stopping trade now
- A function or event today affected
- Anything unsafe
Intermittent? Log each time
- Date and time to the nearest 5 min
- How long it lasted
- What else was happening
- Exactly what was affected
Last reviewed 25 July 2026. Written from twelve months of real support requests across the venues we look after. If your club has its own incident or fault process, follow that first — this is about what makes the request itself actionable once it reaches us.
Something broken now?
Ring us. We'd rather hear about it early.
1300 755 242 for anything stopping trade, support@cyberry.com.au for everything else.