Ticketing for software houses: clients and projects

A software company has a problem that a pure support provider does not: requests come from many clients, but they are about products that are yours. “The export is broken”, said by three different clients, may be one configuration mistake, one defect affecting everyone, or two unrelated things with the same name — and the way you divided your requests decides whether you notice.

This guide is about that division: which axes exist, which one to pick first, who should see what, and where support ends and development begins. It holds with any tool, including a shared spreadsheet.

Customers and products are two axes, not one

The first thing you discover when organising a software company’s requests is that there are two axes and they cross. One client uses three of your products; one of your products is used by thirty clients. Any structure that acknowledges only one of them will make you look for the other by hand.

The two questions you get asked, and must be able to answer in seconds, are exactly one per axis:

• By client. “How many open requests does this client have, how long have they been waiting, and what did we last tell them?” This arrives before a renewal or after a complaint.
• By product. “How many times has this been reported, and since when?” This decides what goes into the next release, and it is the first one lost if you divided by client only.

The point is not to keep two structures: it is to have one axis that divides and a second one that filters. Choosing one as the primary division and the other as an attribute of the request solves ninety per cent of cases; trying to keep both as divisions produces twenty empty containers and nobody knowing where the new request goes.

How to divide: by client, by product or by contract

All three divisions work, in different situations.

• By client when clients are few and large, each with their own contract, contacts and response times. It makes “what did you do for us this year” easy to answer, and it is close to mandatory if support is billed separately.
• By product when the same application is used by many clients and requests resemble each other. Whoever answers specialises in the product rather than the client, and duplicates are noticed the same day.
• By contract or phase — onboarding, maintenance, custom work — when the same company writes to you about very different things that reach different people and carry different urgency.

The practical rule: divide by whatever changes who answers. If the product decides the recipient, divide by product; if the client does, divide by client. Everything else is a filter.

Who sees what, and why it matters more than it seems

In a software company, visibility stops being a matter of tidiness the day the first non-employee arrives: a contractor, a supplier working on one module, an intern. From then on “who sees what” is a commitment you made to your clients, often in writing.

Three questions, best answered before you have the problem.

1. Can a contractor see your other clients? If the answer is “no, but it depends on the interface”, the real answer is yes. The boundary has to hold in the list, in search, in notifications and in any API.
2. Is what you say to each other separate from what the client reads? “This is the 2.4 defect, we have known since March” must exist on the request and must not be visible to the client.
3. What happens when someone leaves? The requests they held must stay, and their access must close at the same moment. Those are two separate things and they need separate checking.

Support and development are not the same list

This is the first mistake a software company makes, because it looks like a saving: using one tool for client requests and for development work. A few months later the list holds “I can’t sign in” next to “refactor the payments module”, and it serves neither purpose.

The two lists run on different clocks (one is measured in hours, the other in releases), answer to different people (one to a person who is waiting, the other to a plan) and have different lifecycles: a support request closes when the customer has been served, even if the defect underneath stays open for two months.

The link between them, when you need one, is a line written by hand on the request: a reference to the development item it concerns. It is less elegant than an integration, and in exchange it never breaks and it never forces clients into the tool where you plan your work — which is the thing to avoid first.

Codes and history: what you quote six months later

Two details that look minor and are exactly what separates support that lasts from support that does not.

The first is the readable code. A request needs a reference you can say on the phone without spelling it, carrying an indication of the client or the product, and never reassigned to something else. A code quoted in a release note or in an email from a year ago must still point at that request.

The second is that history does not belong to whoever wrote it. The conversation with the client, the internal notes, the changes of owner and the closing date must remain readable when the person who looked after that client no longer works with you. This is the technical reason email support does not hold: there, history lives in a mailbox, and a mailbox belongs to somebody.

When you need a larger product

Not everything a software company wants is done by a ticketing system, and it helps to know in advance which requirements take you out of this category of tools.

• Repository links — commits, branches, versions, releases — or two-way synchronisation with a development board: that is the territory of development tools, not support tools.
• Custom fields on the request, such as environment, version or module, held as data you can filter on rather than as text in the description.
• Automatic rules that route, reassign or close on their own when conditions are met.
• Inbound email, that is requests born from messages sent to a mailbox already in use, and several channels at once — phone, chat, social.
• Time tracking, to bill from the request.

Each of those is a legitimate reason to buy a larger product, and every larger product asks for configuration, training and a higher price per person in return. The honest question is how many of those lines you actually need today.

How this maps to OglutTicket

In OglutTicket the division is called a project, and it is the only one: a project per client, or a project per product, and the two coexist in the same workspace. The second axis comes from the product and the department attached to the project, which are what you filter on without building views.

Everything described above follows from the project: a readable prefix and numbers that are never recalculated, the people enabled on it — someone not enabled does not see those tickets because the query does not return them, not because the page hides them — the clients associated with it, and response times if you choose to switch them on. Internal notes are excluded by the server before the client’s page is composed, and removing someone’s access to a project clears their open assignments there.

The limits are the list above, and they are declared: no repository link, no custom fields, no automatic rules, no inbound email and no time tracking. It is not a tool for tracking defects in your software: it collects what arrives from outside.

The commercial page for resellers, including software companies putting their own name in front of clients, is white-label help desk. If what interests you is getting every request to a person, there is the guide on assignment; if you support several companies running software that is not yours, the right one is on the requirements of a multi-client help desk.