Run your CX stack from a chat.

Account check is the skill that is slipping. query_coach_tasks shows 307 Zendesk tickets graded since Mon, and account_check fails on 96 of them (31.3%). Four weeks ago that miss rate was 8.7%. query_coach_sessions has 68 sessions this week, and it is the same miss over and over: the agent skips the plan check on the first reply, so the customer has to write back. A typical line is "i already told you my plan and they asked again". Another: "can someone actually look at my account before asking the same thing".

query_metrics puts the drop on Tuesday afternoon, the same window as the 4.12.0 release. The account-check score went from 70.8 that morning to 54.2 by end of day, and it has been 51-53 since, 51.3 today. This is not a slow drift. It starts that day. Almost all of this volume is iOS. Android is only 11 tickets, so treat that split as directional.

query_feedback_categories, ranked by impact, puts repeat contacts on this skill at $41.3K since Mon, first in the list. Next is checkout retry at $28.6K. The $41.3K is Zendesk only. In-app chat is not in this pull, so the total is probably a bit higher, not lower.

I would start with the first-reply path for account_check, not a general coaching sweep. The rubric already marks it as a required first-reply step, and the 68 sessions show the miss happening there, not later in the thread. If 4.12.0 hid or moved the plan field, fix that before you retrain the queue. Retraining into a broken layout will not bring 31.3% back to 8.7%.

The alert is still open. query_alerts opened it on Tue at 16:42 UTC, tagged to 4.12.0, and nothing has closed it since. The daily series does not sag over the prior weekend and then fall. Monday is still 70.8, and the first broken day is Tuesday.

That is why I would treat this as a release issue first and a coaching issue second. If the plan field moved in 4.12.0, the 68 sessions are agents working around a layout they did not have the week before. Close the alert only after the score holds above 70 for a few days, not after a single coaching push.

The $41.3K is this week only, Zendesk only, and it is already first in the impact ranking. Checkout retry is second at $28.6K, so this is not a close call. Because in-app is missing from the pull, I would not use $41.3K as a ceiling in a review.

If the first-reply miss is what drives the repeats, fixing that path is the fastest way to take this off the top of the list. I would measure next week against the same Zendesk query, not against a blended channel number we do not have yet.

query_cohort_metrics finds 173 customers whose last order was 18-30 days ago. Usage started falling about a week before that, then orders stopped. query_cohort_categories does not attach a Zendesk ticket or an Intercom chat to any of them. There is no complaint on the record. They just went quiet, which is why this did not show up in the support queue.

I sent the questions in their locale. 58 of the 173 replied, so this is the people who still opened the message, not the whole quiet set. Treat the mix as directional. Most of the 58 point at two things. A fee they say they only saw at the last step: "didnt even see a fee until the last screen". And a renewal they say never arrived: "never got a renewal mail?? i would have stayed". A smaller group mentions a retry that failed and was never explained.

query_cohort_relative_metrics splits the 173 by prior usage. The top group, 41 people, was spending 2.14x the rest of the quiet set before they stopped. Those 41 are the ones I would start with. Leaving them in a generic win-back pool with the other 132 wastes the only signal we have on value.

I would not lead with a coupon. The 58 replies already give you a reason: the fee on the last screen, or the renewal email they say they never got. Attach the quote when you write, so whoever sends it can see why the wording changed. If you only have time for one pass, do the 41 first, and say the notice failed, not that you have a new offer.

For the fee group, say the last-step fee should have been visible earlier, and show the amount in the first screen this time. Do not hide it behind a new discount. The quote to keep in front of whoever writes it is "didnt even see a fee until the last screen".

For the renewal group, say the reminder did not go out, and give them a clean way to renew. "never got a renewal mail?? i would have stayed" is the line I would paste into the brief. 58 replies is not the whole 173, so I would keep the wording tight and see who actually comes back before you scale it.

Watch those 41 for a repurchase in the next 14 days, and keep the other 132 in a separate slice so a quiet person with low prior spend does not dilute the read. If the 41 move and the rest do not, the message was the right lever. If neither group moves, the fee and the missing mail were reasons, not the whole reason, and you will need another pass.

I would also keep a Zendesk and Intercom check on this cohort. They had 0 threads when they left. If they write after the note, that is useful, but a repurchase is the success metric.

query_alerts opened a critical on Tue at 14:11 UTC. query_metrics has the decline rate at 2.11% last week and 5.01% today, 2.37x, starting the same afternoon as 4.12.0. The 14 days before Tuesday sit in a 1.87-2.31% band, so this is not a noisy week that got a bit worse. It is a step change on a release day.

Ranked by impact, card declines are the most expensive category since Tue, $18.7K in Zendesk plus in-app. A lot of the quotes are the same move: the retry looks like a second charge, so people leave. One of them: "it said paid but my card got declined so i left". Another: "im not entering my card twice if it already took the money".

