מתנה בקניון

מסמך דרישות מוצר חי · גרסה 0.1.0

מערכת אחת שמחברת
קבלה, החלטה ומתנה.

PRD זה מגדיר את הבעיה, המשתמשים, הדרישות, כללי העסק והגבולות של פלטפורמת קמפייני המתנות לקניונים. הוא מתאר את המוצר כפי שהוא פועל היום — ומסמן בכנות מה עדיין לא הושלם.

01

תקציר מנהלים

למה המוצר קיים

הבעיה

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

חזון

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

עקרון מוצר

האוטומציה מציעה ומסננת; אדם מורשה מקבל את ההחלטה הסופית. ספק מתנות לעולם אינו נקרא לפני commit.

01לקצר את ההרשמה

OCR, חיפוש לקוח וזרימה מותאמת לנייד ולעמדה.

02להגן על הקמפיין

כפילויות, סף ומכסה נאכפים בגבול אטומי.

03לשמור על אחריות

החלטות רגישות מקושרות לשחקן האמיתי ב-audit.

04לגדול בבטחה

כל מידע תפעולי תחום לקניון אחד, גם על תשתית משותפת.

02

מסע הליבה

מתמונה לזכאות — בלי קיצורי דרך

שלב 1

זהות

צוות נכנס בחשבון אישי; לקוח מאמת טלפון ב-SMS.

שלב 2

קליטה

מעלים 1–10 קבלות, מתקנים OCR ובוחרים חנות.

שלב 3

בדיקות

השרת בודק סף, יום עסקי, כפילויות ומכסה.

שלב 4

הכרעה

סוקר מאשר או דוחה כל קבלה, עם נימוק מלא.

שלב 5

זכאות

נוצר שריון מתנה רק אם הסכום המאושר עומד בכללים.

שני ערוצי כניסה, אותו גבול החלטה. הרשמה מ־/station והרשמה מ־/customer מגיעות לאותו סטטוס manual_review ולאותו תור בדיקה.

03

קהלי יעד והרשאות

כל משתמש רואה רק את מרחב העבודה שלו

לקוח/ה

customer

אימות SMS, העלאת קבלות, מעקב אחר סטטוס ושמירת פרופיל אופציונלי — ללא חשבון צוות.

עמדת שירות

attendant

חיפוש לקוח, אימות טלפון וקליטת הרשמה. אין סמכות לאשר או לדחות קבלה.

סוקר/ת

reviewer

בדיקה והכרעה ברמת קבלה, כולל דחייה מנומקת וביטול החלטה בתנאים המותרים.

ניהול קניון וארגון

mall / organization admin

תפעול קמפיין, צוות, חנויות, דוחות ותור בדיקות בגבולות הקניונים שהוקצו.

מנהל/ת מערכת

platform_admin

ניהול גלובלי של המבנה, המשתמשים והקמפיינים, לצד כלי תמיכה, audit ו-Sandbox.

מנהל מערכתארגוןקניוןעמדות וחנויותקמפיין והרשמות
04

דרישות פונקציונליות

החוזה המוצרי

IDENTITY

זהות וגישה

  • צוות נכנס בחשבון אישי; הרשאה נגזרת מפרופיל ומתפקיד בקניון, ולא מ-metadata של המשתמש.
  • בקשת משתמש צוות אינה מעניקה גישה לפני אימות אימייל ואישור מנהל מערכת.
  • לקוח מזדהה בקוד SMS בן ארבע ספרות ומקבל capability חתומה וקצרת-חיים, ללא Supabase Auth session.
  • כל פעולה מוגנת בודקת גם תפקיד וגם tenant; בחירת קניון בממשק אינה מעניקה הרשאה.
RECEIPTS

