Zendesk has become the platform of choice for hundreds of thousands of companies looking to deliver fantastic customer experiences. At the same time, its feature set has expanded considerably over the last few years, with innovations such as Zendesk conversations, improvements on Zendesk Guide, chatbots, etc.

These innovations have transformed Zendesk into something more than just a ticketing system: it's now a robust business application software at the center of customer experience.

And, like any software, there are costs associated with it. In fact, one of the less-discussed costs when managing software like Zendesk is the cost of not paying your technical debt.

What is technical debt?

According to Wikipedia, technical debt is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

In layman's terms, this means the cost of doing something quick and dirty now instead of spending more time to develop a more robust solution. 

The term debt is used because you are borrowing time. The quick and dirty solution will take less time, but that borrowed time must be paid later (you’ll see how soon).

An example of this would be creating a new Zendesk Support trigger to satisfy an urgent business requirement. You might be tempted to create the trigger as fast as possible without considering the order in which the trigger executes.

Reviewing the trigger order and deciding where the trigger fits into that order takes time, and you may not want to spend that time right now. So you create the trigger and move on. 

Right there, you've borrowed time. 

‍

The cost of technical debt

The problem with quick and dirty solutions like the ones described above is that, over time, it becomes harder to remove them.

Going back to the previous example, the more triggers you add without considering the trigger order, the harder it will become later to understand that order and organize it if needed.

Every minute you borrow by using a quick and dirty solution, plus any minute that passes since that solution was implemented, will become the cost of paying that debt. 

In our example, you might need to spend days (>$,$$$) or even weeks (>$$,$$$) trying to make sense of the trigger order later down the line. 
‍

‍

Sometimes, the cost of paying technical debt becomes so large that it becomes challenging to justify it to your business users.

For example, how do you tell your business users that you can't create more triggers for the next two months because you need to use that time to reorganize them all?

‍

Technical debt is not always bad

Despite the scenario described above, technical debt is sometimes a good thing. In many scenarios, it can be used as a tool to iterate faster.

For example, you might not want to spend too much time on a solution that you know is temporary or a solution that is only a proof of concept. In those cases, it makes sense to release something quickly.

However, you must be mindful to avoid the temptation of leaving the quick and dirty solution there for too long. As I said earlier, the longer it stays there, the higher the cost of paying the technical debt.

Technical debt in Zendesk

With all that said, here are some examples of technical debts in Zendesk. Keep in mind that, as I said above, some of these might be on purpose, but they might incur too much cost down the line:

• Custom ticket fields without descriptions
• Duplicate custom ticket fields
• Creating triggers without considering the trigger order
• Ticket fields that are not used anywhere
• Tags that appear in tickets but are not used in reporting, automations, or triggers
• Triggers or automations that can never execute because their logic is no longer valid

‍

How to tackle technical debt

To tackle technical debt in Zendesk, you need complete visibility into your Zendesk configuration. There are a few options here:

• You can use the rule analysis area to see if any business rules don’t look right, where tags are being used, etc.
• You can also use the audit log to review any recent changes and see if any of those changes are not up to a certain standard.  

These are a good starting point, however, to really figure out what technical debt exists in your Zendesk account, you need complete visibility into what's in it, and that’s where Salto can help.

With Salto, you can have that visibility, for example:

• You can see where all your fields and tags are being used
• You can find triggers that would never run because their logic is broken
• You can replicate your sandbox as many times as you need, which can help reduce errors that would occur when manually replicating configuration (a perfect recipe for technical debt)

‍

And there are a lot more use cases! 

But beyond using a platform like Salto, you must practice always being aware of the potential (future) cost of implementing a solution. Always ask yourself if a quick and dirty solution is the right solution now. How about in six months or a year?