A Weekly Telesales Review: Five Decisions to Make from Your Team's Data

Why a Hard-Stop Review Changes How Your Team Operates

Imagine you lead a seven-person telesales team for a Thai online shop that sells skincare products. Every Monday morning you open a chat group and ask how things are going. Replies trickle in across the day. Some tasks from last week are still open. Nobody is sure whose job it was to follow up with lapsed buyers from the segment exported on Friday. By Wednesday the week has already lost momentum — not because your team is underperforming, but because there was no single moment where decisions were made and owned.

This guide offers a structure for making five decisions in one sitting, with a named owner for each. Salesforce's pipeline-review guidance describes a short overview, discussion of priority problems and an action-item wrap-up within 30 minutes; it addresses individual deal reviews, so the five-slot team agenda here is our adaptation. IBM explains choosing sales metrics that align with business goals. Our additional operating recommendation is to record an owner, a target and an agreed trigger for reviewing each priority metric. That owner-and-trigger practice is our recommendation, not a rule attributed to IBM.

HubSpot's sales-meeting guide recommends a timed agenda, preparation and a close that assigns action owners and deadlines. We use those practical ideas here without treating the article as an independently verified productivity study or promising a percentage improvement. Whether this agenda helps your shop is a question to assess from your own completed decisions, overdue work and comparable observations.

The five decision slots below are ordered so that urgent operational problems come first (overdue tasks, contactability, customer issues), followed by interpretation work (observed purchases), and then forward-looking experimentation. You do not need to spend equal time on each. If overdue tasks take two minutes to clear, move on. If contactability is the week's real puzzle, spend eight minutes there.

Sources: Salesforce — How to Run a Better Sales Pipeline Review · IBM Think — Sales Metrics: What and How to Track · HubSpot — How to Run an Effective Sales Meeting in Under 20 Minutes

Setting Up the Review: Scope, Inputs, and Ground Rules

Before the first meeting, establish three ground rules that will apply every week. First, the review covers only what happened since the last review and what needs to change before the next one. Historical context is useful only when it explains a current decision. Second, every item on the agenda must point to a decision, not just an observation. 'Call-reach rate dropped' is an observation; 'We will shift afternoon calls to 11:00–13:00 for the high-value segment starting Tuesday, and Khun Ake owns the result' is a decision. Third, the meeting ends at 30 minutes regardless of whether all items are resolved. Unresolved items move to a named owner's task list, not to next week's agenda.

Prepare the previous task list with owners and deadlines, a call-activity summary by rep and segment, customer-issue notes, and the purchase tally and experiment proposal needed for this review. Use your team’s separately verified activity and purchase records for those calculations. CasperBrain supports authorised customer CSV exports, with field visibility governed by permissions. This guide does not specify which purchase or scoring fields a CSV contains, or promise automatic synchronisation with a calling tool.

Keep the attendee list tight. The team lead, the reps who own the week's active segments, and one person responsible for recording decisions are enough. Broader updates belong in a separate channel.

Decision 1 — Overdue Tasks: Clear the Queue Before It Grows

The first decision slot answers one question: which tasks from last week are still open, and what happens to each of them right now? The three possible answers are close it (the task is done or no longer relevant), reassign it (the original owner cannot complete it this week), or extend it with a new deadline and a reason.

A task that gets extended two weeks in a row is a signal, not just a scheduling problem. It usually means the task was defined too broadly, the owner did not have the information needed to act, or the customer context changed and the task should be closed instead. Spend 30 seconds asking why before extending again.

Our recommended ownership rule is simple: give every open task one named accountable person. When responsibility is unclear, follow-through becomes harder to verify. If a follow-up was assigned to 'the team' last week, name one person to coordinate it and record any collaborators separately.

Suggested time allocation for this slot: two to four minutes. If the queue is clear, move on immediately.

Decision 2 — Contactability: Adjust Time or Channel When the Numbers Drop

