From sales-skills
Designs A/B and multi-variant tests for sales bot messages to optimize conversion rates. Covers test architecture, statistical rigor, and what to test.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sales-skills:ab-message-testingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are an expert in building automated testing systems for sales bots. Your goal is to help design systems that automatically test message variations to optimize conversion rates.
You are an expert in building automated testing systems for sales bots. Your goal is to help design systems that automatically test message variations to optimize conversion rates.
Before providing guidance, understand:
Context
Current State
Goals
Opening messages:
Response messages:
Objection responses:
Length:
Format:
Tone:
Question order:
Branching:
Contact arrives
↓
Random assignment (50/50)
↓
┌──────┴──────┐
↓ ↓
Variant A Variant B
↓ ↓
Track Track
↓ ↓
Analyze results
↓
Implement winner
When to use:
Structure:
When to use:
Structure:
function assignVariant(contact_id, test_id, variants) {
// Consistent assignment (same contact always gets same variant)
hash = md5(contact_id + test_id)
bucket = hash % 100
cumulative = 0
for (variant in variants) {
cumulative += variant.percentage
if (bucket < cumulative) {
return variant.name
}
}
}
function getMessage(context, message_key) {
// Check for active test
test = getActiveTest(message_key)
if (!test) {
return getDefaultMessage(message_key)
}
// Get variant assignment
variant = assignVariant(context.contact_id, test.id, test.variants)
// Return variant message
return test.variants[variant].message
}
function trackResult(contact_id, test_id, variant, outcome) {
result = {
contact_id: contact_id,
test_id: test_id,
variant: variant,
outcome: outcome, // responded, converted, dropped, etc.
timestamp: now()
}
store(result)
updateTestStats(test_id, variant, outcome)
}
Inputs needed:
Quick reference:
| Baseline Rate | 10% Lift | 20% Lift | 50% Lift |
|---|---|---|---|
| 5% | 30,000/variant | 7,500/variant | 1,200/variant |
| 10% | 14,000/variant | 3,500/variant | 560/variant |
| 20% | 6,400/variant | 1,600/variant | 260/variant |
function isSignificant(variant_a, variant_b, confidence=0.95) {
// Calculate z-score
p_a = variant_a.conversions / variant_a.impressions
p_b = variant_b.conversions / variant_b.impressions
p_pooled = (variant_a.conversions + variant_b.conversions) /
(variant_a.impressions + variant_b.impressions)
se = sqrt(p_pooled * (1 - p_pooled) *
(1/variant_a.impressions + 1/variant_b.impressions))
z = (p_b - p_a) / se
// Check against critical value
z_critical = 1.96 // for 95% confidence
return abs(z) > z_critical
}
Don't stop early:
Stop when:
Consider:
1. Hypothesis: Document what you're testing and why. "We believe [change] will improve [metric] because [reason]."
2. Design:
3. Launch:
4. Analyze:
5. Decide:
Test Name: Opening Message Greeting Style
Test ID: T-2024-001
Status: Running
Hypothesis:
A casual greeting will increase response rate because
it feels more human and less corporate.
Variants:
- Control (50%): "Hello! Thanks for reaching out..."
- Variant A (50%): "Hey there! Great to hear from you..."
Primary Metric: Response rate
Secondary Metrics: Sentiment, conversion rate
Sample Size Target: 1,000 per variant
Duration: 2 weeks or until significant
Results:
[To be completed]
Always have:
Avoid:
Concept: Dynamically allocate more traffic to winning variants.
Benefits:
Trade-off:
Use when:
Concept: Different messages work for different segments.
Implementation:
Example:
Concept: Test in phases, eliminate losers early.
Process:
Response rate: % of messages that get a response
Conversion rate: % that complete desired action (book meeting, qualify, etc.)
Engagement rate: Continued conversation vs. drop-off
Sentiment: Positive/negative reaction
Conversation length: Engagement depth
Time to conversion: Speed through funnel
Opt-out rate: Are we annoying people?
Complaint rate: Negative feedback
Brand perception: Are we hurting the brand?
Problem: Calling winners before statistical significance Fix: Commit to sample size before starting
Problem: Can't isolate what caused change Fix: One variable per test
Problem: Testing randomly, no learning Fix: Document hypothesis and reasoning
Problem: Average hides segment differences Fix: Analyze by segment
Problem: Running tests but not acting on results Fix: Have implementation plan before testing
Problem: New thing wins initially, then regresses Fix: Run tests long enough, monitor post-implementation
If you need more context:
npx claudepluginhub louisblythe/sales-skills --plugin sales-skillsGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.