Saxon Clay

We utilize rapid resolve heavily, it'd be a huge loss of functionality for us to no longer have this after Aug 29

This functionality would significantly reduce the amount of manual overhead required for our community moderation, are there any updates on this Kasper Sorensen?

This would be a useful placeholder to email customers with the article they used in general, a confirmation for the user to reference back to etc

Ewa Kondratowicz - I've been working with a custom metric I created a while ago that calculates in a range how many days an agent sent any ticket replies, it's as close of an approximation of days worked as I've been able to find:

IF (SUM(Public Updates - Ticket Count) != NULL) 
THEN DCOUNT_VALUES([Update - Date])
ENDIF

You need to have an Assignee Name attribute or something similar to break the metric down to report individual agents, but it's worked well enough for the last year or so. 

Elisabetta Carli
You can do this with three Metrics and the Result Metric Calculation function. ie

D_/COUNT(Tickets)

D_/COUNT(Reopened Tickets)

D_/COUNT(Excluded Tickets)

Where "Excluded Tickets" is the custom metric using your:

(IF (NOT INCLUDES_ANY([Ticket tags], "thank_you")) THEN [Ticket ID] ENDIF

Once you have those three you can use Result Metric Calculation to perform arithmetic in the report like (Reopened Tickets - Excluded Tickets)/Total Tickets

Hope this helps. 

Edward Drack

If each of the macros have their own tags associated to them then I'd approach it like so:

Create an Attribute Set (Calculations > Set under Attributes) that includes only the tags you're interested in. This is easier to manage than using the general Tags attribute and trying to filter down each one. 

Past that, use Solved Tickets as your Metric, Ticket Solved - (Date/Week of Year/Month) as your Column attribute, and the custom tags attribute set as the Row attribute. I'd use a line graph, and multi-select all of the tags you want to review to see the trending over time rate of solved tickets having each of those tags on them. 

I hope this helps get you in the right direction!

Edward Drack

Can you elaborate on what exactly you're trying to accomplish? 

Tim Bechtold You should use DCOUNT(Solved Tickets) instead of COUNT(Tickets) in the calculations. 

Beyond that though, I'd recommend not using custom metrics for this and instead use Result Metric Calculation:

This lets you run calculations on the existing metrics in your report as well as hiding source columns if desired. Since it runs off of the existing data in your query there's usually no problems with it incorrectly scoping data. 

Ilaria I played around with the pie graph a bit but it seems the standard behavior is to aggregate all your values together (50 tickets) instead of referencing the actual total and I couldn't find a way around that behavior. 

I think a regular table would work the best in this case. Using the metric you already built, and then using 'ticket tags' as the Row attribute you can select just the tags you'd like to display, then possibly change it to an Ordered Set attribute if the default listing isn't in the order you want. 

To avoid manually selecting individual labels, or going back and updating it whenever a new label is added, you could make a custom "tag_%" attribute assuming all of the attributes actually follow a similar naming convention. 

IF LEFTPART([Ticket tags], 4) = "tag-"
THEN [Ticket tags]
ENDIF

This would return all ticket tags in a filtered down attribute that match the "tag-" naming convention, and would automatically update to include any new tags. 

Ilaria Am I understanding correctly that there isn't actually a single "main_tag" in your example, but instead that "main_tag" is a 'base' and there's several possible variations of it? (ie tag_a, tag_b, etc)? Or that there is one main_tag which will always have accompanying "supplemental" tags - tag_a, tag_b etc

In either case, that you have so many tickets where multiple of these tags are applied and you don't want them overlapping (50 total tickets instead of 22 as described) then you need some sort of "prioritization" to determine that if a ticket has tag_a AND tag_b, which part of the pie chart do you want it represented in? 

My first thought with what you presented in your comment is that the formula would work with the "D_COUNT" aggregator instead of COUNT, which will return distinct ticket IDs instead of a ticket ID for every match. Though I don't know if this alone would solve the problem with multiple tags appearing. 

If you want to use some kind of tag prioritization I think a custom attribute would be the best approach where each 'supplemental' tag is listed out in an if/then/else structure like:

IF

(INCLUDES_ANY([Ticket tags], "tag_a")) 

THEN "tag_a"

ELIF

(INCLUDES_ANY([Ticket tags], "tag_b"))

THEN "tag_b"

ELIF

.......

ENDIF

I haven't tested this but in theory it should give you back an attribute set that includes each _Aa tag that's grouped hierarchically in the order defined in the attribute. 

If you can shed a bit more light on the setup and what you're trying to achieve I can try and help further.