Contactability is the proportion of call attempts that result in a genuine conversation. It is calculated per rep and per segment, not as a single team-wide average, because a low team average can hide one rep reaching customers easily while another reaches almost nobody.

In practice, calls made and positive reply rate function as early, activity-level signals — they tell you whether effort is translating into real contact before slower outcomes such as repurchase rate reveal the downstream effect. IBM's sales metrics framework distinguishes leading indicators (activities and interactions that precede a result) from lagging indicators (outcomes such as churn rate and customer lifetime value that reflect cumulative relationship health). Thinking of contactability as a leading signal and repurchase rate as a lagging one is a practical interpretation of that framework, not a claim the cited sources make explicitly for this telesales-retention context. A contactability rate that falls below your team's normal baseline is an action threshold, not just a data point to note.

When contactability drops, the decision is which lever to pull. Common options are changing the call window (for example, shifting from late afternoon to late morning for a particular segment), switching the first contact to a different channel (LINE message before a call), or reducing the queue size so reps concentrate attempts rather than spreading them thin. Each option has a cost: changing the window disrupts rep schedules; switching channel adds a step; reducing queue size means fewer customers contacted per week. The decision is a trade-off, and naming it clearly helps the team understand why the change is happening.

Record the chosen lever, who owns implementing it, and what contactability rate you expect to see next week. If the rate does not improve, that expectation becomes the basis for the next decision.

Sources: IBM Think — Sales Metrics: What and How to Track

Decision 3 — Customer Issues: Flag Problems Before They Raise Churn Risk

Customer issues — complaints, unfulfilled promises, delayed refunds, or any moment where the shop failed to deliver what was said — deserve their own slot because they interact with your retention work in ways that pure activity metrics miss. A customer who received a broken promise this week and is also in your re-engagement segment this week will respond very differently to a follow-up call than your data alone suggests.

IBM's sales metrics framework lists churn rate as a lagging indicator of customer relationship health. By the time churn appears in aggregate numbers, the individual decisions that caused it are weeks old. Reviewing issues in real time — this week's complaints, this week's refunds — gives the team a chance to act before the lagging indicator moves.

The decision in this slot is not to resolve every complaint during the meeting. It is to identify which issues are likely to affect contacts in the active segment this week, assign a rep to handle each one before a call takes place, and flag any issue that reveals a process gap the team lead needs to escalate (for example, a fulfilment delay that is generating complaints across multiple customers).

Keep a short written log of issues reviewed each week. Over time, patterns become visible — recurring product complaints, a particular courier causing repeated problems, a script that over-promises delivery speed — and those patterns inform operational decisions beyond the telesales team.

Sources: IBM Think — Sales Metrics: What and How to Track

Decision 4 — Observed Purchases: Read the Repeat-Buy Rate Carefully

This slot reviews how many customers your team contacted in the prior period have since made another purchase. It is the most analytically delicate part of the review, because the number is easy to misread.

The figure is an observed purchase rate: the share of contacted customers who bought again within a defined window. It does not show that calls caused those purchases; some customers may have bought anyway. Shopify describes descriptive analytics as examining what happened and diagnostic analytics as investigating why. Those categories do not by themselves establish causation. Our recommendation is to keep an observed purchase rate separate from a causal claim, and to use an appropriately designed comparison before attributing a difference to contact.

What you can use the rate for: comparing it to your baseline repeat-buy rate for the same customer segment without telesales contact, and watching whether it moves week to week in ways that correlate with changes in your approach. If the observed rate for a particular RFM segment is consistently close to the baseline, the team's effort may be better directed elsewhere — but treat any such gap as a hypothesis worth testing rather than a proven ranking of which segments respond best to telesales. A historical gap in observed rates is a starting point for an experiment, not a guaranteed result.

Two arithmetic cautions. First, calculate the purchase rate at the customer level: count how many distinct customers (by customer ID) made at least one new order, then divide by the total number of distinct customers contacted. Order IDs are useful as a secondary check — for example, to count how many orders those customers placed in total — but they should not replace customer IDs as your denominator. One customer who placed two orders should count as one contacted customer who repurchased, not two. Second, be careful about cohort maturity: customers contacted only a day or two before you run your tally may not have had enough time to buy again even if they intended to. Only compare cohorts where the full observation window has elapsed for every customer in the group.

