Analytics and reports

Analytics and Reports — which is which

There are two numerical areas in the dashboard, and they are not duplicates. | | Analytics | Reports | |---|---|---| | In the sidebar | Analytics | Reports | | Answers | "what happened across the whole product?" | "how is the support team doing?" | | Covers | conversations, WhatsApp delivery, campaigns, automation, flows, commerce, support cases | conversations, CSAT, agents, channels, labels, teams | | Groups by | day, week or month, over a date range you choose | a date range you choose | | Honest about gaps | yes — it says when a number is incomplete and why | no, it shows what it has | Use Reports for the team. Who answered how much, how fast, which channel is busiest, how customers rated the service. Use Analytics for the product. Whether WhatsApp messages are actually arriving, whether a campaign reached anyone, whether your flows finish or stall, whether abandoned-cart outreach is going out. If a question is about people, it is a Reports question. If it is about machinery, it is an Analytics question. What both share A date range. Every screen has one, and every number on the screen is for that range and nothing else. One timezone. Days, weeks and months are cut in the account's reporting timezone, so two people in two countries looking at the same account see the same totals for the same dates. That is why a day can look "wrong" against your own clock: it is the account's day, not yours. What Analytics does that Reports does not It groups Day, week or month. The same range grouped by month is four bars instead of a hundred, which is the difference between a trend and a thicket. It tells you when a number cannot be trusted Under most Analytics screens there is a line of small print. It is not decoration — it is the part of the screen that keeps the rest honest: - "Immediate automation rules: they run inline and record nothing, so they are absent here rather than counted as zero." Automation analytics covers delayed rules. Immediate ones leave no trace to count. - "Part of this date range: finished episodes are kept for 30 days, so earlier days are incomplete." Ask for a longer range than the data is kept for, and it says so rather than showing you a dip that is really a deletion. - "SLA breach counts: some open cases have no SLA policy attached, so a zero breach count does not mean nothing was late." It says where the number came from "Computed from source records" or "Served from daily rollups". A rollup is a pre-computed daily total, which is why a long range loads quickly. When the rollups do not match the source records, the screen falls back to the source records and tells you it did. It separates "over the period" from "right now" Most tiles count things that happened inside your date range. A few — Open right now, Running now, Overdue right now — are a reading taken at the moment you looked, and they ignore the date range entirely. They carry the note "A reading taken now, not a count over the selected dates." Related - Analytics overview - WhatsApp delivery - Campaign performance - Automation and flow analytics - Commerce analytics - Reports

Analytics overview

The Overview is the first Analytics screen and the one to look at daily. It answers four questions: how much arrived, how much closed, how fast you answered, and what is still open. The Analytics overview, with the counters and the conversation series for the selected range The tiles | Tile | What it counts | |---|---| | Conversations started | conversations opened in this period, on any channel | | Conversations resolved | times a conversation was marked resolved in this period | | Conversations reopened | times a resolved conversation was opened again | | Average first response | how long a customer waited for the first human reply | | Average resolution time | how long a conversation stayed open before it was resolved | | Messages received | customer messages — activity notes and private notes are not counted | | Messages sent | replies to customers, including approved template sends — notes are not counted | | Open right now | conversations open or pending at this moment; snoozed ones are not counted | Three of these repay a careful read. Resolved is an event, not a state. A conversation resolved, reopened and resolved again counts twice. That is deliberate: it measures work done, and closing something twice was two pieces of work. Reopened is the quality signal. A desk with a high resolve count and a high reopen count is closing conversations that were not finished. Watch the ratio rather than either number. Open right now ignores your date range. It is a reading taken when you loaded the page. Looking at last month and seeing today's open count is not a bug. Where the volume sits Under the tiles, a breakdown shows which channels, teams or labels carry the volume, as a share of the whole. "Not recorded" is its own row rather than being hidden — a large "Not recorded" share usually means something is not being labelled, which is worth knowing. Reading the series The chart is the same measure over time, grouped by day, week or month. Three readings are worth making a habit of: 1. Started against resolved. If started is consistently above resolved, the backlog is growing, and no amount of speed on individual conversations will fix it. 2. First response against your promise. If your website widget says "typically replies in a few minutes" and this says hours, one of the two has to change. 3. The shape of the week. Where the volume lands tells you when to staff, and it is almost never spread evenly. Limits - Averages hide the tail. An average first response of eleven minutes is consistent with most customers waiting two minutes and a few waiting a day. - A reply by an automation or a bot is not a human first response. First response measures the first human reply. - Counts are scoped to the account, not to what you personally can see. Who can see this Administrators. Agents do not have the Analytics screens. Related - Analytics and Reports — which is which - Reports - Work in the inbox

