Voice Center — אפיון מלא

2. מה גילינו על AgenTeam

חקרתי את ה-bundles של הדשבורד שלהם (הורדה ישירה מ-Vercel). הסטאק שלהם חשוף בקוד.

1.1 הסטאק הקולי — OpenAI לבד

1.2 אין שום זרימת URL → סקרייפ → סוכן

Dashboard · AdminDashboard · AgentManagement · AgentDetail · AgentRunner
RealtimeCall · CheckVoiceBot · CheckChatbot · PhoneNumbers · BillingPage
BillingHistory · Settings* · Resources · ApiDocs · VerifyEmailPage

1.3 ה-API שלהם — Plain CRUD

GET    /companies
POST   /agents              ← אתה שולח system_prompt
PATCH  /agents/:id
POST   /agents/:id/leads
PATCH  /agents/:id/leads/:id

אין POST /agents/from-url, אין /scrape, אין /generate. הכל manual flow.

1.5 מיפוי ה-Routes של AgenTeam (לבחינה)

3. הקונספט

ארבעת המוצרים — מהפשוט לעמוק

מה המערכת באמת עושה (מאחורי הקלעים)

• זיהוי — מי המתקשר? במאגר? לקוח חוזר? עם היסטוריה?
• הקשר — מה הוא קנה? מה הוא ביקש קודם? מה מצב הפגישה?
• החלטה — על בסיס system_prompt + ההקשר → מה להגיד עכשיו
• פעולה — לא רק לדבר: function calling (book_appointment, send_sms, escalate_to_human, query_inventory)
• תיעוד — כל מילה, כל פעולה, כל תוצאה → DB → CRM webhook
• המשך — 24h לפני פגישה → תזכורת. לא ענה → SMS. עדיין לא → outbound call.

4. זרימת Onboarding: URL/PDF → סוכן חי

זרימת ההצטרפות הסטנדרטית של המוצר. הלקוח מביא URL של האתר שלו (או PDF/Word), המערכת סורקת, מחלצת מידע, ובונה את ה-system_prompt אוטומטית. בלי זה אין self-serve.

5. Scrape Cascade — איך סורקים URL

הקסקדה מטפלת ב-3 רמות של "קושי" באתרים. כל שלב מנסה — אם נכשל (timeout / block / חסר תוכן) → עובר לבא בתור.

4.1 לוגיקת ה-cascade (פסאודו)

async def scrape_with_cascade(url, max_pages=15):
    # Stage 1: Firecrawl (fast, hosted, ~$0.001/page)
    try:
        result = await firecrawl.crawl(url, limit=max_pages, formats=["markdown","html"])
        if validate(result, min_chars=500):
            return {"source": "firecrawl", "pages": result}
    except Exception: pass

    # Stage 2: CloakBrowser (anti-bot, local)
    try:
        pages = await cloakbrowser_crawl(url, max_pages)
        if validate(pages, min_chars=500):
            return {"source": "cloakbrowser", "pages": pages}
    except Exception: pass

    # Stage 3: Playwright (last resort)
    pages = await playwright_crawl(url, max_pages)
    return {"source": "playwright", "pages": pages}

4.2 בחירת הדפים החשובים (לא "כל האתר")

10-15 דפים זה התקרה. לוגיקת priority:

1. Always: /, /about, /contact
2. Pricing/Services: /pricing, /services, /products
3. FAQ: /faq, /help
4. Footer links שאינם משפטיים
5. Top items בתפריט ראשי
6. דיסקרימינטור: מקסימום 15 דפים, מעדיפים דפים עם >500 chars טקסט

