How We Built Our Own Ticketing System Over 12 Years in IT Support

In 2007, we founded IT-Premium and started tracking client requests in an Excel spreadsheet. Within a month, it was clear — this doesn’t scale.

Today, our in-house system handles hundreds of tickets daily. Over 12 years, it’s been completely rewritten several times. Each time — because we outgrew the previous version.

Why Not Zendesk?

We tried it. Freshdesk too. But we kept hitting the same problems:

SLA keeps ticking even when the client goes silent for a week. No integrations with our tools. The interface lags on every click.

We could have lived with it. But we decided to do it our way.

What We Built

SLA Pause

In typical systems, the clock never stops. Waiting three days for a client response — SLA is burning. Waiting for a vendor to send a license — also your problem.

We did it differently. When a ticket moves to waiting status — SLA stops. The client sees how much time we actually worked. The team doesn’t get unfair “overdue” flags. Simple and fair.

Messenger-Like Interface

Rails + Hotwire + WebSocket. Comments appear instantly. Statuses update without page reload. New tickets drop into the list automatically.

Anyone who’s worked with old ticketing systems and the “refresh page” button — knows the difference.

Notifications Where the Team Lives

Slack, Telegram, Mattermost — depends on where the team works. Plus integration with our password management system. Open a ticket — client credentials are already at hand, no searching needed.

Time Tracking on Everything

Every action is logged with a timestamp. We know which task types eat the most time. Which clients generate the most requests. Where the process gets stuck.

This data isn’t for management reports. We actually use it to understand where time goes.

Why Rails From Day One

  1. The alternatives — 1C or PHP frameworks. 1C would have been a maintenance nightmare for years. PHP wasn’t inspiring either.

Rails 2 seemed risky then. Young framework, few specialists in Ukraine. But we made the bet — and it paid off.

Since then, the system has survived Rails 3, 4, 5, 6, 7. Each upgrade takes a few weeks of work. But it’s worth it. Modern stack, current practices, development speed.

Now we use Hotwire instead of piles of JavaScript. Vanilla Rails, as DHH says. It works.

What the Numbers Say

  • 171,718 tickets processed total
  • 318 client companies over the years
  • 180 active clients today
  • 6,900+ employees receiving support

12 years of continuous operation. Not a single “everything crashed, data is gone.”

What’s Next

We’re rewriting the UI. The old Metro-UI-CSS is retiring.

Experimenting with AI for ticket classification. For now — just experiments.

Expanding analytics. We want to better understand patterns in client requests.

FAQ

Can we order such a system for our business?

If your processes are very similar to ours — reach out! We can also help you choose and configure ready-made solutions for your business.

How long did development take?

The first version was ready in a few months. But the system has been continuously evolving for 12 years — it’s an ongoing process.

Why didn’t you switch to a ready-made solution later?

Our system fits our processes perfectly. Migrating to another solution would mean losing unique features and historical data.