A Telecom Software Vendor Pairs Files.com With Zendesk for Revenue-Critical Telecom Diagnostics

A telecom charging software vendor builds the converged charging platform that mobile operators run their subscription revenue through: the system that rates and charges calls, data sessions, and subscriptions in real time, as they happen. Its global support organization stands behind the product those operators bill through. When a charging system misbehaves, revenue is at stake immediately, and root-cause investigation runs on data: large logs and diagnostic files that have to cross between the operator's environment and the vendor's engineers working the case. The exchange also has to remain ready for external engineers who might not use it for months, then need it immediately.

Escalation Data That Email and Tickets Were Never Built to Carry

Before Files.com, that data traveled through email and the ticketing system. Zendesk is the support organization's system of record for escalations, and it is good at that job. Neither it nor email was built to carry large diagnostic files, and the logs from a real-time charging system are large. So the most time-sensitive work the support organization does opened with the wrong problem: engineers on both sides of an escalation spent the first stretch of an investigation working out how to move the file instead of reading it, while an operator's revenue system misbehaved.

The diagnosis was simple: the vendor was asking channels built for conversation to carry data.

Engineers Who Do Nothing for Months, Then Need Access Immediately

The fix was harder than it looks, because of who has to use it. The people sending those files are not the vendor's employees. They are operator-side engineers, spread across customers worldwide, and their usage pattern is defined by the incidents themselves.

That pattern rules out anything set up per incident. The exchange has to face external users, hold their access ready through months of silence, and absorb a burst the moment an escalation lands. And a support organization for a revenue-critical product has no business running its own transfer infrastructure on the side. What the vendor needed was a hosted exchange with accounts provisioned ahead of need, controlled access for external engineers, and a place beside the ticketing system rather than instead of it.

The vendor selected Files.com as that host, and the exchange has run on it for years.

Zendesk Keeps the Ticket, Files.com Carries the Data

The design is a division of labor. The escalation lives in Zendesk, where it always has. When the data outgrows what a ticket can hold, it moves through a dedicated site on Files.com, which exists for exactly that job.

Access is what makes it work at this population. The vendor runs sign-in through Okta, with SCIM provisioning keeping accounts in step with its directory, and several hundred operator-side and support engineers hold standing accounts on the site. Access exists before the incident does. Storage on the site stays light, because the files serve an investigation and then their job is done: the site is a standing channel, not an archive, and its value is that it is ready.

Nearly a Decade in Production With Nothing to Rework

With the Files.com channel in place, the vendor replaced an exchange improvised over email and ticket attachments with one that is ready before the incident starts.

• Large diagnostic logs can move as soon as an escalation begins, so engineers can start reading the data instead of spending the opening stretch arranging a transfer.
• Mid-escalation access is a sign-in, not a setup request. An operator engineer who has touched nothing for months uploads the logs the moment they are needed.
• Diagnostic data from operators' charging systems no longer travels by email.
• Growing the operator base does not mean building anything. A new customer's engineers are provisioned onto the same exchange that already serves every other operator.

The workflow has also survived time and turnover. Its current owner inherited it and has never had to rework it.

The Ticket Never Has to Be the File System

That is the lesson the vendor's setup carries for any support organization: the ticketing system does not have to carry the data. Keep the ticket where it is, and put a dedicated file layer beside it.