This is mostly iOS. Android is 7.2% of the declined checkouts, so treat Android as directional. I would not wait for a fuller Android sample before you act on the iOS path, which is where the $18.7K is sitting.

I would fix the retry state first, then the copy that makes it look like a second charge. If 4.12.0 changed the paid flag or the retry button, that is the patch. A general payment-provider review will take longer and will not explain a Tuesday jump that lines up with your 4.12.0 release window, which is where I would start.

get_theme_matrix shows card-decline complaints up in App Store and Google Play reviews across the category this week. get_score_series says the peer set is only about +0.4x. Your spike is steeper, and it starts on your release day, which the peer set does not share.

That is useful context, not a reason to wait. Public reviews also will not tell you your $18.7K number. They just say this is a theme in the market, and you are having a worse week than the peer set.

ask_responses has 34 replies in since Tue. 21 of them thought the charge had already gone through, so they did not retry. That matches the quotes already in Zendesk. 8 people retried, got a second decline, and stopped. The remaining 5 were unsure what the screen meant and closed the app.

The 34 is only people who answered, and it is iOS-heavy, same as the ticket volume, so treat the split as directional. It is still enough to confirm the first fix: make the failed state unmistakable, then take the "paid" wording off a declined retry.

Last 90 days, query_feedback_categories by volume is: search misses 2,416, paywall cut-off 2,084, checkout retry 1,771, fee clarity 1,209, renewal email 804. count_feedback totals 8,284 mentions across Zendesk, App Store, and in-app. If you ship in that order, search goes first and retry sits third.

Ranked by impact the order flips. Checkout retry is $128.4K, then fee clarity $91.6K, then the paywall $74.2K. Search leads on volume and falls to fourth at $52.9K. Renewal stays last at $36.1K. Volume is not the ranking I would ship from. The item people mention most is not the one that costs the most.

The quotes behind retry are blunt. "why do i have to pay twice??" shows up in Zendesk and in the App Store. Fee clarity is the same shape of surprise, just earlier in the flow: people reach the last step and only then see the amount. That is why fee is second in dollars even though it is fourth in volume.

I would put checkout retry first on the roadmap, then fee clarity, and only then the paywall. Search can stay on the list, but it should not keep the top slot on the back of 2,416 mentions. If you only have room for one of these in the next cycle, take retry. It is $128.4K of the $383.2K across the five items, and the quotes already tell you what "fixed" has to mean: one charge, a clear failed state, no second pay prompt.

get_kano classes checkout retry as expected, not a delight, in both App Store and Google Play reviews. get_theme_matrix has peer mentions of it rising from 41 a week, 12 weeks ago, to 97 this week. In the peer set it already reads as table stakes.

Public reviews are a market signal, not our $128.4K. I would still not plan as if retry is optional. Shipping it late will not look like a feature. It will look like catching up.

get_aggregate_report is 587 interview responses over the same 90 days. When they are asked to rank the five items, retry comes first, then fee, then the paywall. That matches the dollar order, not the volume order. Search is the one they mention in passing and then put lower when they have to choose.

The interview wording is the same as the tickets: a second charge, or a spin that forces a restart. 587 is a large reply set, but it is still the people who answered, not all 8,284 mentions. I would take it as confirmation. Retry first is the consistent answer across dollars, interviews, and the peer set.

You do not have to decide expand or roll back on day one, and I would not. ask_responses collected 112 replies before the change went out. The tone is cautious, not hostile. People wanted a heads-up in email, not a surprise in the app. A usual line: "the price is fine just tell me before I open the app and see it". A smaller set worried the new number would show up mid-cycle with no note at all.

query_metrics for the 14 days before the change sits at 2.0-2.4% complaints across the 11 markets. That is the baseline I would hold the next week against. If complaints jump and stay up, that is a price problem or a notice problem. If they jump and then settle, it is more likely the surprise, which is what the 112 replies already pointed at.

query_alerts is watching all 11 markets on day one. Two of them already went yellow. Both are thinner on volume than the other nine, so a handful of tickets can trip the alert. Treat those two as watch-outs, not as a reason to roll the other nine back. A full rollback on day one would throw away the markets that have not moved, and you would not learn whether the notice was the issue.

What I would do first is keep the nine quiet markets on the new price, fix the email notice, and hold the two yellow markets at the old price until you have a week of data. We can reopen expand vs roll back on day seven with the same complaint-rate query, market by market, rather than making that call from two yellow alerts on day one in two thin markets.

query_metrics on day 7: complaints peaked on day 2 at 6.8% and are at 3.1% today. The 14 days before the change sat at 2.0-2.4%, so this is not an old problem the new price uncovered. query_feedback in Zendesk, Intercom, and in-app is still mostly about how they found out, not the number: "the price is fine i just found out in the app with no email".

