192 Comments

I had our product development team build our Help Center using custom code and APIs to give the 'illusion' of multiple levels, so the information can be segmented the way I needed. Unfortunately, that caused severe limitations with API calls and translation methods. Months of development work (that is slow and buggy due to ZD's own APIs, mind you), all because flexible multi levels are not supported. UUUUGGGGGHHHHH!

I agree with the need for subsections as it will greatly help in organizing articles in the knowledge base. Sure we would want the users to just search, but there are a lot of users who like to drill down and look for the article rather than searching. This would also make the Help Center look and feel cleaner. Otherwise, we would have to make several categories or sections. This would just confuse the users and they would simply not use the system at all. I have seen this type of behavior with users on several applications. Subsections would be more of an added value to Zendesk than it would take away from it. Thanks.

Same here.. Very much in need of subsections or nested ones. Don't care how it's solved. Just as long as we're finally presented a solution for this - and many other things I might add..

I'm growing a little tired of the gruesome time it takes for Zendesk to provide customers with what is clearly needed.. 2 years? and in the mean time not a thing has changed? Maybe Freedesk is more willing to provide its customers with proper service.. for half the price.. It is becoming very unclear to me why we pay so much for the enterprise version while customer service (and satisfaction) is below average..

I'll gladly provide an update although I fear I am not the bringer of positive news. I really wish I could give you the update that this is coming very soon, but it's looking a bit more complicated than that.

First off I want to make it clear that we completely understand the need. It really is difficult to organize your content with the two levels we have. We have the same problem when it comes to our own Help Center and I know that it has proven a challenge to our content writers, although we've so far managed to get it to work with 2 levels.

The reason why we have yet to fix this is the sheer size of changing it. Not just in terms of engineering, but also just figuring out how we can build the right thing that works for all the use cases.

The two levels are built into the core of Help Center. They were built in a way that makes them impossible to extend with more levels. Also, we've seen that more levels might not be the right solution. Some customers require more levels, some less and some the amount we have today. The conclusion so far is that we need something that is fully customizable so you can have any number of levels and truly build up the categorization you need.

We also see a need for publishing the same article to multiple categories, which means that we need to find a way to make that work with search, breadcrumbs and making sure that you can measure the performance of an article across categories and within specific categories. There are plenty other things we need to tend to, those are just a few examples.

We need to tie all these things together before we even embark on building it. We are indeed thinking about how we can achieve this, but it will be a while before we can get all the lose ends tied together.

From there comes actually building it. Since this is built into the core it will require a lot of work to get it changed. It's not impossible, it will just be a very long project.

So we definitely acknowledge the problem and we've started to do all the research needed to actually understand how we can change this - both product wise and engineering wise. Unfortunately the timeline is looking very long, but I wanted to be completely honest about the challenges ahead and where we are today.

Thank you for your response and upldate. For me, it prompted some additional questions and concerns as I read it. I'll iterate below:

This issue was opened almost 2 years ago. It has a considerable amount of user-voiced support (> 60 comments in support of the enhancement).

Based on the reply above, it appears that Zendesk does not yet have a grasp of their user's needs or requirements around this.

The fact that "it will be a while before we can get all the lose ends tied together" makes me wonder what level of support Zendesk is committed to providing in the way of substantial future enhancements to its platform. This comment does not minimize my appreciation for the ongoing incremental enhancements and bug fixes.

"They were built in a way that makes them impossible to extend with more levels" This is not a comment that gives me confidence about the platform or the level of engineering in the past, or perhaps, available for the future.

Timeline

"and we've started to do all the research needed to actually understand how we can change this - both product wise and engineering wise"

When will the research be completed? Is there a goal date?

Where are the surveys of users from this list, gathering requirements? Your users can be one of the most substantial points of research input.

When will the research be completed? Is there a goal date?We do not know when research will be completed. When you don't have a clear picture of the problem you are trying to solve, it's difficult to say when you're gong to solve it. The research intends to solve the problem, after which we'll start to actually build it.

Where are the surveys of users from this list, gathering requirements? Your users can be one of the most substantial points of research input.We have started with conversations. I talk to many different custmers about this. The problem here isn't so much to understand it from a customer perspective. The problem is to understand how we can solve it from a product perspective. What can we build that will effectively solve the problem? What can we build with our current architecture? What can we do if we change the architecture? What architecture needs are requires? What does changing the architecture mean to existing customers? What do we do with migration from the old way of classifying your content to the new way? etc.

Where is this on the Zendesk road map?I am not entirely sure what you are asking here. As mentioned we have yet to figure out how to build this and how long it's going to take, before we can start to talk about potential timelines, which directs me to your next question.

What is "very long"? 6 mo? 6 yrs?It's difficult to say, but I would say at minimum a year. It all depends on what solutions we reach, how we are going to build them, which resources we have available (etc.) which goes back to conducting research.

Regarding your other comments, then I would like to point out that we actually do understand the user requirements very well. There are just many different use cases that we then need to make sure that we solve with the same solution. We don't want to spend significant time building something that doesn't solve the problems. We should make sure to have a solid solution that we know will work, before we start building it. We are definitely committed to solving this problem, but it's difficult to commit to solving it before you truly understand it. That's what we are working on.

Luckily we learn from our mistakes. The reason research and finding a solid solution is so important, is because we don't want to end up in a situation like this again. Imagine we just added another level. Then we could spend a lot of time building that, but it wouldn't really solve the problem and would significantly delay a real solution. We do not want to make that mistake again.

We want to do the right solution and we'll only do that by truly understanding the problem from all possible perspectives.