General support guidelines

If you run into an issue using CHILI publisher, you can report this through our ticketing system:

You can log in with the credentials you received at your onboarding.

We strive to give fast and high quality support. To do so, we make the best possible use of our resources. But there are also some simple steps you can follow to help us help you even better.

Use the documentation

We have spent quite a bit of effort including both common and less common questions in the documentation as of version 3. And we will continue to do so. Starting the 3.0 release, any request for information ("How do I ...", "Where do I find ...") which is also relevant to other CHILI publisher customers will be answered with one or more links to relevant documentation pages. If we think an existing page is relevant but can't be found easily, we'll make that so. If no content exists, we'll write it on the spot. So you can expect the available content to grow even more!

Centralized contacts

If at all possible, we would appreciate any customer trying to organize a limited amount of persons within the company to be responsible for submitting support requests. This can potentially greatly improve not only our own availability, but also your internal response times. Many of our customers, for example, work with end customers / types of documents which remain relatively consistent across multiple projects. Having your own, centralized, person(s) to act as a "knowledge base" in such a case can have significant impact on your time to market.

This goes doubly so for colleagues newly exposed to CHILI publisher. The main purpose of the support system is to provide support. Using it as a free training mechanism will drain resources which you surely can agree are better spent on other tasks.

Of course we aren't the type of company which would deny a support request. We understand the needs of a service provider, and we understand that your internal "knowledge base" (if you've built it up) also needs to go on holiday on occasion!

Useful information

Try to anticipate the fact that we might not know what you mean when you report an issue like "I try to edit something, but it doesn't work". This will only result in delayed resolutions/answers, because our first standard reply will have to be: "What are you trying to edit, what are you expecting to happen, and what doesn't work?". This may be an extreme example, but it does actually happen (you know who you are! But we still like you anyway ;)

Also in less extreme examples, too much information is always better than too little. Of course within reason. We don't expect you to spend 15 minutes gathering information before reporting a potential issue. But when you do, please try to include at least the basic information. Much of it is usually within easy reach for you:

Which server? (if you have multiple)
Which environment?
Which document / workspace / PDF export setting / ..., if applicable ?(TIP: each document in the system has a unique ID number, this is the fastest way to find a document online)
For issues related to the conversion of Indesign documents it is usually necessary to upload the original with the issue. When you do so, please create an Indesign package of the document, so we have all the assets we need at hand.
Is it easily reproducible / consistent, or is it intermittent?
It more often than not helps to include detailed steps which we can follow to reproduce it (click here, move mouse there, click there). If it's a globally present issue, it probably means we never considered clicking first here and then there. So we might not after your initial report either. But of course, on any given ticket with more than just minimal information, we will make a reasonable effort to try to reproduce the issue without having to come back to you for more information.
A couple of quick screenshots of where the issue occurs never hurt! If you make any, try to include enough context information when it might be relevant (don't just caputure the area where the issue occurs, but include a larger portion of the screen). Sometimes this information helps us to very quickly recognize a symptom,
If the steps are too complicated too describe (or would take too much time), a quick video screen capture might prove useful
Try to be as accurate as possible in your assignment of the ticket's severity. We do understand that a request for information can be high priority to meet your important deadline (for a project or even a demo). But in such a case: try to include a bit of context on the importance so we can correctly prioritize it internally. A centralized reporter also helps our support staff in this regard.

A very good way of making us understand what is happening on your side, you could make a little screen capture. Together with your explenation or the issue, this will give a very clear understanding.
A lot of these tools are freely available on the Internet. One we found is "Jing".

http://www.techsmith.com/jing-features.html

See how to capture with Jing?

JingCapture - Broadband.m4v