Tables: The combination you wanted to look at
Last week we introduced Signals. It was built for a specific fear: that somewhere among thousands of combinations there's a finding you never thought to look at. Signals tests them all and brings back the few that hold up.
But most analysis doesn't start from fear. It starts from a hunch. You've read enough open-ended survey answers to suspect that one persona keeps showing up in one city. You think a pain point is mostly a problem for one product line. Your support lead is sure that calls about billing take longer than the rest. These are good questions, and you already know you want to ask them.
Asking them was never the hard part. Answering them was. Until now it usually meant exporting the analysis, opening a spreadsheet and spending an afternoon making the numbers come out right. Tables is how we fixed that, and like Signals, the reason it was hard is a decision we made ourselves.
The side effect of depth
Kimola doesn't give a piece of feedback one label. In Reports and Funnels, classification is multi-label by default: a single review can talk about delivery, price and packaging, and answer several Dimensions at once. That's deliberate. Customers don't speak in single topics, and forcing them into one throws away most of what they said.
The cost shows up the moment the results leave Kimola. In a spreadsheet, one review with three labels becomes three rows. Count them naively and that customer is counted three times. Average a number across them and the average quietly shifts. Every cross-tab turns into an exercise in remembering which rows belong together, and by the time the formulas are right, the question has usually moved on.
We kept watching customers, and ourselves, leave Kimola at exactly the moment the analysis got interesting. The data was already classified and the columns were already there. Only the question had nowhere to go. So we gave it a place, inside the report.
The decisions behind Tables
Drag the question, not the formula. A table is built by dragging. Say you want to see how personas are distributed across cities in an open-ended survey. Drag the Personas dimension into the table, then drop the City column under it. You first see how your feedback splits across personas, then how each persona splits across cities. Swap the two and the same table answers a different question: Sentiment, then Pain Points tells you what negative feedback complains about, while Pain Points, then Sentiment tells you how negative each pain point is.
Your columns and our analysis, in one table. Building Signals taught us that the columns you upload carry some of the most important information in a report. Tables treats them the same way. Any column that isn't the feedback text itself, such as product, city, segment or sales rep, can be crossed with anything Kimola found: themes, sentiment, Dimension answers, and the language of the feedback.
Numbers, not just counts. When you upload a dataset, Kimola works out what kind of data each column holds. Numeric columns show up with a # next to their name, and for those Tables can calculate Count, Sum, Average, Minimum, Maximum and Median for any combination. Upload call center conversations with the duration of each call, and you can see how long calls take on average for each pain point. What customers say and how your operation performs finally sit in the same table.
Filters narrow the question. Every table can be built from a part of the data. Look at personas by city only within feedback about a single topic, a single period or a single product, and the table is rebuilt from those records alone.
A table belongs to the team. Once a table answers a question worth asking again, save it, filters included, under a name your team will recognize. Pin it, and it sits on the Overview, so anyone who opens the report sees it first. This turned out to be the quiet benefit: a pinned table is a way of telling your team where to look.
Under the hood
Getting multi-label data right comes down to counting records, not labels. Each row shows how many pieces of feedback fall into its group and what share of the table's records that is, and a row nested under a group shows its share of that group. Because one piece of feedback can belong to several groups, the shares of a metric can add up to more than 100%. That's the honest number: it tells you how many customers mentioned each thing, not how a fixed pie was divided. Numbers follow the same rule. When a piece of feedback falls into three groups, its value counts once in each of them, so a long call about billing and delivery adds its duration to both, and never to the same group twice. This is exactly the step that goes wrong in a spreadsheet, where the same feedback sits on three rows and the arithmetic has to remember it.
What you'll see
Tables sits in the menu of every Report and Space. The page opens with how many records it reads and the period they cover. Below that are your filters, then every metric you can group by: classifiers, your columns, Dimensions and, when your feedback comes in more than one language, the language itself. Drag one into the table area, or simply click it. Every row shows the group, its number of records and its share, with a bar that shows how positive or negative that group is. In a Report, a table can also be copied or exported to PowerPoint.
Tables and Signals
Signals and Tables work from opposite directions, and we built them to be used together. If you came with a hypothesis, Tables lets you check it after the analysis in a few drags. What you didn't have a hypothesis about is exactly what you'd otherwise miss, and that's Signals' job: it finds it and pulls it out of the data for you. Often the two meet in the middle. A signal points to a group, and one click on Open in Tables takes you there to keep digging.
Where it works best
Tables gets more useful the more your data says about where feedback came from and what happened around it. Descriptive columns like product, region, channel, store or customer type give you groups to compare. Numeric columns like call duration, order value or a satisfaction score give you something to measure. A file with neither still works, through Kimola's own classifications and Dimensions.
Try it, and tell me what you think
Signals was about the questions you didn't ask. Tables is about the ones you did. Between the two, I hope there's less reason to leave Kimola in the middle of an analysis, and fewer afternoons spent making a spreadsheet agree with itself.
The easiest way to see it is to open a Kimola account. Every new account comes with sample reports, and Tables is already there, no upload needed. Our support articles on Tables will walk you through building, filtering, saving and pinning your first one.
If you try it, I'd love to hear what you asked it, what it answered well and what you wish it could do. Write to me on X.