Sources: Shopify — Ecommerce Data Analytics: A Guide for Enterprise Teams

Decision 5 — Next Experiment: One Testable Change with a Named Owner

The final slot is forward-looking. Pick one change, define a hypothesis, assign an owner and set an operational target and review date. Keeping other deliberate changes stable makes a pilot easier to interpret; changing one thing alone still does not prove causation. Record differences in customers, timing and exposure, and plan a comparable control when the aim is to estimate an effect.

A well-formed experiment has four parts. The hypothesis states what change you expect and why: for example, 'Sending a LINE message 24 hours before calling the win-back segment will increase the call-reach rate because customers will recognise the number.' The owner is one named person responsible for setting it up and reporting back. The success metric is specific: 'Call-reach rate for the win-back segment rises from 28% to at least 35% over the next two weeks.' The review date is fixed: you will evaluate it at the second weekly review from now, not 'when we have enough data.'

Shopify's analytics framework uses the term prescriptive analytics for this layer — the stage where insight converts into recommended action. For a telesales team, the experiment slot plays the same role: it moves the team from reporting on what happened to deciding what to try next.

If the experiment produces a clear result, document it. If it is inconclusive, document the reason and decide whether to refine or drop it. Either outcome is useful. The teams that improve fastest are not those whose experiments always succeed; they are the ones that close the loop on every test and carry the learning forward.

Sources: Shopify — Ecommerce Data Analytics: A Guide for Enterprise Teams

A Worked Example: NakornShop's Monday Review

The following is a fictional teaching example. All names, numbers, and outcomes are invented for illustration. NakornShop is a hypothetical Thai online shop selling home-cleaning products. The team lead, Khun Pim, runs a 30-minute review each Monday morning with four reps: Ake, Bao, Chai, and Dao.

Inputs prepared before the 28 October meeting: the task list from the previous review, a call-activity summary for 21–25 October, three customer-issue notes, and a separate purchase tally for 80 distinct customers first contacted during 14–18 October. The purchase cohort is from that earlier period, not the immediately preceding week. Count customers by customer ID and cross-check order IDs separately. Bao also brings one experiment proposal.

The meeting note below shows how each decision slot played out.

NakornShop Weekly Review — Fictional Meeting Note, Monday 28 October

The table below shows all five decisions from NakornShop's fictional Monday review. Each row states the slot, what the data showed, the decision made, who owns it, and the deadline.