WhatsApp delivery

This screen answers one question: are the messages arriving? Every figure on it comes from what Meta told us about a message after we handed it over. None of it is inferred. The tiles | Tile | What it counts | |---|---| | Messages sent | outgoing WhatsApp messages handed to Meta in this period | | Template sends | of those, the ones sent as an approved template | | Delivered | messages Meta confirmed as delivered or read | | Read | messages Meta confirmed the recipient opened | | Failed | messages Meta refused to deliver | | Delivery rate | delivered as a share of what was sent | | Read rate | read as a share of what was sent | | Failure rate | refused as a share of what was sent | | Synced from the app | messages sent from the WhatsApp Business app and synced in | Two of these have a rule inside them. A message delivered and later marked failed counts only as failed. Meta sometimes reports a delivery and then retracts it. The later word wins, so the delivered figure never overstates. Messages synced from the WhatsApp Business app are excluded from every count and rate above. Their delivered status was recorded on a phone rather than confirmed by Meta, and mixing the two would make a delivery rate that means nothing. They are shown separately so the volume is visible without polluting the measurement. What a bad number means Failure rate climbing. Open a failed message in its conversation and read the error. The usual causes are the 24-hour window, a number that is not on WhatsApp, a template that was rejected or paused, and a quality-rating restriction on your own number. Read rate far below delivery rate. The messages arrive and nobody opens them. That is a content and timing problem, not a delivery problem — and on a template campaign it is the number that matters. Template sends near zero while sends are high. Everything is going out inside the 24-hour window, which is healthy. The reverse — almost everything a template — usually means you are reaching out more than you are replying. Limits - This measures delivery, not conversation. A high delivery rate with no replies is still a failure of the message. - Rates are shares of what was sent in the period, so a small period with a handful of sends produces rates that jump around. - Meta's own delay means the last hours of a range can look worse than they will once the statuses settle. Related - The WhatsApp 24-hour window - WhatsApp templates - Find a failed WhatsApp message - Campaign performance

Campaign performance

A campaign has two numbers people usually ask for — how many got it, and how many read it — and four more that explain the gap between them. The tiles | Tile | What it counts | |---|---| | Campaigns run | campaigns that addressed at least one contact in this period | | Recipients addressed | contacts the period's campaigns selected, counted once per campaign | | Sent | recipients Meta accepted a message for | | Delivered | recipients Meta confirmed as delivered or read | | Read | recipients Meta confirmed opened the message | | Failed | recipients Meta refused to deliver to | | Skipped | recipients never attempted — for example a contact with no phone number | | Still queued | recipients addressed with no outcome yet | | Delivery rate | delivered as a share of the recipients addressed | | Read rate | read as a share of the recipients addressed | | Failure rate | refused as a share of the recipients addressed | The rates are measured against addressed, not against sent. This is the important difference between this screen and WhatsApp delivery, and it is deliberate. A campaign that addressed a thousand contacts, skipped six hundred for want of a phone number and delivered to all four hundred of the rest has a delivery rate of 40%, not 100%. The first figure is the truth about the campaign; the second is the truth about the four hundred messages that existed. Skipped is the number to read first on a disappointing campaign. It is almost always an audience problem — contacts with no phone number, no consent, or a number in a format the provider refuses — and it is fixable before the next send in a way that a low read rate is not. Still queued is only meaningful while a campaign is running. Hours later it should be zero; if it is not, something stopped. Limits - A contact addressed by two campaigns counts in both. These are campaign recipients, not people. - Read requires the recipient's read receipts to be on. Where they are off, a read message is reported only as delivered, so read rate is a floor rather than a measurement. - Nothing here says whether the campaign worked. Delivery is not a reply, and a reply is not a sale. What a campaign produced lives in the conversations it started. Related - WhatsApp campaigns - Live chat campaigns - Shared audiences - WhatsApp delivery

