Administrators only
This topic describes a useful strategy for designing metrics of type count or aggregate. Formula metrics are not covered because most of them are likely to be arithmetic calculations on existing count and aggregate metrics.
Ensure that your organisation is configured and routing communications according to your requirements and then follow the strategy depicted below when creating the metric.
|
|
Think about what the metric is required to measure and then devise a short plan for generating the type of traffic that the metric is expected to report on (for example, incoming calls to queues). Find a quiet period when minimal or no calls are being routed through storm, such as after close of business. Follow the plan to generate the traffic whilst noting down the time at which each action occurred (for example, the time at which calls were made or transferred, or messages sent and replied to by agents). You may need other people to help you with this activity. |
|
|
|
Choose a Historical Data Source The metric should be designed using the most suitable data source. |
|
|
|
Make Manual Calculations From a Data Export Report In the Report Builder interface for historical data export reports, create and run a data export report that includes a set of fields containing data for the generated traffic (for example, a talk time field). When you run the report, limit the date and time range to include only your generated traffic. Use the report to identify the rows and values required for the metric calculation and then use these to make the calculations manually. |
|
|
|
Apply filters to the data export report to eliminate rows that should not be included in the metric calculation and then recalculate the metric's value. |
|
|
|
In the Report Builder interface for custom historical reports, create a custom metric of type count or aggregate (as applicable) applying the same filters as those used in the data export report. |
|
|
|
Include the metric in a new custom report and then run the report for exactly the same date and time range as you did for the data export report and check that the value returned by the metric matches your manually calculated value. Tip: even if your metrics passes the test, it is recommended that you retest it using different data in another date and time range. |
Metric Compatibility Across Reports
Depending on how a metric is designed, it may give unexpected results when included in some reports.
For example, consider the metric 'Total Wrap Duration', which is designed for reporting wrap durations for incoming, outgoing, and internal calls. Although the metric will work well in the report for which it was designed, it may not provide the expected result in a report that includes metrics that were designed for reporting on incoming calls only. The effect of this is that some data values may look 'wrong' in the report. You can resolve this incompatibility by looking for an equivalent standard metric that is designed for reporting on incoming calls only. If this is not available, you can design a new metric for the report, or add filters to the report for excluding external and internal calls.
If you are designing a metric to be used in several different reports, it is recommended that you test the metric in all those reports.