Rymac call funnel skill
Builds the conversion plumbing that turns site traffic into scheduled calls: chat scheduler, AI voice agent, emergency escalation that pings a live on-call human, non-emergency booking into one shared calendar engine, and after-hours handling.
by oathdriven·MIT license·★ 28 Stars on the repo·GitHub ↗
Use now
npx degit oathdriven/rymac-skills/skills/rymac-call-funnel#main ~/.claude/skills/rymac-call-funnelChecked ·commit main
Inside this skill
SKILL.md · the author's own words# RyMac Call Funnel Wire a site to convert visitors into scheduled calls, with a human-ping path for emergencies. This is the architecture running live on RyMac's own CRM platform; the pattern works with any stack (a CRM with AI channels, or Vapi/Twilio + a calendar API wired directly). ## The architecture (one persona, many channels) One AI persona serves web chat, SMS, and voice. The persona is rebuilt server-side on every turn from a single profile (business facts, hours, escalation config), so every channel answers with the same brain and the same rules. ## Emergency vs non-emergency: it is a COMPOSITE, not a boolean
Word-for-word excerpt, not a result. Read the full SKILL.md ↓
Files of Rymac call funnel
SKILL.md
Show the full text79 lines
RyMac Call Funnel
Wire a site to convert visitors into scheduled calls, with a human-ping path for emergencies. This is the architecture running live on RyMac's own CRM platform; the pattern works with any stack (a CRM with AI channels, or Vapi/Twilio + a calendar API wired directly).
The architecture (one persona, many channels)
One AI persona serves web chat, SMS, and voice. The persona is rebuilt server-side on every turn from a single profile (business facts, hours, escalation config), so every channel answers with the same brain and the same rules.
Emergency vs non-emergency: it is a COMPOSITE, not a boolean
Do not build a single if (emergency) classifier. The proven pattern is
four separable mechanisms, configured per business:
- Escalation keywords (the instant human ping). Case-insensitive keyword match on inbound messages ("urgent", "emergency", "complaint", "speak to manager", plus the niche's own panic words). On match: the AI GOES SILENT and the on-call human is notified immediately with a deep link to the contact. Allow per-channel keyword and notify-address overrides.
- Live transfer (the ring-a-human path). Phone-system dial forward (e.g. Twilio Dial) to the on-call number with a ring timeout (~18 seconds) and an automatic text-back to the caller if unanswered.
- Callback capture (the deferred queue). Voice calls run a structured extraction for "callback requested"; when true, a follow-up task lands on the operator's today list plus a notification email. Pure-info calls create nothing.
- Booking tools (the non-emergency default). The agent gets get-availability / book / reschedule / cancel tools against ONE shared calendar-aware booking engine, so chat, voice, and the public booking page all see the same availability truth and send the same confirmation, invite, and reminders. Never let the model invent slots; hard-rule the booking protocol to real availability.
After-hours (where the money leaks)
Configure explicitly: business hours, after-hours behavior (AI handles and books vs capture-and-morning-queue), and when the AI hands off. For emergency-natured niches, after-hours emergency keywords route to the live on-call ping (mechanisms 1-2); everything else books the morning slot (mechanism 4). This is the beachhead pitch for any business losing overnight leads: the morning-missed-leads pile becomes booked calls.
Build order for a new site
- Define the niche's emergency vocabulary + the on-call contact
- Stand up the calendar (who takes the calls, when)
- Wire chat widget → persona → booking tools
- Add voice number → same persona → same tools
- Configure escalation keywords + notify address (+ live transfer if the business runs a real on-call)
- Set after-hours behavior explicitly
- Test all four paths: panic keyword pings, transfer rings + text-back fires, callback request creates the task, normal chat books a real slot and the confirmation lands
Rules
- AI silence on escalation is a feature: after the ping, the human owns the thread. The bot resuming over a live human is the cardinal sin.
- One booking engine, one availability truth. Two calendars = double bookings = dead client.
- Disclose honestly: the assistant speaks as the business's intake assistant, never impersonates a specific human.
- Every mechanism must degrade safely: failed webhook still captures the lead, unanswered transfer still texts back, failed booking still takes a callback.
| 1 | |
| 2 | name rymac-call-funnel |
| 3 | description Builds the conversion plumbing that turns site traffic into scheduled calls: chat scheduler, AI voice agent, emergency escalation that pings a live on-call human, non-emergency booking into one shared calendar engine, and after-hours handling. Use when the user asks to "wire up the call funnel", "add the chat scheduler", "set up the voice agent", "convert traffic into scheduled calls", "handle after-hours calls", or builds any page whose goal is booked calls. Make sure to use this skill whenever call-booking, voice-agent, or emergency-routing plumbing is being designed or built. |
| 4 | argument-hint [site/business to wire, calendar target, on-call contact] |
| 5 | |
| 6 | |
| 7 | # RyMac Call Funnel |
| 8 | |
| 9 | Wire a site to convert visitors into scheduled calls, with a human-ping |
| 10 | path for emergencies. This is the architecture running live on RyMac's own |
| 11 | CRM platform; the pattern works with any stack (a CRM with AI channels, or |
| 12 | Vapi/Twilio + a calendar API wired directly). |
| 13 | |
| 14 | ## The architecture (one persona, many channels) |
| 15 | |
| 16 | One AI persona serves web chat, SMS, and voice. The persona is rebuilt |
| 17 | server-side on every turn from a single profile (business facts, hours, |
| 18 | escalation config), so every channel answers with the same brain and the |
| 19 | same rules. |
| 20 | |
| 21 | ## Emergency vs non-emergency: it is a COMPOSITE, not a boolean |
| 22 | |
| 23 | Do not build a single `if (emergency)` classifier. The proven pattern is |
| 24 | four separable mechanisms, configured per business: |
| 25 | |
| 26 | **Escalation keywords (the instant human ping).** Case-insensitive |
| 27 | keyword match on inbound messages ("urgent", "emergency", "complaint", |
| 28 | "speak to manager", plus the niche's own panic words). On match: the AI |
| 29 | GOES SILENT and the on-call human is notified immediately with a deep |
| 30 | link to the contact. Allow per-channel keyword and notify-address |
| 31 | overrides. |
| 32 | **Live transfer (the ring-a-human path).** Phone-system dial forward |
| 33 | (e.g. Twilio Dial) to the on-call number with a ring timeout (~18 |
| 34 | seconds) and an automatic text-back to the caller if unanswered. |
| 35 | **Callback capture (the deferred queue).** Voice calls run a structured |
| 36 | extraction for "callback requested"; when true, a follow-up task lands |
| 37 | on the operator's today list plus a notification email. Pure-info calls |
| 38 | create nothing. |
| 39 | **Booking tools (the non-emergency default).** The agent gets |
| 40 | get-availability / book / reschedule / cancel tools against ONE shared |
| 41 | calendar-aware booking engine, so chat, voice, and the public booking |
| 42 | page all see the same availability truth and send the same confirmation, |
| 43 | invite, and reminders. Never let the model invent slots; hard-rule the |
| 44 | booking protocol to real availability. |
| 45 | |
| 46 | ## After-hours (where the money leaks) |
| 47 | |
| 48 | Configure explicitly: business hours, after-hours behavior (AI handles and |
| 49 | books vs capture-and-morning-queue), and when the AI hands off. For |
| 50 | emergency-natured niches, after-hours emergency keywords route to the live |
| 51 | on-call ping (mechanisms 1-2); everything else books the morning slot |
| 52 | (mechanism 4). This is the beachhead pitch for any business losing |
| 53 | overnight leads: the morning-missed-leads pile becomes booked calls. |
| 54 | |
| 55 | ## Build order for a new site |
| 56 | |
| 57 | [ ] Define the niche's emergency vocabulary + the on-call contact |
| 58 | [ ] Stand up the calendar (who takes the calls, when) |
| 59 | [ ] Wire chat widget → persona → booking tools |
| 60 | [ ] Add voice number → same persona → same tools |
| 61 | [ ] Configure escalation keywords + notify address (+ live transfer if |
| 62 | the business runs a real on-call) |
| 63 | [ ] Set after-hours behavior explicitly |
| 64 | [ ] Test all four paths: panic keyword pings, transfer rings + text-back |
| 65 | fires, callback request creates the task, normal chat books a real |
| 66 | slot and the confirmation lands |
| 67 | |
| 68 | ## Rules |
| 69 | |
| 70 | AI silence on escalation is a feature: after the ping, the human owns |
| 71 | the thread. The bot resuming over a live human is the cardinal sin. |
| 72 | One booking engine, one availability truth. Two calendars = double |
| 73 | bookings = dead client. |
| 74 | Disclose honestly: the assistant speaks as the business's intake |
| 75 | assistant, never impersonates a specific human. |
| 76 | Every mechanism must degrade safely: failed webhook still captures the |
| 77 | lead, unanswered transfer still texts back, failed booking still takes |
| 78 | a callback. |
| 79 |
Discussion
Alternatives
Advisor orchestrator workerUse when a task is too large for one model pass, needs parallel research or generation across many subtasks (like researching a dozen competitors at once), or the user asks to orchestrate multiple models, split work across a model team, run an advisor-worker loop, have a stronger model review the plan while cheap workers execute, or says "too big for one model" or "fan this out". Not for single-file edits or tasks one model handles in one pass.CCS Align — Worker Watch seat (Phases 0–2 shipped; Phase 3 = verify / sign-off)Run the CCS Align seat's hourly breathing cycle — prove the local claude-mem worker is healthy, pull needle observations through search → timeline → get_observations, land them in a seat-owned middle cache via atomic grab → append → filter exclude-marks → replace, manage exclude marks, and walk house → project → seat rules to detect conflicts (SHADOW_HOUSE, DENY_ALLOW, DRIFT, CLOCK_HEADER) with an append-only rules-report.md. Use when asked to run CCS Align, breathe the alignment seat, refresh the middle cache, exclude or restore an observation, walk rules, check rules conflicts, or check the Worker Watch board.Catchup — Async-Team Return BriefingSummarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
Async python patternsMaster Python asyncio, concurrent programming, and async/await patterns for high-performance applications. Use when building async APIs, concurrent systems, or I/O-bound applications requiring non-blocking operations.
Async python patternsMaster Python asyncio, concurrent programming, and async/await patterns for high-performance applications. Use when building async APIs, concurrent systems, or I/O-bound applications requiring non-blocking operations.Browse more free Claude skills or everything in Development.