Automation and flow analytics

Two screens, one subject: what the machinery did when nobody was watching. Automation execution An episode is one delayed rule starting its clock on one conversation. The screen counts episodes, not rules. | Tile | What it counts | |---|---| | Episodes armed | times a delayed rule started its clock in this period | | Acted | episodes whose actions ran | | Declined | episodes the rule re-checked at firing time and chose not to act on | | Action rate | acted as a share of the episodes that reached an outcome | | Waiting to fire | episodes whose clock is still running | | Stranded | episodes whose worker stopped while the actions were running | Declined is not a failure. A delayed rule re-checks its conditions when the clock runs out: "if nobody has replied in two hours, escalate" should decline when somebody replied. A rule that never declines is usually a rule whose condition does not depend on anything that can change. Stranded above zero is worth investigating. It means a worker stopped mid-action. Nothing retries these on purpose, because repeating a send is worse than dropping it — a customer who gets the same message twice has a worse experience than one who gets it once. If this number is not zero, look at what those episodes were doing. Immediate rules are not here at all. A rule with no delay runs inline and records nothing to count. The screen's own note says so. If you have one immediate rule and one delayed rule, this screen is about half your automation. Flow sessions A run is one customer going through one flow once. | Tile | What it counts | |---|---| | Runs started | flow runs that began in this period | | Reached the end | runs that ended at an End node | | Stopped on an error | runs that hit an error or a safety limit and were handed to a person | | Ended from outside | runs ended by something else, such as the conversation being resolved | | Handed to a person | runs that reached a handoff node and gave the conversation to your team | | Completion rate | reached the end as a share of the runs that ended in this period | | Average run length | start to end, including every stretch spent waiting for the customer | | Average steps | nodes a run passed through before it ended | | Running now | runs a customer could still answer | Handed to a person is a success, not a leak. A flow that answers the easy half and hands over the rest is doing its job. The number to worry about is stopped on an error: that is a customer who hit a wall. Average run length includes waiting. A flow that asks a question and waits overnight for an answer has a run length of hours, and that says nothing bad about the flow. Compare runs with each other, not against a clock. Completion rate is measured over runs that ENDED in the period, not runs that started in it. A run started yesterday and finished today counts today. Limits - Finished episodes are kept for 30 days. Ask for a longer range and the screen says that part of it is incomplete, rather than showing a decline that is really a deletion. - These screens count machinery, not outcomes. A flow with a 95% completion rate can still be answering the wrong question. Related - Automation rules - Flow builder - Automation or flow builder - Analytics and Reports — which is which

Commerce analytics

