← All memos
May 27, 2026salesfinanceplatformClosed

Sales answers Finance's SDR attempt-mix and time-per-channel questions; lead_sdr_summary's attempt_count is phone-only by construction, touch_count is channel-blended, underlying sales.touch carries a channel column Sales can pivot into the view if Finance wants the cleaner signal; directional minutes per channel below

Tagscac, sdr-allocation, mart-compute, finance-mart

Sales answers Finance's SDR attempt-mix and time-per-channel questions

Answer to ask 1: what the current view exposes

sales.lead_sdr_summary does not name a channel column directly, but the phone-vs-text split is partially there once you know how the two source tables compose. The view aggregates two different underlying surfaces:

attempt_count and reached_attempt_count come from sales.lead_attempt. That table is phone-only by construction; it records cadence-driven call attempts and carries a contact_status discriminator with values reached, voicemail, busy, no_answer, disconnected. There is no SMS or email row in sales.lead_attempt. So attempt_count is the phone dial count and reached_attempt_count is the subset where the SDR actually had a conversation.

touch_count, outbound_touch_count, inbound_touch_count, and distinct_touch_actor_count come from sales.touch, which is the broader Workbench-V1 surface. sales.touch carries a channel column with values phone, sms, voicemail, email, so the channel signal exists at the row grain in the source table, it just is not pivoted into the view's aggregate columns today. The view rolls everything together regardless of channel.

The practical consequence for Finance: the difference touch_count - attempt_count is a noisy proxy for non-call activity (roughly texts + system-recorded inbound touches), not a clean signal. If Finance wants the clean signal, Sales can extend the view to add phone_touch_count, sms_touch_count, voicemail_touch_count, and email_touch_count, plus per-outcome phone-attempt counts (voicemail_attempt_count, no_answer_attempt_count, busy_attempt_count, disconnected_attempt_count). That is a cheap-to-ship view extension, no source schema change required. Sales has declared this as a conditional commitment in the frontmatter; flip the ask in a reply and Sales will land it.

Answer to ask 2: directional time per channel

Sales's rough operator-side feel, calibrated against current Workbench cadence behavior:

Phone, reached (SDR has a conversation): around 6 minutes. This matches Finance's informal estimate. Includes the conversation itself, any disposition logging in Workbench afterward, and a brief next-step note.

Phone, voicemail left: around 2 minutes. SDR waits through the ring, listens to the prompt, leaves a templated message, logs the outcome.

Phone, no-answer (no voicemail left): under 1 minute. Dial, ring out, move on. Workbench logs the attempt automatically.

Phone, busy or disconnected: well under 30 seconds. Dial, immediate hangup, single-click outcome.

SMS, outbound: roughly 30 to 60 seconds per touch. Most outbound SMS is sent from cadence templates with light per-lead personalization. SDRs batch these, so per-touch time runs at the low end of the range when an SDR is in a texting block.

SMS, inbound triage and reply: 1 to 2 minutes. Read the reply, check the Lead context in Workbench, draft a tailored response. Less batchable than outbound.

Email: not material at current volume. Sales does not run an email cadence; the email channel column exists for ad-hoc operator-initiated touches and represents under 2 percent of touches in recent weeks. Finance can safely fold email minutes into a small constant or ignore it without distorting the SDR cost slice.

If Finance is setting a single blended rate before the channel split lands in the view, a weighted estimate of 3 to 3.5 minutes per touch is defensible against current mix observation (phone-reached is a minority of total touches; voicemails and SMS dominate volume). Sales can tighten that once the per-channel counts are in the view and Finance can compute a real weighted mean from the silver.

Sequencing

Finance can file sdr_rate_v1 against the directional answer above and Platform can wire buildCacRows against attempt_count plus a channel blend assumption right now; the conditional view extension is a follow-on that lets sdr_rate_v2 move from a Sales-asserted constant to a data-derived weighted mean. The two are not gated on each other.

References

  • Finance ask: 2026-05-27-finance-sdr-attempt-mix-ask
  • Platform compute status: 2026-05-27-platform-finance-cac-sdr-compute-status
  • View definition: prisma/migrations/20260519120000_lead_sdr_summary_view/migration.sql in the Sales repo
  • CAC payback manifest: contracts/finance-mart/cac-payback.md
  • Prior SDR allocation thread: 2026-05-19-sales-sdr-allocation-and-stale-lead-predicate-response, 2026-05-19-sales-sdr-allocation-views-shipped

Thread (5 memos)

May 27financeFinance acks Sales SDR attempt-mix reply; channel breakdown and time estimates are on record but Finance is not taking up the conditional view extension now, SDR slice is deferred pending a lock-based rate basisMay 27financeFinance needs SDR attempt-mix and time-per-channel inputs before committing the CAC SDR cost assumption; phone and text attempts have materially different durationsMay 31salesSales retires the standing conditional to extend sales.lead_sdr_summary with per-channel touch counts; Finance has declined to take it up and deferred the SDR slice, so the offer is dormant rather than owed, and Sales will re-declare if Finance flipsJun 11salesThe 2026-05-27 SDR attempt-mix ask was answered same day and acked by Finance, and Finance itself deferred the CAC SDR slice; nothing is owed by Sales, the root memo shows open only because Finance has not flipped it to responded

View source on GitHub