We’ve been using Zammad for almost 3 years now. This being our first experience with a ticket system, there was a learning curve and I’d say even today we could improve on how we use it.
Even though the possibility has been around from the start, we never opened up web login to Zammad to our customers. We’ve been using it as an internal tool only.
Now I’m thinking of changing this and giving customers direct access. The main idea here is that we could add a Zammad link to our invoices, answering proactively the question what this invoice is about.
Two questions I would like to ask the community, a technical and a strategic one.
I’ll start with the technical one. Is there a way to restrict access for customers to tickets that are older than a certain date? Assuming I’d start making Zammad from January, customers should be able to see all tickets that have been created since then, including all entries made in the ticket. Old tickets should remain out-of-bounds, however, not least because in most cases, our communication within the ticket was very informal and not something that was meant to be shared. Still, starting from scratch is not an option, the information in Zammad has become much too important for us.
The strategic question is what experiences you made with opening up Zammad to your customers. Is it a step you’d recommend or do you believe we may be making our lives unnecessarily difficult instead?
It will definitely become at least a bit more difficult because instead of using internal notes, we’ll have to use a lot more public notes or even call and email messages to document what happened. Since a higher quality for such entries will be required, this will increase the time we need to spend on a ticket. Only question is if it’s worth the trouble.
I hope some of you will take the time to answer, it would be very helpful.
we use Zammad internal and external. This is very helpful because the customers can see the state of a ticket or see our solution.
You can restrict the ticket in a simple way: go to the admin panel > overviews and edit the view for your customers. You can restrict the overview by add a filter for creation date of a ticket or closing time. BUT: this is only for the overview. Customer can view the other tickets by use the direct URL of the ticket.
The only way to block that is in my opinion to remove the customer from the ticket.
I don‘t know if you can set the first post to internal
But maybe another guy has better ideas I‘m not a pro
I’m working for an org that’s opening up Zammad to a whole bunch of users all at once in less than a week. If you like, once a week has gone by after doing so, would it help to reply here about my experience, our use case, and what we’ve done both technically and operationally to handle it?
Hi @Dennis1993, thanks for your suggestion. I’m not sure this will help, though. If I’m not mistaken, a user can always see all tickets that have been created in his name, and if it’s a shared organization, for all tickets created for the organization. So creating a filter for the overview wouldn’t do much.
Sorry, yes, I meant customers. And so far, the way we handle incoming service requests, is that customers can email service@, sales@, support@, etc. and it directly gets converted into a Zammad ticket for either myself or the other person working at our org to triage. Voicemails to our PBX get attached as a .wav file and are emailed to us with the PBX name as a customer, and a form that folks can fill out for a specific purpose are emailed to us as well.
We take notes internally on the ticket and then when it’s time to reach back out to the customer, we use Zammad to send them an external message by email. The way we’ve created how the response gets sent, the customer doesn’t even know that Zammad exists and that it’s an option.
That’s not to say that as part of the process, a savvy customer can’t realize that Zammad is powering our ticket response system. We got an incoming ticket from a customer that way and they seem to have figured out how to use it on their own. However, because most of this incoming flow of customers are from regular, non-techie folks who started using the Internet in the 1980s and 1990s, we’ve deliberately created some restrictions on them finding out how they can log into Zammad and use it.
Did any of that make sense? What else would you like to know? I’ll be able to respond at the end of the workday.
This is actually exactly how we work today, and our use case is also very similar.
So maybe my initial post was misunderstood. We are considering opening up the Zammad portal to our customers in addition to us as agents. We perfectly understand what this means from a technical perspective, I was just wondering if someone who’s done this already can share their experience.
In particular, today, we use internal notes predominantly to describe a problem and its solution in more detail. So when we solve an issue over the phone or remote access, we will not create a “call note” which is “public”.
Meaning that, if we open Zammad today and customers log in, they will see several tickets that are closed without any reasoning of what was done to close the ticket. Because they will not see the internal notes. And I have no intention of making these notes public because we usually write these internal notes in a very informal style.
I understand that by opening up Zammad, we will most likely have to change our processes and start working more with information that will be visible to the ticket user, such as call notes and emails. But since we didn’t do this until now, I was wondering if I can somehow “lock down” everything that is older than day x. I’d much prefer this over creating a fresh Zammad instance or disassociating existing tickets from customers.
Oh, I see now. Hmm, I’m not sure how long my org had been using Zammad before I started doing customer service and tech support, so it sounds like I can’t be of further help at all. I’m sorry that I wasn’t more helpful.
this may be a great benefit for your customers if they can call up and process their tickets themselves.
If you also make customer-related content available to the customer automatically (e.g. invoices from the accounting department as you describe), this can also make a lot of work easier for the accounting department. My thought here is: The customer can ask questions directly about their invoice without the accounting department having to search for the corresponding invoice, user data, etc first. When you use elasticsearch the
customer can search for an arcticle inside of one of his pdf-invoices and find the corresponding invoice in seconds. - Just one word away -
This step in your journey to open your Zammad to the customers must be planned in detail before you give them access to the web channel. Here are some points to think about:
Are there arcticles in existing tickets that customers are not allowed to see and eventually not marked as “internal” (the red border around the article)?
This function has to be consequently beeing used in the past.
You can easily, as Dennis1993 already described, filter the ticket-lists in the customer-overviews but they can find older tickets that are assigned to them by search-engine. As i mentioned: - Just one word away -
When customers are organised in organisations you have to throw an eye at the setting “SHARED ORGANISATION” within organization settings
From a technical prospective:
A simple way (but maybe not the best) with some drawbacks to get the old tickets out of customers eyes is to set all the older tickets to a “dummy” customer with a good planned, granular-driven “scheduler”. But be aware there are some disadvantages and this has to be planned and tested before you do some of these “wide-ranging” changes in production environment! When you feel unsave with some of these actions - search for professional help and this challenge becomes a success story for your customers and agents.
I‘m not a pro 