Decision 1 — Overdue tasks. Three tasks carried over from last week. Task A (follow up with 12 customers in segment 'R3F2M2' — Recency quartile 3, Frequency quartile 2, Monetary quartile 2, a mid-tier group selected by Khun Pim based on additional non-RFM criteria identifying them as recently lapsed) was completed by Ake on Friday — closed. Task B (send product information to two customers who requested it) was still open; Bao had not yet received the updated product sheet from the content team. Decision: extend to Wednesday once the content team delivers; Bao owns it. Task C (log call outcomes for Thursday's batch) was missed; Chai logged only 60 of 75 outcomes. Decision: Chai completes the remaining 15 by end of Monday.

Decision 2 — Contactability. Call-reach rate for the week: Ake 41%, Bao 38%, Chai 44%, Dao 29%. Team baseline from the prior four weeks: 39%. Dao's rate dropped 10 percentage points from his prior-week rate of 39%. Reviewing Dao's call log, most of his attempts were between 15:00 and 17:00. The segment he worked — customers in rural provinces — historically shows better reach in the 10:00–12:00 window based on prior weeks' logs. Decision: Dao shifts his call window to 10:00–12:00 for the coming week. Dao owns it. Khun Pim will check Dao's reach rate at next Monday's review.

Decision 3 — Customer issues. Three issues logged. Issue 1: a customer complained that a rep promised same-day dispatch, but the order was shipped the following day. Assigned to Ake to call the customer before any further segment contact this week and acknowledge the delay. Issue 2: two refund requests for a cleaning concentrate that customers said caused skin irritation — flagged to Khun Pim to escalate to the product team; reps pause promotion of that SKU. Khun Pim escalates the reports to the qualified product, quality or compliance owner, or the supplier’s formal review process. Promotion can resume only after that process is complete and the responsible qualified owner has formally approved it. Issue 3: one customer was called twice in the same week by different reps because the segment list was not deduplicated before the call queue was built. Decision: Chai adds a deduplication check to the queue-building step before next week's contacts.

Decision 4 — Observed purchases. For this fictional example, use Bangkok calendar-day boundaries and define each 14-day window as [first-contact day, first-contact day + 14 days). First contact on 14 October therefore closes at the start of 28 October; first contact on 18 October closes at the start of 1 November. At the 28 October review only the earliest windows have closed, so the full cohort is incomplete. Of the 80 distinct customers, 16 have at least one new order within their individual window and before the review cutoff: 20% provisionally. A separate check finds 19 orders from those 16 buyers. The historical segment baseline is about 17%, but the arithmetic difference of 3 percentage points is not yet a valid mature-cohort comparison or causal lift. Decision: freeze each customer’s tally at their own window end, verify matched baseline definitions and report the mature observed rate at the 4 November review, after the last window closes on 1 November. Purchases after an individual window ends are excluded.

Decision 5 — Next experiment. Bao proposed sending a short LINE message the evening before calling a customer, stating the team's name and inviting the customer to ask any product questions. Hypothesis: customers who receive a pre-call message will be more likely to answer when called the next morning, raising Bao's personal reach rate from 38% to at least 45% over the two-week test. Owner: Bao. Metric: reach rate for his assigned batch over the next two Mondays. Khun Pim records the baseline (38%) and sets the review date for 11 November. No other experiment runs simultaneously.

Agenda Time Budget for a 30-Minute Review

The time allocations below are starting points, not rules. Adjust based on what your data shows each week. A week with no overdue tasks and no customer issues should free up eight to ten minutes for a deeper discussion of contactability or the experiment result.

Salesforce's pipeline-review guidance recommends a brief overview, focused time on the top priority problems, and a defined wrap-up for action items — all within 30 minutes. The same logic applies here: the hard stop is not a courtesy to participants' calendars. It is the mechanism that forces the team to prioritise during the meeting rather than exploring everything loosely.

Sources: Salesforce — How to Run a Better Sales Pipeline Review

Limitations and Common Mistakes to Avoid

An incomplete cohort gives customers unequal time to buy. Compare rates only after every individual observation window has closed, applying the same eligibility, time boundaries and order definitions to the baseline. For any purchase dataset your team prepares, document its coverage and gaps separately. The CasperBrain capability stated here is authorised customer CSV export with permission-based field visibility; do not assume that this customer export supplies the purchase-level inputs needed for the calculations in this guide.

The numerator for repeat purchase counts distinct customers with at least one eligible order; the denominator counts distinct contacted customers. Count customer IDs, not rows or order IDs. In a generic external order-level file or a joined spreadsheet, one customer may occupy several rows; that warning does not describe a CasperBrain order-export capability. Keep order totals as a separate secondary check.

CasperBrain RFM uses four quartiles, where 1 is best and 4 is worst. The text code 114 means Recency 1, Frequency 1 and Monetary 4. If you compare score values with another method, first verify that method’s direction and number of levels. This explains the scoring convention, not the columns available in a customer CSV. A score code alone does not establish that a customer has lapsed or that contacting them will help; those judgments require additional evidence.

CasperBrain supports authorised customer CSV exports and permission-based visibility for planning and review. No automatic synchronisation with CasperCall or another calling tool is documented in the product constraints used for this guide. If your workflow uses another system, verify its supported transfer and permission requirements separately; this guide does not promise an integration or state that every possible transfer must be manual.

Do not turn the weekly review into a performance tribunal. The five-slot agenda is designed to decide what changes next week, not to assign blame for last week. A rep with a low reach rate gets a changed call window and a clear success target — if the pattern persists across multiple weeks after deliberate adjustments, a separate coaching conversation is the right venue, not the group review.

Finally, resist the temptation to add a sixth decision slot because the data surfaces something interesting. Interesting observations belong in a parking-lot note. The discipline of five decisions in 30 minutes is itself a decision about what matters most this week. Teams that try to cover everything weekly end up covering nothing deeply.

Sources: Shopify — Ecommerce Data Analytics: A Guide for Enterprise Teams

Troubleshooting: When the Review Stops Working

Three patterns signal that a weekly review has drifted from decision-making into reporting theatre. The first is when the same overdue tasks appear on three or more consecutive agendas. This means either the task definition is wrong (too broad, missing information, not actually actionable this week) or the ownership assignment is wrong (the named owner does not have the authority or resources to complete it). Fix the task, not the person.

The second pattern is when Decision 4 consistently shows that the observed purchase rate for the active segment is indistinguishable from the baseline rate. This does not necessarily mean the team is failing — it may mean the segment choice is worth re-examining. Consider whether a different RFM segment might show a larger gap in historical observed rates between contacted and uncontacted customers. Treat that gap as a hypothesis and test it deliberately rather than assuming it reflects telesales impact. A segment that buys at roughly the same rate regardless of contact may not be the best use of calling capacity, but confirming that requires a controlled experiment.

The third warning sign is an experiment that never reaches its review. Keep the review date even if the result is inconclusive, and record the counts, observation window, comparison design and missing evidence. Inconclusive does not prove there is no effect or that it is smaller than a detectable threshold. The available uncertainty and measurement limits must inform whether to stop, refine or run a further planned test.

If the 30-minute limit is consistently broken, the most common cause is that Decision 4 or Decision 5 is being treated as an open discussion rather than a focused decision. Assign a timekeeper role to a different team member each week. The timekeeper's only job is to signal when a slot has reached its allocated time and ask the team lead to call the decision.

Turning Five Weekly Decisions into a Learning System

A single weekly review produces five decisions. Twelve consecutive reviews produce a searchable log of 60 decisions, their owners, and their outcomes. That log is how a telesales team builds institutional knowledge — the kind that survives rep turnover and informs segment strategy beyond what any single data export can show.

Keep the meeting notes in a shared document that every team member can read. Record not just the decision but the reasoning behind it: why Dao's window was shifted, which customer issue revealed a script problem, which experiment confirmed a hypothesis and which failed to move the needle. When a new rep joins, that document is a training resource. When the team lead is absent, it allows another person to run a coherent review without starting from scratch.

Our operating recommendation is to agree what deviation prompts a review, rather than recording a target alone. As comparable observations accumulate, revisit those triggers using the recorded segment, time window and data coverage. Historical baselines can support a discussion; they do not guarantee that a threshold is calibrated or that acting on it will improve results. IBM supports aligning metrics with business goals, not the specific ownership-and-threshold rule proposed here.

The five-slot structure described in this guide is a starting point. Once the team is running it smoothly — decisions made, owners named, hard stop respected — you can adapt individual slots to fit your shop's specific rhythm. What matters is that every slot ends with a decision, not a discussion.

Sources: IBM Think — Sales Metrics: What and How to Track

Sources and editorial method

Examples are fictional and contain no customer records. Prepared by the CasperBrain team with AI drafting assistance; facts and language are checked before publication.

• HubSpot — How to Run an Effective Sales Meeting in Under 20 Minutes
• Salesforce — How to Run a Better Sales Pipeline Review
• IBM Think — Sales Metrics: What and How to Track
• HubSpot — 38 Sales KPIs Every Company Should Measure
• Shopify — Ecommerce Data Analytics: A Guide for Enterprise Teams