קבלות ו-OCR

  • הרשמה כוללת 1–10 קבלות, ולכל קבלה נדרשת תמונת JPG, PNG או WebP תקינה עד 10MB.
  • OCR מציע חנות, מספר, תאריך, סכום, מטבע וסימני אזהרה; המשתמש נשאר אחראי לאימות ולתיקון.
  • העתק, אי-התאמת תאריך או חשבונית עסקה מוצגים כאזהרה ואינם חוסמים שליחה לבדיקה.
  • חנות שאינה ברשימה ניתנת להזנה כחריגה גלויה, ללא שיוך שקט לחנות אחרת.
ELIGIBILITY

הרשמה וזכאות

  • השרת קובע יום עסקי לפי אזור הזמן ושומר כסף ביחידות הקטנות של המטבע בלבד.
  • סף, חנויות, כפילויות, מכסת קמפיין ו-idempotency נאכפים לפני יצירת זכאות.
  • כל הרשמה חיה נוצרת ב-manual_review; אין מסלול שמדלג על החלטה אנושית.
  • זכאות למתנה נוצרת רק בהחלטה סופית מזכה, במסגרת פעולה אטומית שמעדכנת גם את המכסה.
REVIEW

בדיקה ידנית

  • סוקר רואה תמונת קבלה בקישור חתום וקצר-חיים ומחליט לכל קבלה בנפרד או לכל הממתינות יחד.
  • דחייה דורשת סיבה; כל עוד נותרה קבלה pending, ההרשמה נשארת בתור.
  • אישור חלקי מעניק מתנה רק אם סכום הקבלות שאושרו לבדו עדיין עומד בסף.
  • אפשר לבטל החלטה כל עוד לא הונפק שובר בפועל; שריון בלבד נמחק והמכסה מוחזרת.
MANAGEMENT

ניהול ותפעול

  • מנהל רואה תמונת מצב, הרשמות, בדיקות, זכאויות, חנויות, צוות, דוחות וקמפיינים לפי קניון.
  • מנהל מערכת מנהל ארגונים, קניונים, עמדות, שעות פעילות, חנויות, משתמשים וסוגי הטבה.
  • יצוא XLSX, החלטות בדיקה ושינויים רגישים נרשמים ביומן ביקורת עם השחקן האמיתי.
  • כלי תמיכה כוללים צפייה בתור משתמש ל-30 דקות, Sandbox לתמונות יתומות ויומן שגיאות מחוטא.
EXPERIENCE

חוויית שימוש

  • כל המסכים בעברית וב-RTL, מותאמים לנייד ולעמדת שירות, עם ניווט מקלדת ומצבי focus גלויים.
  • אין לבקש GPS אוטומטית; המיקום משמש להצעה בלבד ואינו נשמר.
  • שגיאות מנוסחות כפעולה שניתן לבצע, בלי לחשוף אם טלפון או משתמש קיימים.
  • המערכת מציגה בבירור אם יכולת פעילה, חלקית, במצב הדגמה או ממתינה לספק חיצוני.
05

כללים ומכונות מצבים

מה נחשב החלטה סופית

כללי יסוד

  • טלפון מנורמל לפני hashing והשוואה.
  • קבלה אינה ניתנת לשימוש חוזר בקמפיין.
  • סכום זכאי מחושב רק מקבלות שאושרו.
  • קבלה עם תאריך שונה או חנות חריגה עוברת לבדיקה — לא נדחית אוטומטית.
  • שעות עמדה נאכפות לפי היום, השעה ואזור הזמן; משמרת יכולה לחצות חצות.
  • סטטוס חלקי חוסם הרשמה יומית נוספת כאשר ניתנה זכאות.

מצבי הרשמה

ממתיןmanual_review

כל הקבלות טרם הוכרעו

סופיaccepted

כל הקבלות אושרו

סופיpartially_accepted

שילוב של קבלות מאושרות ונדחות

סופיrejected

לא אושרה אף קבלה

06

אבטחה, פרטיות וארכיטקטורה

ההרשאה אינה נשענת על המסך

דפדפן RTLNext.js + ZodDomain rulesSupabase RLS + RPCספקים חיצוניים

