SalesThumb's sales playbook automatically sends SMS nudges after a job is paid for — a review request, a warranty-registration reminder, a cross-sell pitch, and so on. The configuration for those nudges lives at Settings → Sales playbook (/app/settings/playbook), which is deliberately separate from /app/playbook, the live queue where you watch and manage plays that are actually in flight. The settings page carries a "View live queue" button back to that page, and the live queue in turn links back here via a "Configure templates" link — so you move between "watch what's running" and "edit what will run" without the two views getting tangled.
Notification preferences
At the top of the page are two independent email toggles, both on by default: the "Daily playbook reply digest" (an 8am email summarizing yesterday's customer replies, with one-tap links into hot-lead conversations) and the "Failure alert email" (fires when 5+ plays fail in any rolling hour — useful for catching a broken Twilio connection early). Turning either off only silences that email; the underlying reply inbox and failure data still work the same in-app regardless of these settings.
Editing templates
Below that is the templates editor, with one row per play kind: Review request, Warranty registration, Cross-sell, Maintenance check-in, Win-back offer, and 1-year anniversary. Each row has an "Enabled" checkbox, a "Fire after N days" delay (0-730 days), and an SMS body textarea (1,600-character limit, with a live counter). A "Default" badge means the shop is using SalesThumb's stock copy/timing for that kind; once you save a change it becomes "Custom," and a "Reset to default" button appears to drop your override and revert to the stock version. The "Save" button only lights up once something in that row actually differs from what's saved.
Bodies support merge fields — {{firstName}}, {{discountPercent}}, {{pitch}}, {{shopName}} — and a preview box under each textarea renders the message live with sample values (a fictional customer named Maria) as you type, using service copy matched to your shop's configured vertical. A "First-time / Repeat" toggle above the list swaps the sample {{pitch}} text between what a brand-new customer would see versus a repeat customer, mirroring how the real cross-sell logic picks copy at send time — it only changes the preview, not any saved data.
Test-firing before you save
A "Test-fire to:" phone field at the top of the list is shared by every row's "Test" button and by "Test all." One non-obvious point: Test sends whatever is currently in the textarea, saved or not — so you can fire an unsaved draft to your own phone before committing to it. The number is remembered in your browser (localStorage) so you don't retype it each visit. "Test all" fires every row that's enabled and has at least 5 characters of body text, one after another, and reports how many sent versus failed. These are one-off SMS sends to your phone only — they don't get logged as a real customer conversation.
The gotcha: snapshot semantics
The one behavior worth internalizing: changes here are not retroactive. When a play gets enqueued, its SMS body is captured into that play's own record at that moment. So editing a template's copy, delay, or enabled state only changes future enqueues — any play already queued or in flight keeps the exact wording (and will still fire) it had when it was created, even if you disable or rewrite the template five minutes later. If a customer got an oddly-worded message, check what the template said when the job was paid, not what it says now.