Connecting up the 'Support' Dots...
We have a situation here where, on creation of a new ticket, I can enter a customer reference (Customer - a field with a set of values I have to pre-populate within the Ticket fields) which is simply duplicated data from the list of Organisations we interact with. I also have some site specific information that, ideally, I'd see populate the Ticket field I have also created for that purpose...an example...
Release Level (a field indicating the customer/organisation's) latest release of our software they are using.
At present this creates additional effort to ensure the non-denormalised data from Organisation is transposed into the Ticket field as well as having to maintain a interal (Ticket) list of possible value (for both Customer and Release Level). I have other fields but these are just key examples.
As software developers ourselves using relational databases it seems counter-intuitive to have to do this with the native ZenDesk offering - you imagine that it'd simply be a given that you'd be able to drop an organisation and user field into the ticket definition allowing you to select from the valid values (or have items prefilled accordingly...i.e. I enter Organisation 'Name' in my Ticket and ZD recognises another field from Organisation is defined to the ticket (Release Level) and pre-populates based on that KEY field from that row in the Organisation list.
This functionality clearly exists in some form when one creates/maintains a ticket because you can alter the Requester (for a ticket) and this IS obtainable from your presently defined User list. It does not make sense to me that this level of interaction does not exist between the 3 key aspects of ZD Support: Organisation, User and Ticket and the simple relationship that exists between them:
Organisation--<Users--<Tickets
The denormalised and valuable data should, in my view, be 'inherited' by a Ticket if so desired.
I enjoy my use of ZD and it has personally helped me significantly organise my support desk workload but this limitation is a continuing mystery to me and is definitely a cause of frustration as it slows ticket creation and maintenance due to my constant need to verify the non-denormalised data for accuracy.
It would be great if ZD offered this capability to, as I titled my post, fully 'join up the dots' of the key items of CRM data: organisations, our users who work for them and the support tickets they raise.
Kindest Regards
Gary Donoghue
-
Hey Gary,
I had a read over your post here a couple of times. In reality, the truth of the post came down to your last line: join up the dots of the key items of CRM data: organizations, the users who work for them, and the tickets they raise.
As far as my understanding goes... this is the way the data works in Zendesk, exactly how you describe it.
- You have an Organisation i.e Org A.
- You then have a bunch of users who all work for Org A and submit/raise tickets to your Zendesk. For example's sake, you have 5 different users.
In this scenario above, the 5 users themselves, their individual Zendesk profiles each need to be linked to the organization in Zendesk which has been created for org A.
From this point, after the users have been linked directly to the org in Zendesk, when any of those 5 users then submit a new ticket, the ticket will automatically be raised against that organization and be represented on the ticket visually for the agent to the left of the Requesters name and Ticket ID in the top right-hand corner of the ticket window. - There's no need for you to have a manual ticket field to capture the organization on the ticket.
Feel free to correct me if I'm on the wrong path with this for you, however, this is basic functionality in Zendesk already. Once you have users linked to orgs, you can then create all types of different automatic workflows with triggers etc based on the org itself.
This might also be a good read for you as well in case you need: https://support.zendesk.com/hc/en-us/articles/203661766-About-organizations-and-groups
Hope this helps. :)
Best,
Amie
-
Hi Amie,
Many thanks for coming back to me so promptly - much appreciated. Before responding I should, perhaps, provide the wider context of this post into the Support feedback forum...namely https://support.zendesk.com/hc/en-us/community/posts/204625618-Add-custom-Organisation-Fields-to-Tickets and community moderator Devan's https://support.zendesk.com/hc/en-us/profiles/379574987874-Devan response to it viz...
Hello Raman Kalia & Gary Donoghue,
These are phenomenal posts from both of you that breakdown your use cases perfectly. I'm going to be passing this along to our product managers, but I can't stress enough that sharing this in our product feedback forum would be helpful for other users and our product team. It is where we keep conversations on topics like this and often where our PMs look for use cases from the community.
In your response you mention the relationship between organisations and users which I am clear about (as ZD allows organisations to be defined (based on domain name(s)) and users then connected to that organisation. A user can then be connected to a ticket via various means, the ultimate reference being the 'requester' - so, yes, the dots are connected...but perhaps, to push the analogy a bit further, they are just a little faint than I would expect or prefer them to be.
The main point of my contribution in this discussion on the original forum posting was that there is valuable OTHER data contained/stored within an organisation (and a user for that matter) that would be useful to see appear within a ticket itself. I cite an example of our own...the 'release level' of our software a specific customer is using. This is useful information we like to store on a ticket yet it is NOT presently possible for me to do this via the relationship the requester (user) has to an organisation (he/she belongs to) and the 'release level' field stored for that organisation. Each time a ticket is created we have to check the value of the Release level field in Organisation to make sure it is transposed onto the denormalised Release level field within a ticket.
So while the underlying architecture of Organisation-<User-<Ticket does exist (though there is no ability on the standard dashboard to open up a list of Organisation and/or Users - separate issue) it is the lack of interaction of fields (i.e. useful data) from the Organisation/User into tickets that is the main concern. A normal relational system should, I feel (and others agree - see the forum) provide this capability...i.e. to allow ticket fields to be defined from Organisations/Users (if present) where the key data for each is connected to a ticket: respectively the ZD ticket customer and ticket requester.
I hope this helps clarify the requirement further and also provide some wider context.Kindest Regards
Gary Donoghue
-
Hi,
Adding my use case from the community post:
Many organisations have contracted us and we are supposed to provide services to them. Service can only be rendered for the period of contract, which must reflect in the ticket by date of start or end of contract so decision making at agent level can happen. Contract dates must be defined at the organisation level as there can be anyone from client's domain email address raise the ticket. When raised, ticket must automatically pick up the date value (ie. start or end date of contract) from the organisation. This is because, other parameters like text, drop down, checkbox values can be copied automatically if custom ticket fields carry tag names same as of the organisation's "field key". But when it comes to passing on values from a custom 'date' field organization organisation to ticket's date field, system fails miserably to do so.
Such a facility is important in applying appropriate workflow / trigger / automation / macro to the ticket. Any ticket, which is past expiry date of contract may need to be directed to sales instead of support. Alternatively, agent can take a decision if to address the ticket based on the date of start of end of contract.
-
Hi Raman. Many thanks for adding. Hopefully a few more people will join in too. Take care.
-
The Jira Integration does not support Organization fields to sync.
We need to be able to pass the organization value to the linked Jira. The only workaround here is to create an individual trigger for each Organization to populate a custom ticket field.
Just imagine the load on the system as we continue to add a trigger per organization
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
5 Kommentare