Hi, I’ve just tested Zammad at zammad.com and very impressed. Zammad is the best open source helpdesk (among over 30 open source systems tested so far), but there are several critical things, which does not allow us to start using it in our worldwide non-profit. Main thing is the ticket interface which is super non-user-friendly & misleading and email notifications to users & agents. Hope it is not too late to share this info.
Try to open ticket interface, imagine you see it first time and try to interact with the ticket. The most user-friendly and intuitive interface for now is HelpScout’s, check it, analyse it. In Zammad each step I’ve done in order to reply to the ticket was like an unpredictable adventure, I did not know what will happen if I click this or that button. The main principle must be: “The simpler - the better”.
We just can’t start using Zammad because our support agents in different countries will be unable to properly reply to the tickets without special education which is ridiculous. So advice for the Zammad team:
Put aside all seemingly important features, focus now only on bugs, emails to users and ticket interface, this is the most important part of the system, make it simple, self-explanatory and straightforward. It is difficult to dare to change something which seems to be ready, but sometimes it has to be done. Come together, discuss, redesign ticket page and make it perfect.
Let’s start:
I opened a ticket, typed the text and wanted to submit a reply to the user, but I could not find a big blue “Reply” button. There was an “Update” button in the lower right corner of the screen, I had no idea what it is for, it was located quite far from the “Reply” textarea. Finally I decided to click “Update” button and my reply was sent to the user. Now I learned that “Update” means “Reply”.
Solution: Make a real “Send Reply” button right under the reply textarea (see HelpScount) and another “Update” button in the sidebar. No need to mix “Reply” and “Update ticket status/parameters” functions.
After some time I learned that it was not a reply to the user. I’ve created a note to the ticket.
Solution: Agent must clearly understand what he is creating: a note or reply. Little tiny switcher Note-Reply-Call without any hover hints is not enough. Make three separate radio buttons to the left from the textarea: Note, Reply and Call. “Reply” must be default action.
After that I noticed a gear and pencil buttons with some colors on top without any hover hints. I still don’t know what this colors button with pencil is doing.
Solution: Add some explanation to the button or get rid of it. Only important elements must be present on the ticket screen. This is the most important screen of the whole system.
Now I needed info about the user who created a ticket: there was no user’s email displayed on the screen at all (!!!) I found a button with a man icon without any hover hint and user email was there.
Solution: Agent must always see user’s email and name (see HelpScout)
After that I noticed an arrow in the top right corner of the right sidebar. Arrow did not have any hint, so I decided that it will open next ticket, but it just collapsed the sidebar.
Solution: Add a hover hint or replace it with some more common “collapsing” element.
When the sidebar is open the bottom “Discard your unsaved changes” button seems to be completely disconnected from the ticket textarea where I’m making changes.
Solution: Place “Discard” button right under or above the reply textarea.
Now I noticed little tiny “reply” button under each user’s message in the thread with a bunch of other buttons without any hover hints (lock, arrow, I still don’t know what “right arrow” button means). I decided that this reply button will allow me somehow to reply to this specific user’s message. But this reply button just scrolled me to the reply textarea.
Solution: Add one “Reply” button on top instead of that “pencil-colors” button which will scroll to the reply textarea.
For me it was very difficult to distinguish between messages from user, my messages and notes in the thread. Ticket thread for now looks like a colorful mess with numerous small buttons and circles.
Solution: See how it looks in HelpScout and just do the same. Simple and clear.
TO field is not needed when replying to the ticket as I’m replying to the user and his email must be always visible somewhere on the ticket thread. There should be a link-button allowing to change user which is receiving replies to the ticket.
Solution: Again see how it works in HelpScout and do similar.
CC field is always visible when replying, this is a waste of space.
Solution: Display small “Cc” link which opens CC field.
When I clicked on the message in the thread two black areas appeared. This is the most unexpected and unusual “feature” I’ve seen in the system
Solution: Just show above each message in the thread: user’s name, date, channel (see HelpScout)
Email which user received contained only my reply to the ticket, but not user’s question. This is not acceptable, user must see whole ticket thread in each email he receives (see Gmail and HelpScout). Now it does looks like support agent cuts out previous email history and sends just his reply, which is not good.
Solution: It looks like already there is a ticket https://github.com/zammad/zammad/issues/816 for this.
I think he hit a good point that we saw in our rolling out, too.
The UI is quite good, improves a lot of things other applications struggle around for years already and looks a lot more up to date … BUT: users have problems when they need to “think” and things look (or even are) unintuitive.
So, please try to address these issues as they really decide whether users like the system or switch back to good old spamming of your mail account …
99.9% agreed. I love the Zammad UI, but there’s room for improvement especially in the (most used) ticket view. Most pressing issues are:
Customer name and email should be visible at all times. (When I type "Dear ", and have to point or click somewhere to find out the customer’s name, the UI failed.)
Reply should be the default action and stand out clearly. No extra clicks should be required to start a reply, the reply field should be there and ready to type.
Tab should close automatically after reply. This should be the default, or at least it should be able to configure it to be the default.
(BTW, the OP obviously hasn’t found out yet how bulk changes from the ticket list work, otherwise that would have made #1 in his list of non-obvious UI design.)
But only if the ticket has been closed. I am sure that all my colleagues will ask me why there are so many open tabs when the tickets are already closed.
I totally agree.
When answering more than 1-2 Tickets per hour, one gets totally annoyed by always have to follow the same ritual after typing the answer:
click arrow-up (to select macro)
click close (own macro: status closed - to avoid some more clicks to change status via dropdown)
slide mouse across the whole screen to the tabs list at the left
click the small (x) to close the ticket
I know there are keyboard-shortcuts, but that’s not the right way to solve the problem of a not user-friendly UI.
My proposal is: when the user clicks on the “reply” Link (that could be a little more conspicuous) to start typing an answer, zammad should automatically change the Dropdown “Status” to “closed” and activate “Close tab”.
This way, you still see the right status after opening a ticket – but when you decide to send an answer, the system sets a useful default for the next status of the ticket. After finishing typing, a single click in the right lower corner sends the message, closes the ticket status (what could be overridden by the agent while typing), and closes the tab. That’s exactly what is needed in >95% of the use cases.
But what if you want to clarify something about the ticket with the creator? A ticket should never be automatically closed just because you think your answer is good enough (imho)
Sorry, perhaps my description was a bit misleading.
I propose to change the dropdown “status” to “closed” in that moment, when the agent clicks on “answer”. While typing his answer, he has enough time to change it back to “open” (before saving&sending), in case he want to keep the ticket open.
In our workflow, we close >95% of the thickets after sending a response to the customer, so it would make sense to change this automatically for the (new) status on replying. This automatism was also implemented in OTRS.
As work around you could simply create a automation that closes all open tickets where the agent replied X (time) ago.
I know many systems that close the ticket automatically like 48 hours if no reply by the customer has been made. This spares you from manually touching the ticket again.
@chrisblech you have to think about what the majority of users need, not only which features fit your own needs. In my whole company it would be very counterproductive if every ticket gets closed automatically on an answer. For 99% of the tickets it would be one step more to do.
There could be a setting where the default behavior is adjustable, but changing this by default for everyone is not acceptable.
I should be able to add Screenshots by clpboard, images by drag+drop (embedded) and files by a drop field. And bitmaps should be visible in thread not only by download. Its better solved in OTRS.
thanks for this hint, but it also doesn’t fits our needs.
While we close most of the tickets on reply, there are still some tickets that should stay open (because there is something for us to do). So I insist on my proposal: when clicking on “answer”, the dropdown should change to , and while typing his answer, the agent can change this default when needed sometimes.
The new ticket button is a problem for us too. Some of the potential support agents had trouble finding it and interpreting its meaning!
Ideally the first screen the user sees after logging in should have a prominent button saying “New ticket”. Failing that, there should at least be some help text to say “To open a new ticket, use the + button at bottom left.”
In fact, a feature to have some customizable welcome text (in Markdown) for the user page would be a great idea.
