To get better Support for customer we work together with another Company which use OTRS.
Currently, if we do not have the knowledge We fill out a ticket inside the ticketsystem from the other company, gave them our customer data and the contact our customer.
It would be nice If there is a Solution that we could somehow use Zammad as Proxy for OTRS or other zammad Installation. The best solution would be that the customer do have to change the ticketsystem to a third company. (Kind of federated ticketsystem)
May there is a need for a protocol (like ActivityPub) for this?
We really like this Idea and are currently discussing possiblities. You could help us by providing further information.
Coud you please provide us some specific use cases and problems your can solve with this?
Company A: Zammad
Company B: OTRS
Current Case: Company A has one Account for all users.
Solution Idea:
In the User Properties we could get an access Token and Import it to Zammad.
This Token is linked with a Group.
A description Text Template has to be created, so important details like Agent, Customer details (Mail, phone number) etc. is shipped.
If I create a Ticket and use the other Company as Group the Form add the forms you have to fill on an OTRS ticket.
Use case 2:
Company A: Zammad
Company B: Zammad
A need help from B
May use the Activitypub Protocol for exchange Data. If a Company account or an User account has a website or mail-address check their https://example.com/.well-known if a Zammad is set-up.
New Ticket
The Agent (B) fill a Ticket for a user of another company (A) the first time.
Zammad (B) detect another Zammad on the domain of this company (A)
A Ticket Mail is sent to the user
User could select an e-Mail link to connect this ticket with their Zammad
Zammad from (A) authenticate the user and ask for permission to link the ticket.
Zammad setup a Dashboard for Tickets on (B)
An overview of shared Files could be seen.
According to GDPR Company (A) could see and delete files Company (B) store for working on the ticket, and setup rules like remove data 14 days after a ticket was closed.
Zammad (A) and (B) exchange a hash of the mail-adress of their users. Maching Users on (A) get the possibility to create Tickets on (B) in Zammad.
Use case 3:
Zammad as Mastodon instance for companies that manage their social media Profile. e.g.
This company publish news and information onto the Fediverse. If someone reacts on such a Post a reaction may needed.
Allow Zammad link a Fediverse account to it. Made it a full part of the Fediverse itself.
The Agent that write News and Information may not the same one that answers on Reactions.
In this case, the First reaction on a news should create a new Ticket, which could get picked by one of the Agent.
For the Record
I created 3 different use cases. But I also see possibilities where e.g. 1 and 2 could be merged and some other customer journeys are needed.
For our company use case 1 and 2 could be used right now.
A is doing the support (1st-Level, Administration, and some more cases) for a product/software developed by B.
As long as the requests don’t involve B needing to fix bugs, or implementation of new features, B doesn’t need tob e bothered with any requests.
This way B can focus on development and A filters standard requests, incidents, etc.
When a requests turns out to need the involvement of B, A writes a new ticket in Jira, so B can then help. Jira isn’t open to anyone outside B, except this speacial use case.
In Jira then a template needs tob e used fort he ticket creation to ensure ticket-quality.
A needs to check regularly in Jira, if B is ready with development, bugfixing, whatever…
Then A updates the ticket in Zammad.
A shortcut to directly enable both systems to communicate would be great.