This screen is careful about one thing above all: it does not claim credit it cannot prove. The tiles | Tile | What it counts | |---|---| | Carts seen | carts your stores first told us about in this period | | Reported abandoned | carts a store said were abandoned | | Messaged | carts where recovery outreach was accepted for sending | | Checkout completed | carts a store said were completed | | Completed after messaging | completions that happened after outreach went out | | Completed with no messaging | completions on carts we never messaged | | Messaged rate | messaged as a share of the carts reported abandoned | | Order actions | refunds, cancellations, status changes and resends your team asked for | | Actions refused | order actions a store refused — nothing changed in the store | | Recovery messages prepared | recovery messages drafted for an abandoned cart | | Open abandoned carts | carts a store called abandoned and never called completed | | Actions unsettled | order actions with no final answer | The two rules that make these numbers honest Abandonment is the store's word, never ours. Lynomia Chat runs no inactivity timer of its own, so silence from a store is never counted as abandonment. If your store's definition of abandoned is "no checkout within an hour", that is the definition this screen uses, because that is what the store reports. Completed after messaging is a sequence, not a cause. It is the order of two recorded times and nothing more. The shopper may have come back on their own, or because of the store's own reminder email. That is exactly why Completed with no messaging sits next to it: the pair is the comparison, and either number alone is a story you can tell yourself. What to act on Messaged rate well below 100% means carts are being reported abandoned and never followed up. Usually a missing phone number, a missing consent, or outreach that is not switched on. Actions refused is the store refusing a change your agent asked for — a refund on an order already refunded, a status change the store's own rules forbid. Each one is a conversation where your agent told a customer something would happen and it did not. Actions unsettled above zero needs a human. These include the cases where the request reached the store but the reply was lost. They are never re-sent automatically, because a re-sent refund is a refund twice. Check them in the store itself. Limits - Only connected stores appear. A sale through a channel with no store connection is invisible here. - Checkout completed proves checkout completion and nothing more — not payment, not fulfilment, not that the order survived. Related - Commerce overview - Commerce provider support - An order action did not apply - Customer 360

Reports

Reports answer questions about the team: who handled how much, how quickly, and how it compares. The Reports overview, with the live counters and a week of conversation traffic The screens | Screen | What it is for | |---|---| | Overview | a live snapshot plus traffic and resolution heatmaps | | Conversations | the core metrics over time, with a drill-down to the records | | CSAT | every customer rating, as a table you can filter | | Agents | the same metrics per agent, with a page per person | | Inboxes | the same metrics per channel | | Labels | the same metrics per label | | Teams | the same metrics per team | Every one of them takes a date range — last 7, 14 or 30 days, this or last month, the last 3, 6 or 12 months, or a custom range — and most take a grouping: day, week, month or year. Overview Two different kinds of number share this screen, and it is worth knowing which is which. The Live row is now. Open, Unattended, Unassigned, Pending. These are counts at this moment and they ignore the date range completely. Unattended is the one to watch: a conversation nobody has answered yet, or one where the customer is still waiting. The heatmaps are history. Conversation Traffic and Resolutions, by day of the week and hour of the day, over the range you chose. They are where staffing decisions come from: the busiest hours are rarely the ones people assume, and the gap between the traffic map and the resolution map is where the queue builds. Conversations The headline metrics over time: - Conversations, Messages received, Messages sent — totals - First Response Time, Resolution Time, Customer waiting time — averages - Resolution Count — a total Each average tells you how many conversations it was computed from. An average first response time calculated from four conversations is not a measurement of your service, and the screen says so rather than letting you quote it. Click a bar to see the records behind it. The drill-down lists the actual conversations or messages in that bucket — which turns "Tuesday looks wrong" into "these are the eleven conversations on Tuesday". Drill-down is for administrators only. Business hours There is a Business Hours switch on this screen. With it on, response and resolution times count only the hours your channels are open. A conversation that arrived at 7pm and was answered at 9am is a fourteen hour wait on the clock and a few minutes of your working day. Which number is fair depends on what you are asking; keep the setting consistent when you compare two periods. Agents, Inboxes, Labels, Teams The same metrics sliced four ways, each with an overview table and a page per row. Each can be downloaded as a CSV. The useful comparison is rarely the ranking. It is the shape: an agent with a high conversation count and a high resolution time is probably picking up everything and finishing nothing; a channel with a slow first response is usually one nobody has made a habit of watching. CSAT Every rating a customer left, with the agent, the channel, the conversation and the comment. Filter by agent, inbox, team or rating, and download it. CSAT only exists where you switched the survey on, per channel, and only for conversations that were resolved. See Ask customers how you did. Bot reports Where you run an agent bot, this screen shows how many conversations it handled, how many it resolved itself, and how often it handed over. The handoff rate is the honest measure of a bot: a bot that resolves nothing but routes correctly is useful, and a bot with a high resolution rate and angry follow-up conversations is not. Limits - Reports are account-wide. They are not filtered to what you personally can see. - Averages do not show the tail. Use the drill-down to find the conversations that dragged a figure. - "Not enough data" is a real answer. A chart that refuses to draw is refusing to imply a trend from three points. Who can see this Administrators. The drill-down into individual records is administrators only as well. Related - Analytics and Reports — which is which - Analytics overview - Ask customers how you did - Assign and prioritise

