Infos:
- Used Zammad version: 6.5.0-1749747762.06d0d09c.centos9
- Used Zammad installation type: package
- Operating system: AlmaLinux 9
- Browser + version: Chrome
Expected behavior:
- Trigger to send email when adding a new article should include ALL clients/customer emails that have interacted with the ticket. We do NOT want to send it to everyone in the related organization (there can be dozens of customers in an organization that are entirely not interested in every single ticket). But it’s super common that multiple people are adding info and details to a single ticket as they are all working together.
Our trigger uses the “Email” action and the recipient is set to “Customer”.
Actual behavior:
- Only the customer that initially opened the ticket gets an email. Other customers that are involved are “left out of the loop” and complain they are not aware of changes/updates to the ticket or requests for more info that they would be able to provide, if they had received/seen that request/article.
Steps to reproduce the behavior:
- customer A creates a ticket
- agent #1 adds an article, trigger sends email to customer A
- customer B is now included into the ticket by replying to the original email (which was forwarded to them) or using the web interface to add to the ticket.
- agent #1 adds another article to the ticket. trigger sends email to customer A, but NOT to customer B
- customer B gets mad they are “left out” of the ticket
- we have to send a gift basket
Comments
We tried having the trigger send to the organization, but some of our larger clients have dozens of customer/users in their organization and felt there was too much email traffic as a result. So we really just need a way for a trigger to send an email to ALL the client/customer addresses (not agent) that have contributed an article to a ticket
I’m hoping we are just missing “how” when setting up the trigger
Why does the trigger needs to send the e-mail? Can’t agent#1 not just send the e-mail himself? Because the agent#1 can simply click “reply all” and everybody stays in the loop.
I mean, they could, but that seems like an extra, conditional step. And in some cases, the agent is adding articles via email, so not available.
I’m trying to keep the system as “automatic” as possible and for the most part, it’s amazing and seamless to our agents workflow. They reply/send an email or quickly just type in an article and the system does the rest.
Except in these cases, which have turned about to be about 10% of our tickets - not enough to break things, but enough that having to use a different method (like pressing the semi-small reply-all and remembering to do that each time instead of just typing right into the ticket) trips this up and puts too much “book-keeping” on the agent.
We feel there needs to be one, simple way for the agents to post things so they aren’t having to remember context/different methods while fielding dozens of differently created/targeted/managed tickets. And other than this situation, the current setup does exactly that and requires minimal training and “work load” on the already busy agent.
What we would need, I think, is simply a new type of programmatic recipient. We already have “Customer” (which resolves to the sending/origination customer), “Owner” (currently assigned agent) and “All Agents”. I would think an “All Customers” that programmatically “expanded” to all customers associated with a ticket would be ideal
Thank you for the feedback!
Means, your agents primary add a note, when they want to write to the customer?
Please be aware, that Zammad does not interpret these as “communication”, also emails send by triggers are not recognized as “communication”, therefore behavior around SLAs and the last_contact attributes may not work as intended.
So I think what you actually need is to make it as easy to reply as to add a note, correct?
Okay - I appreciate that feedback.
But from looking at the interface, the first thing agents see is a ready to type into text area/input. Compared to the gray, small Reply/All glyph, it seems to suggest a primary way of entry.
Well, at least to us
We use the articles and the public/private option (for less common notes that should not be shared with the client) and other than this, it works very well.
We don’t use SLAs, so we prolly have simpler needs.
Still, perhaps the larger thought would be adding such a recipient variable so that triggers would benefit from it, however someone tries to structure their support process.
We may look into adding something like that ourselves, understanding it doesn’t seem to be a compatible concept.
Thanks again for replying!
My question was not there to dismiss your feedback, but to better understand, where it comes from. We are actually working on the next iteration of the UI for a while now. And it most likely will not have the empty box at the end at all.
I want to understand why you use it that way, to avoid users feeling forced to use triggers to send out emails to their customers.
No worries - I didn’t take it that way. I know that zammad has a “way”/philosophy of doing things. This may be one that just varies from what I’m looking for, but that is OK
We develop a pretty complex product ourselves and it has to be, by the scale of it, “opinionated” on somethings - a certain sort of “philosophy of the product” as well.
And I’m always amazed at different ways our client base interprets and uses things in ways very different from how we originally intended them to be used. Sometimes I shake my head, but often, there is value/truth in it, even if it requires some reworking of the clients basic concept to better fit in the product.
That is an interesting direction in UI evolution. And if that “Add Reply” button is basically the same as pressing the somewhat small “Reply All” button already there, I can see us adopting it easily enough.
We only use the empty box at the bottom because, frankly, it’s just the most obvious/easy way to type something in. Triggers are added just to make it do the “Reply” part automatically for the agent. Always looking for the lowest barrier to the agent getting the note into the system and moving on.
I am not wedded to using triggers, of course. I just want a method for an agent to have one simple way to quickly/easily add notes/details/comments to a ticket and insure all clients involved in the ticket are kept “in the loop” (via email). The less that agent has to remember to do (press Reply All vs Reply vs typing in the box at the bottom), the more likely everything “just works”
Overall, we are very happy with what zammad has done for our client ticket tracking and we did try out a number of different systems first (it doesn’t hurt that we both use rails so I feel more empowered, should I need to make changes/customizations)
Appreciate the reply and glimpse of the future!
1 Like
Maybe I can pick your brain once more. When you click the big “Add reply”-button at the bottom, instead on one of the articles, who do you expect it to reply to? The author of the last article, the author of the last e-mail? The customer? All recipients of the first article? All recipient of the last e-mail the customer wrote? Or something completely different?
Happy to share our thoughts
For us, the “ideal” would be that all customers involved in the ticket would get the email/reply. That would be for anything added to a ticket that was public, though generally just things added by the agent/staff. In our workflow, any customer who is involved in the ticket generally wants to be kept up to date on the ticket overall.
Ticket lifespan is generally a few hours and generally involve just one customer, but for tickets that are more complex or do involve other customers (usually in the same organization), once they are “mentioned”/referenced in a ticket, we would want them all to get updates/notices.
We wouldn’t need any staff/agents to receive email as they are all tracking/subscribed to any ticket that they need to be involved in and if they need to be added to a ticket, in general, that is done after some other communication that makes them aware of the ticket.
Hope that helps some!