מה לא סורקים: /privacy, /terms, /accessibility, blog posts (אלא אם כן יש <10 דפים בסה"כ).

4.3 מקור חלופי: PDF / Word / Text

4.4 ולידציה

4.5 עלויות משוערות

בעלות אונבורדינג של פחות מ-7 אגורות לסקרייפ ובחירה של $0 חבילת trial, ROI הצדדי מוצדק בקלות.

6. Prompt Generator — איך מייצרים system_prompt (ללא RAG)

5.1 בחירת המודלים — מאי 2026

5.2 התהליך המלא

5.3 מבנה ה-system_prompt שיווצר

[PERSONA]
שמך {agent_name}. אתה {role} של {business_name}.
אתה מדבר {language} בטון {tone}. אנושי, סבלני, קצר בתשובות.

[BUSINESS CONTEXT]
{business_name} הוא {one_line_description}.
- כתובת: {address}
- שעות פעילות: {hours}
- טלפון נציג אנושי לחירום: {fallback_phone}

[SERVICES / PRODUCTS]
{extracted_services_bullets}

[FAQ]
{extracted_faqs}

[PLAYBOOK: messaging|secretary|sales]
{playbook_template_content}

[GUARDRAILS]
- אל תמציא מחירים שלא מצוינים → "אני אתאם נציג שיחזור אליך".
- אל תיתן ייעוץ משפטי/רפואי בשם העסק.
- אם לא ברור — escalate_to_human().

[TOOLS] (משתנים פר-מוצר)
messaging: take_message, send_sms_summary
secretary: book_appointment, send_sms, escalate, take_message
sales:     send_sms, escalate, send_brochure

[CLOSING]
תמיד סיים בסיכום ברור.

5.4 עלות אונבורדינג פר-לקוח (אומדן)

עלות חד פעמית פר onboarding. זניחה.

7. Voice Stack — Pipecat + xAI Grok (קיים)

6.1 איך זה עובד היום (voice-agent-grok)

6.2 מה צריך להוסיף כדי שזה יעבוד multi-tenant

1. Tenant resolver בכל webhook — לזהות איזה tenant לפי המספר שמתקשרים אליו.
2. Per-tenant config loader — system_prompt + voice + tools + business_hours מ-DB.
3. Tool registry — כל tenant יכול להפעיל/לבטל כלים (book_appointment, send_sms, ...).
4. Call recording ל-S3/R2 פר tenant (עם הסכמה ברורה לחוק הפרטיות).
5. Transcript pipeline — אחרי שיחה: שמירה ב-DB + webhook ל-CRM של הלקוח.

6.3 קולות זמינים (כבר נבדקו)

* HD mode זמין דרך preset xai_realtime_hd ב-output_rate=48kHz.

6.4 עברית — מה צריך לדעת

6.5 התאמות נדרשות ל-voice-agent-grok

app/
├── agent.py                 # ←  הוסף tenant_id param
├── main.py                  # ←  webhook resolves tenant from number
├── prompts.py               # ←  load from DB instead of hardcoded
├── voices.py                # ←  unchanged
├── config.py                # ←  add TenantConfig dataclass
├── tenants/                 # ←  NEW
│   ├── resolver.py          # phone → tenant_id
│   └── config_loader.py     # DB query
├── tools/                   # ←  NEW
│   ├── book_appointment.py
│   ├── send_sms.py
│   └── escalate.py
├── call_logger.py           # ←  add S3 upload per-tenant
└── rag/                     # ←  REMOVE / disable (no RAG)

8. ארכיטקטורה כוללת

7.1 פירוט שירותים

7.2 hosting מומלץ

9. מודל נתונים

Tenant
├── id, name, business_name, created_at
├── owner_user_id
├── subscription (plan, status, tranzila_token, next_charge_at)
├── usage_meters (minutes_used, sms_sent, current_month)
└── settings (timezone, language, business_hours_json)

User (גישה למחשב, יכול לנהל את ה-Tenant)
├── id, tenant_id, email, name, role (owner|admin|viewer)
└── auth (google_oauth | email_pw, password_hash)

Source (חומר גלם להפקת ה-prompt)
├── id, tenant_id, type (url|pdf|docx|text), url_or_filename
├── scrape_status, scrape_method (firecrawl|cloakbrowser|playwright)
├── raw_markdown[]   ← 15 דפים שנשמרו ב-R2
└── extracted_json   ← {business_name, services[], hours, ...}

Agent
├── id, tenant_id, name, persona_id, playbook_id (secretary|messaging|sales)
├── system_prompt (text - generated)
├── voice (Ara|Eve|Sal|Leo|Rex)
├── language (he|en)
├── voice_speed (0.5-1.5)
├── tools_enabled[] (book_appointment, send_sms, escalate, ...)
├── business_hours_json
└── source_id  ← reference to Source

PhoneNumber
├── id, tenant_id, twilio_sid, phone_e164
├── linked_agent_id, country, monthly_cost
└── status (active|suspended)

Contact (CRM-like - האנשים שמתקשרים אליך)
├── id, tenant_id, phone_e164, name, email, tags[]
└── first_seen_at, last_seen_at

Conversation (thread יחיד לאיש קשר, חוצה ערוצים)
├── id, tenant_id, contact_id, agent_id
├── started_at, last_activity_at, status
└── summary (auto-generated after each event)

Call
├── id, conversation_id, twilio_call_sid
├── direction (inbound|outbound), duration_sec
├── recording_url     ← Supabase Storage (mp3/wav)
├── transcript_url    ← Supabase Storage (JSON timestamped)
├── transcript_text   ← short flat text for search/index
├── outcome (appointment_booked|escalated|hung_up|...)
├── extracted_fields_json (name, intent, contact info from call)
└── tools_used[] (which functions the agent called)

Message (SMS / WhatsApp)
├── id, conversation_id, channel (sms|whatsapp)
├── direction, body, sent_at, delivered_at, status
└── twilio_message_sid

Event (פגישה / משימה / תזכורת)
├── id, conversation_id, contact_id
├── type (appointment|callback|reminder)
├── scheduled_at, status, calendar_event_id (Google)
└── created_by_call_id

Campaign (outbound — קמפיין שיחות יוצאות)
├── id, tenant_id, name, agent_id
├── target_contacts[] (CSV upload)
├── schedule (cron expression), status
└── stats (calls_made, connected, converted)

Integration
├── id, tenant_id, type (hubspot|monday|salesforce|generic_webhook)
├── credentials_encrypted, webhook_url
└── events_subscribed[] (call_ended|appointment_booked|...)

ApiKey
├── id, tenant_id, name, key_hash (prefix only stored)
├── created_at, last_used_at, revoked_at
└── scopes[]

8.1 הקלטות, תמלולים, ודשבורד

8.2 הבדל קונספטואלי מ-AgenTeam

10. Tranzila — תשלום ומסחר (דרך API, לא iFrame)

10.1 זרימת רכישה (API-first)

10.2 ניהול מנויים — Tranzila לבד מספיק לחלוטין

10.3 חיוב חוזר חודשי

Cron daily @ 02:00 UTC
  ├─ SELECT tenants WHERE next_charge_at <= NOW() AND status = active
  ├─ FOR EACH tenant:
  │    ├─ POST Tranzila API with TOKEF + plan_price
  │    ├─ IF success → next_charge_at += 30 days, reset usage_meters
  │    └─ IF fail   → status = past_due, send email, retry @ +1, +3, +7 days
  └─ IF still failing after 7 days → suspend tenant (disable Twilio webhook)

10.4 חיוב Overage (תוספת דקות / הודעות)

בסוף החודש, אם הלקוח חרג ממכסת הדקות או הודעות:

• חישוב: extra_minutes × ₪X + extra_sms × ₪Y
• חיוב נפרד דרך Tranzila עם אותו TOKEF

חשבונית דיגיטלית — לא דרך Tranzila. מבוצע דרך Finbot (אינטגרציה נפרדת, מחוץ ל-scope של הטאב הזה).

10.5 אז מה לגבי Clerk?

10.6 PaymentProvider abstraction (לעתיד)

אם בעתיד נרצה Stripe ללקוחות בינלאומיים — נעצב מ-day 1 שכבת PaymentProvider מופשטת:

interface PaymentProvider {
  charge(token, amount): { success, transaction_id }
  createToken(card_data): { token }
  refund(transaction_id, amount?): { success }
}

class TranzilaProvider implements PaymentProvider { ... }
class StripeProvider implements PaymentProvider { ... }  // future

11. מבנה האתר השיווקי

10.1 דפי ליבה

10.2 דשבורד הלקוח

10.3 דף בית — סקציות מומלצות

1. Hero — H1 ("השלוחה הדיגיטלית שלא תפסיק לעבוד") + Lost Revenue Calculator interactive
2. 3 מוצרים — מזכירה / הודעות / מכירות
3. "דבר עם הסוכן עכשיו" — WebRTC button → demo session
4. How it works (URL→Agent) — אנימציה 4 שלבים
5. פלייבוקים לפי תעשייה — 6 כרטיסים גדולים עם דוגמאות
6. Social proof — לוגואים + ציטוטים + 3 הקלטות אמיתיות
7. Pricing teaser — 3 חבילות + Trial
8. FAQ — 10+ שאלות, לא 3 כמו AgenTeam
9. CTA סופי — "התחל ב-15 דקות"

12. אסטרטגיית תמחור

* כל החבילות ממוקדות SOHO / SMB / SME. אין יעד-לקוח Enterprise בשלב הזה.

11.1 ההיגיון מול AgenTeam

11.2 חיוב Overage

• דקות נוספות: ₪2 לדקה (פחות מ-₪3.3 שלהם)
• SMS נוסף: ₪0.20 (עברית UCS-2)
• WhatsApp נוסף: ₪0.10
• מספר נוסף: ₪29/חודש

11.3 הנחות

• שנתי → 20% הנחה (חודשיים חינם)
• סוכנויות → 30% הנחה ב-Scale ומעלה, white-label אופציונלי
• הפניות → חודש חינם פר הפניה מוצלחת

11.4 עלויות תשתית פר לקוח (אומדן גס + מה זה עולה ללקוח)

* האומדנים צריכים אימות מול מחירונים עדכניים. תשואה גולמית סבירה אחרי עלויות תשתית — לפני שיווק, פיתוח, ותמיכה.

13. מסלול בנייה — לפי 3 רולים במקביל

חוזי API משותפים (כל הצוותים מסכימים מראש)

🅰️ Track A — Backend + Payments + Onboarding (איש אחד)

🅱️ Track B — Voice Agent (1-2 אנשים)

🅲 Track C — UI/UX (איש אחד)

סדר תלויות (מי מחכה למי)

14. שאלות פתוחות + החלטות שנסגרו

✅ נסגרו

⚠️ שאלות פתוחות רציניות

15. Latency & Redis — הסבר בגובה העיניים

למה Latency נמוך זה קריטי בשיחה קולית?

הסתכלות High-Level על הארכיטקטורה

Redis ו-Postgres — האנלוגיה של המשרד

תרחיש: מה קורה כשמישהו מתקשר

3 השימושים של Redis אצלנו

איפה מתארחים

האם חיוני מיום-1?

RAG ו-Redis — איך זה משתלב?

3 כלים, 3 מטרות שונות

ה-Vector DB יכול להיות pgvector (תוסף של Postgres — הכי נפוץ ל-MVP), או שירות נפרד כמו Pinecone / Weaviate. Redis היא לא Vector DB (אם כי קיים Redis Stack שמשלב את שניהם).

איך RAG עובד בשיחה אמיתית (בלי Redis)

1. לקוח שואל "כמה עולה ערעור?"
        ↓
2. ה-LLM שולח את השאלה ל-Retriever
        ↓
3. Retriever מחשב embedding לשאלה (~300ms)
        ↓
4. מחפש ב-Vector DB chunks דומים (~100ms)
        ↓
5. מקבל top-5 פרקים רלוונטיים
        ↓
6. שולח ל-LLM: [שאלה + 5 פרקים] → תשובה
        ↓
7. הסוכן עונה

סה"כ ~400ms על שלבי RAG. בלי Redis — בכל שיחה.

4 דרכים לשלב Redis ב-RAG

הסטאק המומלץ עם הכל ביחד

┌──────────────────────────────────────────────┐
│  שאלה מהמתקשר                                │
│              ↓                                │
│  1. בדוק Redis ── יש תשובה מוכנה? ── יש → החזר│
│              ↓ אין                            │
│  2. embedding ── יש בקאש? ── יש → דלג         │
│              ↓ אין                            │
│  3. pgvector חיפוש → top-5 chunks             │
│              ↓                                │
│  4. שמור תוצאות ב-Redis (TTL שעה)             │
│              ↓                                │
│  5. שלח ל-Grok עם הקונטקסט                    │
│              ↓                                │
│  6. שמור תשובה סופית ב-Redis (TTL 5 דקות)     │
└──────────────────────────────────────────────┘

איזה דפוס מתי?

למה לא Cloudflare KV?

Upstash vs Railway — איפה לארח את Redis?

שני האפשרויות העיקריות. שניהם טובים. הנה ההשוואה אחרי בדיקה מעודכנת (מאי 2026):

ההמלצה הסופית

16. Twilio Concurrency — שיחות מקבילות, PBX, ו-SIP Trunk

1. שיחות נכנסות — האם מספר אחד מטפל ב-N שיחות במקביל?

מה כן יכול להגביל?

2. שיחות יוצאות — האם מספר אחד יכול לחייג 10 במקביל?

מה כן עלול לחורק?

• Caller ID זהה לכל הנמענים — 10 נמענים שונים יראו את אותו מספר. אם 3 מהם חוזרים בו-זמנית, זה inbound רגיל (לא בעיה). אבל אם מבחינה שיווקית רוצים שכל קמפיין יראה מספר שונה — צריך כמה מספרים.
• Anti-spam מצד carriers — בארה"ב יש "STIR/SHAKEN" שעלול לתייג מספר שמחייג להרבה אנשים כ-spam. בישראל פחות. עדיין: לפזר על 2-3 מספרים זה healthy לקמפיינים גדולים.
• Twilio account concurrency limit — אם החשבון מוגבל ל-100 ויש לך 80 נכנסות + 30 יוצאות → תהיה חסימה ב-10.

3. מתי צריך SIP Trunk?

SIP Trunk זה פרוטוקול שמחבר מערכות טלפוניה דרך IP. בהקשר שלנו, יש כמה תרחישים:

4. השורה התחתונה ל-Voice Center

5. תשובה לשאלות הספציפיות