The two markets that went yellow on day one are still at 5.4% and 5.9%, and both are thin on volume, so I would keep holding those two and expand in the nine that are already flattening. A full rollback now would throw away markets that have already settled.

get_ratings has you at 4.14 this week, down from 4.47 twelve weeks ago. You need to climb 0.36 to get back to 4.5, and the curve has not flattened yet. App Store is most of the volume. Google Play is 18% of reviews, so treat the Android number as directional and do not plan a Play-only fix as if it will move the blended rating much.

query_feedback_categories on the low reviews: login crash 612, paywall cut-off 441, search misses 318, everything else 207. The first two are most of the drop. A usual App Store line is "app keeps crashing after login wtf". That starts showing up more after 4.11.2, then again after 4.12.0. Paywall quotes are quieter in tone and more tired: "it cut me off and i already paid".

Search is loud, but loud is not the same as what is pulling the average down. 318 reviews is a real pile, and I would not ignore it, but I would not bet the climb back to 4.5 on it. The 612 crash reviews and the 441 paywall reviews are the ones that sit in the 1 and 2 star band, which is what actually bends a store rating.

If I had to pick a first move, I would ship a stable login after 4.12.0, then the paywall cut-off. Those two are 1,053 of the 1,578 low reviews in this window. A search pass can follow. Waiting for the curve to bounce on its own is unlikely: it has been easing down for twelve weeks, not one bad week.

query_cohort_relative_metrics on the last 12 weeks agrees with the review mix. Fixing login crash and the paywall cut-off is what actually moves the rating. Search is loud, 318 reviews, and it barely bends the curve.

If you only ship search, I would not expect to get back to 4.5. If you ship the crash and the paywall, the curve has room to move, especially on the App Store side where most of the volume sits. Play will lag because of the 18% share, and I would not read a slow Play week as the patch failing.

ask_responses reached 79 people who left a low review in the last 12 weeks. Most say a stable login or a clearer paywall would change their mind. A few offered to edit the review: "would change my review if it didnt crash every time i open it". Search comes up. Almost no one said it was the reason they went below 4.5.

79 is a reply set, not all 1,578 low reviews, but it agrees with the cohort math. I would only ask someone to update a review after the crash fix is actually in their hands, not when 4.12.1 is merely scheduled.

I scoped this to your role, so this is not the whole company feed. count_feedback is 1,284 records in the last 28 days: Zendesk 612, App Store 331, in-app 226, Intercom 115. No ticket to anyone for a report. query_feedback_summary has checkout first, then renewal copy, then search. Intercom is only 9% of the slice (115 records), so do not overweight those quotes when you brief your team.

query_feedback_subtopics splits checkout into retry 214, timeout 137, fee copy 103, and locale 64. Retry is the one I would put at the top of a standup. The quotes are the same shape as the incident work around 4.12.0: "checkout just spins and i have to start over". Timeout is next, and it often shows up in the same thread, after the spin.

The daily series is climbing, 31 records a day 28 days ago, 71 today. This is not a one-day spike that you can wait out. Renewal and search are real, but they are behind checkout, and checkout is being pulled by the retry. Locale is 64 mentions, enough to note, not enough to lead with.

If you only have time for one thread this week, start with the retry. It is the biggest subtopic in your area, it is rising, and it is already tied to a release you can point at. I would not open a general checkout project. I would take the spin-and-restart path, then see whether timeout falls with it. The 1,284 already give you enough volume to brief that as the week of work, and you do not need a separate ticket to anyone else to get started on it this week with the slice you already have.

The quotes behind retry keep lining up. query_feedback is full of a spin, then a restart, then a customer who is not sure the first attempt went through. That is the same pattern as the decline work, just seen from your slice of the 1,284. Timeout and fee copy are present, but they are not what doubled the theme.

This month is louder than last month on every checkout subtopic, not only retry. Even so, retry is the one I would staff first. Locale at 64 is the smallest bar, and I would leave it as a follow-on unless one language is carrying most of those 64. I would check that before the next standup.

query_metrics for September: declines peaked at 1.83x the August average in the week of Mon 14 Sep, then eased to 1.21x by 30 Sep, 2.49% on the last day. get_dashboard_data matches those figures. The same query id is in the log, so if they ask how a number was built, you can rerun it. Nothing here is a screenshot of a dashboard with no query behind it.

The five questions map onto volume, timing, the retry, customer contact, and whether it was isolated. count_feedback traces each answer to a set of records: volume 612, timing 547, retry 408, contact 41, scope 28. The first three are solid. Contact and scope are thin, and I would say that in the pack, not hide it.

