Update: Ontology (Orders, Customers, Inquiries)

This update adds two features.

A segment concept has been newly introduced to order and customer analysis, and an aggregation method management feature that lets you group and view inquiry data by the criteria you want has been added.

Why we made this

When analyzing order, customer, and inquiry data in Deskroom, there are moments when viewing everything as a single whole simply isn't enough.

A customer who purchased on both Coupang and your own shop may be the same person, yet their purchasing patterns and LTV can be completely different by channel. Treating them as a single customer instance hides those channel-level differences.

The same applies to inquiry data: the analysis results change depending on the unit by which you group inquiries. Whether you treat a single customer's consecutive inquiries as one case or split them by inquiry type produces different CS operational efficiency and resolution rate metrics.

This update focuses on letting you set the unit and criteria of your analysis directly.

Defining segments in order and customer analysis

When analyzing customers, viewing everything grouped as a single whole is sometimes not enough. This is the case when you want to break customers down by criteria you want, such as sales channel, channel, or acquisition path.

Now you can define segments yourself based on order object properties. For example, if you create a segment based on the "sales channel" property, a customer with purchase history on both Coupang and KakaoTalk will be split into and aggregated as a separate instance in each of the two segments.

The additions in this update are as follows.

• Segment definition: You can set up segments based on the custom properties of the order object.
• Per-segment instance separation: Even for the same customer, instances are split and aggregated separately by segment.
• Existing data preserved: Existing instances without a segment are kept as-is under the "All" basis.

Now you can immediately answer questions like "What is the repurchase rate of Coupang customers?" or "How does the LTV of our own shop's customers compare to other channels?" You can directly check channel-level differences that were hidden behind the overall average, and build strategies tailored to each channel.

Grouping tickets in inquiry analysis

An "inquiry case" is an object that groups customer inquiries into a single unit for analysis. CS metrics change depending on the criteria you use to group them, such as whether you view a single customer's consecutive inquiries as one or split them by inquiry type.

Previously, the aggregation method was fixed. Now users can create their own aggregation criteria and group and view tickets according to those criteria.

The additions in this update are as follows.

• Add aggregation methods: When you add a new aggregation method, instances are created based on the past three months of data and then automatically accumulate daily.
• Select aggregation method: You can select the aggregation method you want and view instances.

Now you can immediately check questions like "If I group inquiries by channel, how does the resolution rate change?" or "Looking by inquiry type, which case takes the longest?" using criteria you set yourself. By switching aggregation methods according to your analysis goal, you can draw more diverse insights from the same data.

Even with the same data, your strategy changes depending on the criteria you view it through. Breaking customers down by channel and grouping inquiries to fit your purpose — this small difference changes the depth of your analysis. Now define the criteria of your analysis yourself, and draw more accurate insights from your data.