Ask customers how you did

CSAT — customer satisfaction — is one question asked after a conversation is resolved. It is off until you switch it on, and you switch it on per channel. Switching it on Open Settings → Inboxes → the channel → CSAT, and enable the survey. You choose: - how the rating is shown — stars or emoji - the message that goes with it - whether a comment is invited as well as a rating The survey is sent when a conversation is resolved, on channels that can display it. A conversation that is never resolved is never surveyed, which is the single most common reason a desk gets no responses: agents are leaving conversations open rather than closing them. Reading the answers Reports → CSAT lists every response: the contact, the agent, the rating, the comment, and a link to the conversation it came from. Filter by agent, channel, team or rating, and download the lot as a CSV. Read the comments before the average. The number tells you whether something changed; the comments tell you what. A single one-star rating with a sentence attached is worth more than a week of unexplained fours. What it measures, and what it does not It measures the people who answered. Response rates to a CSAT survey are low and the people who answer are not a random sample: the delighted and the furious answer, the satisfied majority do not. Watch the trend rather than the absolute number, and never compare your figure to somebody else's. It measures the conversation, not the outcome. A customer can rate a polite, fast agent five stars while remaining unhappy about the thing they asked for. It is per conversation, not per customer. Somebody who contacts you four times can leave four ratings. Limits - Off by default, per channel. - Only on resolution. No resolution, no survey. - Not every channel can display a survey — it depends on what the channel supports. - You cannot re-send a survey, and a customer cannot change an answer. Who can do this Administrators switch the survey on. Administrators read the report. Related - Reports - Set up an inbox - Work in the inbox

Support case analytics

The Support cases tab appears in Analytics only where the support-case module is switched on for your account. This screen is about cases, not conversations. If you do not use support cases, it will be empty, and that is correct. Support case analytics: the counters, and the note that a zero breach count is not the same as nothing being late The tiles | Tile | What it counts | |---|---| | Cases opened | cases opened in this period, however they started | | Cases resolved | cases whose resolution was recorded in this period | | Cases reopened | reopenings recorded in this period | | First-response targets missed | first-response targets recorded as missed | | Resolution targets missed | resolution targets recorded as missed | | Average time to resolve | opening to resolution, over the cases resolved in this period | | Open right now | cases in one of the four active statuses at this moment | | Overdue right now | active cases whose resolution time has already passed | | Unassigned right now | active cases with nobody assigned | Three things these numbers do that most do not Resolved counts every resolution, not every case. A case resolved, reopened and resolved again counts twice. That is work done twice, and it should show. Reopened is read from the case history, not inferred from the current status. A case reopened and resolved again still counts as a reopening, which is exactly the case a status-based count would lose — and it is the one you most want to see. Average time to resolve is absent when nothing was resolved. Absent, not zero. A zero would read as "instant" when it means "no data". The SLA caveat Only cases with an SLA policy attached can appear in the two "targets missed" figures. The screen says so itself when any open case has no policy. A desk where half the cases are unmeasured will show a low breach count that means nothing. If you want the breach numbers to be meaningful, attach a policy when the case is opened — see SLA policies. The right-now row Open right now, Overdue right now and Unassigned right now ignore the date range. They are readings taken as you loaded the page, and they are the three to act on today: - Overdue right now — already late. - Unassigned right now — nobody has picked it up. - Open right now against Cases opened over a month — whether the pile is growing. Related - Support cases - SLA policies - Analytics and Reports — which is which