Poor support handling can turn a fixable telecom fault into a long dispute. Treat queues, callbacks and ticket handling as evidence, not just frustration.
Key points
- Keep timestamps for calls, queue duration and abandoned attempts.
- Write down exact callback promises.
- Save ticket references and whether each was closed or escalated.
- Distinguish a technical support case from a formal complaint.
- Ask the provider to investigate its own call and CRM records.
Long queues matter most when they prevent a fault being reported or progressed
A queue is not automatically unlawful because it is long. The useful question is what consequence it had. Did the consumer fail to report a loss of service? Did the provider require phone contact for a task that could not be completed elsewhere? Did the delay extend an outage or prevent an engineer booking?
Record callback promises in testable terms
Capture who made the promise, the time, the stated callback window and the outcome. If a sales agent says technical support will call within 30 minutes, and a second agent later says the callback is escalated and will happen by close of business, those are two separate commitments.
Ask whether the callback was created, queued, assigned and completed
A useful complaint asks the provider to trace the workflow. Was a callback task created? Which queue received it? Was it assigned? Was an attempt logged? Was the number correct? Was the task closed without contact? These questions are more productive than “your support is terrible”.
Repeated ticket closure can distort the chronology
If a provider repeatedly closes a ticket and opens a new one, keep your own continuous fault timeline. The technical system's ticket boundaries do not necessarily define the duration of the underlying problem.
When to turn support failure into a formal complaint
Do so when the underlying problem is not progressing, commitments are repeatedly missed, the provider changes its explanation without resolving it, or you need a formal remedy and ADR clock. State: “Please treat this as a formal complaint under your complaints code, not solely as a support ticket.”
Evidence worth keeping
A missed callback is not automatically a standalone compensation claim
There is no useful shortcut that turns every missed callback into a fixed cash award. Its importance is usually evidential: it can show that the provider failed to progress a known fault, extended avoidable inconvenience, broke a specific service commitment or made it harder to register and pursue a complaint.
Keep the complaint proportionate. One late callback that caused no consequence is different from repeated promises that left a complete loss of service unresolved for days.
Build a contact log that can be audited
| Field | Record |
|---|---|
| Date/time | When the call/chat began and ended |
| Channel | Phone, webchat, app, email, social support |
| Queue | How long you waited before answer or abandonment |
| Agent/team | Name if given and department |
| Promise | Exact callback window or action promised |
| Reference | Ticket, fault or complaint number |
| Outcome | Called, not called, voicemail, ticket closed, engineer booked |
Phone screenshots and itemised call history are often enough to establish the timing. You do not need a transcript of every conversation before you can make a coherent complaint.
Two promises can be two separate failures
If one agent promises a callback within 30 minutes and another later promises contact by close of business, record both. Do not collapse the chronology into “nobody called”. Separate promises make it possible for the provider to check whether each workflow was created and why it failed.
Ask for the provider’s records, not just an apology
The useful investigation is operational. Ask whether a callback task was actually created, which team owned it, what target was entered, whether an outbound attempt exists and how the task was closed. If the answer is “we cannot see anything”, preserve that answer too.
A focused subject access request can later help where call recordings, CRM notes or callback-task data contain your personal data. Use a SAR to obtain evidence, not as a substitute for the telecom complaint itself.
Watch for the ticket-reset problem
Providers may open and close several support tickets for one underlying fault. Keep your own continuous chronology from first notification to final restoration. Otherwise the record can misleadingly make a week-long unresolved problem look like three short, unrelated contacts.
Ask the provider to state whether a new ticket represents a genuinely new fault or merely another internal container for the same unresolved issue.
If you cannot get the provider to register the complaint
Move from the technical channel to the provider’s published complaints route. State explicitly that you are making a formal complaint and ask for the complaint date and reference in writing. Current telecom ADR rules can also recognise sustained difficulty in registering a complaint, so preserve failed attempts rather than endlessly starting again.
Common support explanations, and how to test them
| Provider says | Check |
|---|---|
| “A callback was raised.” | When, to which queue, with what target and what closure status? |
| “We tried to call.” | Ask for the attempt timestamp/number and compare with your call log. |
| “The ticket is closed.” | Was the underlying fault actually fixed, and on what date? |
| “High call volumes.” | That may explain delay, but what was done about the missed commitment and resulting impact? |
| “Technical support is separate from complaints.” | Fine: ask complaints to investigate the support handling as part of the complaint. |
What to write
Turn “poor service” into answerable questions.
“Please identify each callback task created on my account, its creation time, owning team, target time, attempted-contact record and closure outcome. Please also explain whether the missed callbacks delayed diagnosis or engineer attendance, and address that impact as part of my formal complaint.”
Official sources