Pedro Rodrigues

Based on this post: Conditional view: fulfil A and B conditions OR fulfil C and D conditions. Is this possible?

We'd like to have the ability to combine multiple AND/OR conditions, adding extra layers of conditions to Views and business rules.

Examples:

• (A and B) OR (C and D)
• (A or B) AND (C or D)
• (A and B and C) OR (D and E)
• (A or B or C) AND (D and E)
• Etc.

Awesome, thanks Violeta!

The reply above is a bit misleading... Reopens seems to refer to Solved tickets whose update reopens them, i.e. their status changes to Open (source article; "Reopened Tickets: The percentage of reopened tickets that were previously marked as Solved.")

One way of reporting on follow-up tickets, for example:

• Trigger 1. When ticket is updated AND status changes to Closed = add tag ticket_closed
• Trigger 2 (placed at the very top of trigger list). When ticket is created AND tag = ticket_closed = remove ticket_closed + add ticket_followup

To report on follow-up tickets, you now have the tag 'ticket_followup'.

(Instead of a tag, you could have a checkbox or some other field, of course.)

I'd like to have the ability to create custom multi-select fields for users and organizations (also, reporting capabilities on these fields, too!)

Also, any plans to have any kind of auditable data for Chat? And/or usage data like for triggers, e.g. by accessing https://example.zendesk.com/api/v2/triggers.json?include=usage_30d

Hi, are there any logs for changes in Guide/HC?

A question for everyone out there: how do you identify a follow-up created from a closed Facebook or Twitter ticket?

Since we can't add a "Channel is Closed Ticket" condition (because in this case the channel is Facebook/Twitter), what element(s) allow(s) us to properly act on this kind of follow-up?

Hi Joseph, thanks for the heads up! Out of curiosity, regardless of which option we choose, there are a few challenges here.

1. If that parent ticket is changed to Closed, for example, and some user replies to the post on Facebook, then a follow-up ticket is created. So... when should we close these tickets? Should we close them at all?

We could create a workflow where we'd make sure these specific FB tickets would never be closed. But then they could be counted as backlog in views, reports, etc.

Then there are other more option-specific existential debates:

2.1. Option 1 = single ticket w/ all comments
If all comments are added to the same ticket, it's likely every "next reply" is a "first reply"... does anyone exclude this from any time-based KPI?

These tickets might also potentially contribute to a higher "public comments per ticket" ratio, so they'd probably have to be excluded in some way from those.

2.2. Option 2 = parent + child tickets
When each comment creates a ticket, there is no need to see the parent ticket at all, and it shouldn't probably be counted for any KPI calculation... right?

3. Relevance of post comments

Also, I've never properly analized this (thousands and thousands of tickets..) but it seems a high % of these post comments are completely irrelevant.

Does anyone exclude them from higher-level reporting? We're going to standardize a workflow where the agents (using macros, and then secret triggers in case they forget) will help us admins tag the tickets with zero agent replies... 

4. Any features for FB or Twitter integrations in the roadmap?

The third and final topic is a feature request to add more options to the integration:

a) Sometimes our agents decide to merge parent tickets (creating a lot of follow ups). Could we have an option to choose whether this could be entirely forbidden?

b) Sometimes they merge the end user which is in reality our Facebook Page (i.e. the end user who creates these FB integration tickets), with a real end user (a human). Can we prevent this? These user accounts, created by the integration, should be protected from this kind of ingenuous actions.

---

Maybe I'm exagerating with some of these scenarios, I don't know if everyone else has these problems, but I'd be happy to learn about how others deal with them if they do.

Any best practices or suggestions?

I'd like to highlight the need to include user-level mergers in the audit

Seconding this... mostly everything from everyone here :)