The timing question is the one they will press. The series is quiet through early August, starts to rise in the first week of September, and peaks in the week of Mon 14 Sep. It does not jump on a single hour and vanish. The retry question is next: 408 records sit on a failed retry, which is also what the Zendesk quotes describe. Contact is only 41 records, so any claim about how quickly people were reached is weaker than the volume and timing answers.

I would answer all five, point at the query behind each figure, and flag contact and scope as thin. The pack can go out a day early. That leaves time to pull a quote appendix for the first three questions, which is where the evidence is actually dense, before they follow up.

query_feedback can open the Zendesk, App Store, or in-app row behind any of those counts. Volume, timing, and retry all have a mix of the three channels. Contact is mostly Zendesk, which is why n=41 feels even thinner once you notice App Store reviews rarely tell you whether anyone was reached.

If they ask you to walk a single number, start with the 1.83x peak in the week of Mon 14 Sep and the 2.49% close on 30 Sep. Both come from query_metrics, and both match the dashboard pull. Put the 41 and the 28 last, and say they are thin. For more on contact, go back to Zendesk. 41 records will not carry a strong claim.

get_benchmark shows three peers already live in market 15. get_ratings, App Store and Google Play, has them at 4.41, 4.18, and 3.96. You do not have a listing yet, so there is no rating of yours to plot, and I would not invent one. Day one will be read against that 4.41-3.96 band, not against a score from your other markets.

The gaps they get mentioned on are checkout in the local currency, and delivery promises that do not match what arrives. That is the bar on day one, not a later release. A customer who cannot pay in the local currency, or who is promised two days and waits six, will not give you a grace period because you are new.

There is no local ticket history of yours to cost out, because there are 0 orders. The cost of getting this wrong is the first-week rating and the first-week delivery complaints, which are hard to walk back in a store listing. The cheaper move is to treat currency checkout and delivery promises as launch blockers, not as a month-two patch.

I would lock those two into the launch list now, arm alerts before the first order, and talk to locals in their language before you freeze the copy. Thirty days is enough to do that. It is not enough to learn these two things after you are live and then try to patch a 3-handle rating.

ask_responses is 41 locals, in their language. That is enough to see the two themes, not enough to rank cities, so I would not break this down further than the market. They say the same things the peer reviews say. Checkout in the local currency is expected. Delivery promises are a trust issue.

One line, translated plainly: "they say 2 days but it came in 6". A few also mention a rival they left after a late order and then stayed with because checkout was clear. I would put both lines in the launch brief. 41 is a small set, so treat city-level splits as directional at best, and keep the finding at the market level.

query_cohort_metrics has a market 15 cohort with 0 orders, which is what you want 30 days out. query_alerts is armed on checkout errors and delivery-promise misses, so a miss shows up on day one, not in a monthly report. Delivery-promise mentions in the peer set have been climbing for 12 weeks, 14 a week then, 38 this week.

I would keep the thresholds tight for the first 14 days. 41 interviews already told you which two things to watch. We will not have a rating of our own until the listing is live, so the early read will be your own alerts plus the first reviews.

Yes, with limits you set, and nothing is live yet. query_feedback_insights has 41 approvals from the last 30 days, 19 of them Zendesk, the rest in-app and App Store reply work. propose_playbooks folded those into 5 drafts. Each draft has a cap, an escalate-if, and a stop condition. The drafts will not go live until you save them, and they will not widen themselves later.

The 41 approvals are the pattern, not a prediction. Most of them are routine replies: a status update, a missing-mail pointer, a fee explanation that was already cleared. Those are the drafts I would let run inside a cap. The approvals also include a handful of charge questions and one messy refund thread. Those should stay outside the cap and escalate, because a wrong auto-reply on money is more expensive than a slow one.

I would start the caps tight. A daily send cap on each playbook, a hard stop if a thread mentions a charge dispute or a regulator, and an escalate-if when the amount is over $100. That is conservative on purpose. You can loosen a cap after you have seen a week of traffic. You cannot unsend a reply that went out because the cap was generous on day one.

What I would do first is save the 5 guardrails as drafted, with those money threads excluded, and let the loop run on the routine 30-day pattern. Stay out of the inbox for the ordinary cases, and stay in it for anything the guardrail refuses. If you want one cap tighter or looser before we turn it on, change that guardrail now. After it is live, you can still change it. You should not have to sit in every thread to keep the loop inside those lines.

read_alerts for the last 7 days: one escalation, a charge dispute for $182.40. The guardrail correctly refused to auto-reply and routed it to you. That is the money case the cap was written for. query_alerts shows the other 38 loop actions stayed inside the caps you saved at 09:14 last week, including the Zendesk and App Store reply work.

This is one week of traffic, not a quarter, so I would not relax a cap on the back of it. If you want one tighter, change that guardrail. You do not have to sit in the loop to keep it inside the lines you already set.