PII וסודות

מידע אישי מוצפן; טלפונים מושווים ב-HMAC. סודות נשארים בצד שרת ואינם נכנסים ל־NEXT_PUBLIC_, למסמכים או ללוגים.

בידוד קניונים

כל שורה תפעולית נושאת tenant_id. השרת בודק membership ומסד הנתונים מוסיף RLS או פונקציה מאובטחת.

שחקן אמיתי

במצב “צפייה בתור” הממשק משתנה, אך הפעולה ממשיכה להירשם על מנהל המערכת האמיתי ואינה מזייפת JWT.

שמירת תמונות

הקבצים פרטיים, מוצגים בקישור חתום לחמש דקות ונמחקים בסיום ההחלטה; תמונות יתומות ניתנות לאבחון ולמחיקה.

נתיבי המוצר

ציבורי

/customer/login/register/guide/tech-stack/prd

צוות

/welcome/station/manager/account

מנהל מערכת

/admin/users/admin/sandbox/admin/error-log

07

מצב המימוש

מה פעיל, ומה עדיין דורש עבודה

פעיל

ליבת המוצר

  • שני ערוצי הרשמה: עמדה ושירות עצמי
  • OTP לקוחות וצוות, חיפוש לקוח ושער אימות בעמדה
  • OCR חי עם תיקון ידני ואזהרות מסמך
  • תור בדיקה משותף והכרעה ברמת קבלה
  • מניעת כפילויות, ניהול מכסה וזכאות אטומית
  • ניהול multi-tenant, משתמשים, חנויות וקמפיינים
  • דוחות, XLSX, audit, Sandbox ויומן שגיאות
חלקי / עתידי

גבולות ידועים

  • אין עדיין הנפקת שובר חיה דרך BuyMe או ספק מתנות אחר.
  • עורך מלא ל-JSON של חוקי הקמפיין ואכיפתם בקוד עדיין חסרים.
  • הוכחת OTP של העמדה נאכפת כיום בממשק, אך לא נישאת עדיין בחוזה ה-API.
  • ניקוי אוטומטי מתוזמן לתמונות OCR יתומות טרם הופעל.
  • הגרלות, קופוני דייר ומלאי מתנות פיזיות הם הרחבות עתידיות.
גבול מסחרי מחייב

המערכת יוצרת כיום gift entitlement שמור, אך אינה מנפיקה קופון חי. חיבור ספק יתחיל רק לאחר חוזה sandbox מאושר הכולל idempotency, שגיאות, retry, reconciliation וסטטוסים.

08

מדידה והמשך הדרך

איך נדע שהמוצר מצליח

זמן

משך חציוני מאימות טלפון ועד שליחת הרשמה.

איכות

שיעור קבלות שבהן הצעת OCR התקבלה ללא תיקון.

בקרה

זמן חציוני בתור ושיעור הכרעות עם נימוק מלא.

אמינות

כפילויות שנחסמו, חריגות מכסה ואירועי cross-tenant — היעד האחרון הוא אפס.

  1. עכשיו

    הקשחת הליבה

    אכיפת הוכחת OTP בעמדת השירות, ניקוי אוטומטי, בדיקות E2E ועומס.

  2. הבא

    חוקי קמפיין מלאים

    עורך rules, versioning ברור, ולידציה וניתוח דוחות תפעולי.

  3. לאחר חוזה

    הנפקת מתנות חיה

    Adapter לספק, retry, reconciliation, webhook ומסכי תפעול כשל.

  4. הרחבה

    מוצרי קמפיין נוספים

    הגרלות, קופוני דייר ומתנות פיזיות — כל אחד כמודול נפרד.

החלטות מוצר פתוחות

ספק המתנות וה-SLA שלו; מדיניות retention מחייבת; כללי קמפיין מעבר לסף בסיסי; התנהגות לקוח בכשל SMS; והגדרת תהליך rollback במקרה של כשל אחרי הנפקה.