Customer ticket subscriptions: follow a ticket, and let a manager subscribe the colleagues involved

Feature requests
1

Title: Customer-side ticket subscriptions and an organization manager role that can subscribe colleagues

What is your original issue/pain point you want to so

Our customers can already see their organization’s tickets in the portal: shared organization is enabled for all 39 of our customer organizations. Zammad notifies only the ticket customer, so a colleague who did not open the ticket learns nothing about agent replies, state changes or closure. The Subscribe button exists for agents, not for customers. As a result, “who else needs to know” is d: our agents add people to CC in individual articils to each other, and both sides lose track of who is actually informed.

Which are one or two concrete situations where this problem hurts the most?

  1. A production line stops at 3 a.m. The shift operator opens the ticket, we work on it during the night and close it. In the morning the plant IT manager and the quality manager need the result. They can find the ticket in the portal, but nobody told them it exists, so they call us and we retell the night by phone.
  2. A customer’s IT manager asks for notifications about every ticket of their plant, not only the ones they opened themselves. One of our organizations has 24 contacts, another has 35. Today the only ways to do this are to make that person the customer of every ticket, which destroys the real requester, or to CC them manually in every article, which nobody remembers to do.

Why is it not solvable with the Zammad standard?

  • Shared organization governs visibility. It has no effect on notifications. ticket subscriptions are an agent feature. Customerket. ticket has exactly one customer, so "several inteessed in the data model.
  • Article CC is per article and manual. It does not persist as a subscription, it is not shown as a list on the ticket, and customers cannot manage it themselves.
  • Trigger recipients cover the ticket customer, the ticket owner, agents and admins. There is no recipient like “all members ticket’s organization” or “ticket subscribers”, so h triggers either.

We closed the gap with an external service: a webhook from Zammad into our own notifier, which keeps its own list of who should receive what. It works, and it is also a list that goes stale the moment a customer’s staff changes. Any installation serving corporate customers has to build the same thing.

What is your expectation/what do you want to achieve?

  1. Customer subscriptions: a contact with portal access can subscribe and unsubscribe on any ticket they are already allowed to see, and then receives the same notifications as the ticket customer.
  2. Organization-level subscription: “notify me about all tickets of my organization”, ideally with a filter by group or ticket type and an option to receive a daily digest instead of every event.
  3. A role or user permission, working name organization manager, that can manage subscriptions for other contacts of the same organization: add a colleague as a subscriber to oganization feed.
  4. Ticket subscribers as a trigger recipient, so admins can reuse the notification triggers they already have instead of building a parallel mechanism.
  5. REST API for subscriptions (list, add, remove), so installations that provision users automatically can keep subscriptions in 6. Guard rails: a subscriber must be a contact of theions only apply when the organization is shared, andthe ticket history records who subscribed whom.

If there is any more useful information, feel free to share it all

Two places in the UI would carry this:

  • Customer portal, ticket view: a Subscribers block with the list of subscribed people and an add field limited to colleagues from the same organization.
  • Organization profile, visible to the organization manager: a Notifications tab listing contacts with three settings per person, all tickets of the organization, own tickets only, none.
    For reference, Zendesk covers this with followers andmail notifications, and Freshdesk with watchers. Frappe Helpdesk ships a customer manager role that sees all tickets of its organization, though notifications there stay author-centric, so visibility alone is not enough.
    We are glad to test this on our instance and report b

Your Zammad environment: 7.2.0, self-hosted, docker-compose, PostgreSQL and Elasticsearch

Average concurrent agent count: 26 agent accounts, usually around 10 working at the same time

Average tickets a day: 22 (649 tickets in the last 30 days, 2576 in total)

What roles/people are involved: 26 agents; 461 active customer contacts in 39 organizations, all of them shared; the two largest organizations have 24 and 35 contacts. On the customeperators who open tickets, plant IT managers andquality managers who need to follow them.

Anything else which you think is useful to understand your use case: We already push notifications to customers through our own Firebase service and to agents through Element and Yandex Messenger bots, all driven by Zammad triggers and webhooks. Subscriptions are the only piece we cannot express inside Zammad, so it lives outside the system and drifts out of sync. We manufacture and support production line marking software, so a ticket usually means a stopped line, and the people who need the update are rarely the people who typed the request.

2

You copy-pasted the first part twice.

Wouldn’t it be possible to set the default notifications for your users to “All tickets” for the groups in question? I mean it would certainly be a huge increase in notifications for all of them, but this seems like the same issue as the “assign multiple customers to same ticket”-request - would be nice but isn’t on the dev team’s to-do-list.

3

Thanks for the read, and sorry about the duplicated block. I have cleaned up the post.

On setting notifications to “All tickets”: that setting lives in the agent profile and works per group. The people I am talking about are customers. The Customer role has no group assignment at all, and the notification matrix is not part of the customer interface, so there is nothing to switch on for them.

Turning them into agents is not an option either. An agent with access to a group sees every ticket in that group, from every organization. We run one Zammad for 39 customer organizations with 461 active customer contacts against 26 agents, so an agent seat for one customer’s manager would expose other customers’ tickets.

There is a second reason “All tickets” does not fit, and it matters more than the first one. What our customers ask for is the opposite of a firehose. They want specific tickets, chosen by a person, for as long as those tickets are open.

Three real situations from our support line:

  1. Shift handover. A production line stops during the night shift. The operator on duty th us on it. At the end of the shift they hand the ticket number to the next operator, who
    Three real situations from our support line:

  2. Shift handover. A production line stops during the night shift. The operator on duty th us on it. At the end of the shift they hand the ticket number to the next operator, who now needs updates on that one ticket: our replies, the state change, the closure. That person does not want the other twenty tickets of the plant. They want this one.

  3. A manager subscribes the people involved. The plant’s support lead reads a ticket about failing marking on line 105 and knows who will be asked about it: the mechanic who services that camera, the quality manager, the person who owns the SAP side. Today the lead forwards our mail to them by hand, or sends the ticket number in a chat, and from that moment those people are outside Zammad. They should be
    able to add those colleagues as subscribers on the ticket, so the system keeps them ilaying it.

  4. A manager follows a colleague’s ticket. The same lead wants to stay in the loop on a specific ticket until it closes, without becoming the customer of it and without taking the requester’s place in the history.

In all three cases the people can already find the ticket: shared organization is on, so they see it in the portal. The only missing piece is the bell. They can read the ticket but they cannot ask Zammad to tell them when something changes.

Because subscribing other people should not be available to everyone, the second case needs a permission rather than a free-for-all: a role or user flag, working name organization manager, that allows managing subscriptions for contacts of the same organization. Restrictions that make it safe: a subscriber must be a customer of the ticket’s organization, the organization must be shared, and the ticket history records who subscribed whom.

I want to separate this from the “multiple customers on one ticket” request, because thesking to change the ticket data model. One ticket keeps one customer and one requester. Iam asking for a list of people who receive the notifications, which Zammad already implements for agents through Subscribe.

If the full feature is too much, the smallest version that would already solve this for us is:

  1. Subscriptions allowed for customer users, so the existing Subscribe action works in the customer interface for tickets they can see.
  2. A permission that lets a designated customer manage subscriptions for contacts of the same organization.
  3. Ticket subscribers as a recipient option in trigger notifications.
  4. REST endpoints to list, add and remove subscribers, with the same restrictions as above.

With that we can build the rest on our side. Happy to test on our instance and report back.