אוריגמי גרסה 6.3.5: אוטומציית AI מתקדמת, Vision שבונה תהליכים, מערכת תשלומים ועוד

גרסה 6.3.5 היא גרסה של אוטומציה חכמה וכסף שנכנס. אוטומציית ה-AI קיבלה שדרוג עמוק עם בחירת מודל, Context מרשומות קשורות ותשובות מובנות. Vision כבר לא רק מבין תהליכי עבודה, הוא בונה ומעדכן אותם מ-Prompt. נוספה מערכת תשלומים מלאה עם קישורי תשלום וחיבור לספקי סליקה, אפליקציית זימון תורים, שדה KPI שמחשב נתונים מצטברים מרשומות מקושרות, וייצוא חשבוניות ישירות לחשבשבת. וכרגיל, גם עשרות שיפורים קטנים שנולדו מהשטח.

אוטומציית AI: בחירת מודל, Context מלא ותשובות מובנות

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

שלב אחר שלב

1. נכנסים להגדרת Workflow ומוסיפים את הפעולה AI Automation.
2. מזינים את ה-Prompt שמתאר מה רוצים שה-AI יבצע בInstruction.
3. בוחרים את ספק ה-AI וה-Model מתוך רשימת המודלים הזמינים במערכת (אלה שצורף עברם טוקן תקין בהעדפות המערכת).
4. בוחרים באפשרות לרמה מתקדמת במקום בסיסית.
5. מגדירים איזה מידע ייכלל ב-Context:
   • נתונים מהישות הנוכחית.
   • נתונים מישויות אחרות.
   • קבצים סטטיים שהוגדרו כקלט.
6. עבור מידע מישויות, ניתן להגדיר תנאי סינון על הרשומות שיישלחו ל-AI.
7. בוחרים את אופן קבלת התוצאה:
   • Simple – תשובת טקסט אחת.
   • Structured – מספר ערכים שממופים לשדות שונים ברשומה.
8. שומרים את הגדרת ה-Workflow.
9. כאשר ה-Workflow מופעל, המערכת אוספת את הנתונים שהוגדרו ומרכיבה מהם Context.
10. המערכת שולחת את ה-Prompt וה-Context למודל שנבחר, כולל קבצים במידת הצורך, באופן שאינו חושף אותם באופן ציבורי.
11. המערכת בודקת ומאמתת את תשובת ה-AI.
12. במצב Simple, התוצאה נשמרת בשדה שהוגדר כטקסט.
13. במצב Structured, הערכים שהוחזרו ממופים לשדות המתאימים וניתן להשתמש בהם בהמשך ה-Workflow.
14. במקרה של תשובה לא תקינה או שגיאה, המערכת מבצעת Validation ושומרת מידע מתאים ל-Logging/Audit לצורך איתור התקלה.

שימושים עיקריים

• ניתוח אוטומטי של רשומות באמצעות AI.
• שילוב מידע מהרשומה הנוכחית יחד עם מידע מרשומות קשורות.
• סיכום מידע עסקי ממספר מקורות.
• חילוץ מידע מובנה מתוך טקסט.
• סיווג או העשרת רשומות.
• הפקת מספר ערכים מתוך תשובת AI ושמירתם בשדות שונים.

למי מיועד

• Solution Builders – שבונים Workflows עסקיים ורוצים לשלב AI ללא פיתוח Custom Code.
• מנהלי CRM – שרוצים להעשיר ולנתח רשומות אוטומטית באמצעות מידע מהרשומה ומרשומות קשורות.
• צוותי Sales ו-Operations – יכולים להשתמש ב-AI לניתוח עסקאות, אנשי קשר, משימות ונתונים קשורים.
• צוותי שירות ותמיכה – יכולים לנתח Tickets והיסטוריית לקוח ולייצר מידע מובנה להמשך טיפול.
• מנהלי תהליכים ואוטומציות – יכולים להשתמש בתוצאות AI כקלט לפעולות Workflow נוספות.
• אנשי Implementation – יכולים להתאים את מודל ה-AI וה-Context לתרחישים עסקיים שונים במקום להיות מוגבלים למודל קשיח.

מה זה פותר / דוגמאות

• מודלים קשיחים ומתיישנים
  לפני: הפעולה הישנה השתמשה במודלים שהוגדרו מראש בקוד.
  אחרי: ניתן לבחור Provider ו-Model מתוך Registry, כך שניתן לעדכן ולהוסיף מודלים בלי לשנות את ה-Workflow עצמו.
• AI שמבוסס רק על הרשומה הנוכחית
  לדוגמה, בעת ניתוח Deal ניתן לשלוח ל-AI לא רק את פרטי העסקה אלא גם את ה-Contact, Tasks או Tickets הקשורים אליה.
• סיכום מידע ממספר מקורות
  לדוגמה: Workflow מקבל Deal, שולף את העסקה ואת רשומות הפעילות הקשורות אליה, ומבקש מה-AI להפיק סיכום של מצב העסקה והפעולות הבאות.
• עבודה עם קבצים פרטיים
  ניתן לצרף קובץ כחלק מה-Context שנשלח ל-AI בלי להפוך אותו לקובץ ציבורי רק לצורך העיבוד.
• תשובת AI שאינה שימושית לאוטומציה
  לפני: הפעולה הישנה כתבה בעיקר תשובה אחת לשדה יחיד.
  אחרי: במצב Structured ניתן לבקש מה-AI להחזיר מספר ערכים ולמפות כל אחד מהם לשדה אחר.
• לדוגמה – סיווג Ticket
  Workflow יכול לשלוח ל-AI את פרטי ה-Ticket, היסטוריית הפניות וקובץ מצורף. ה-AI יכול להחזיר מבנה כגון:
  • Priority
  • Category
  • Suggested Resolution, וכל ערך נשמר בשדה המתאים.

Vision בונה לכם את ה-Workflow: יצירה והגדרה מ-Prompt

עד היום Vision ידע להבין תהליכי עבודה קיימים. מהגרסה הזו הוא גם בונה אותם. מתארים בשפה טבעית מה התהליך צריך לעשות, ו-Vision מזהה את ה-Actions, השדות וההגדרות, מבקש אישור למיפוי שדות במקומות שצריך, ומוודא שכל Action מתאים ל-Trigger שמפעיל אותו.

שלב אחר שלב

1. המשתמש נכנס ל-Vision.
2. המשתמש מתאר באמצעות Prompt את ה-Workflow שהוא רוצה ליצור או לשנות.
3. המשתמש מציין את הפעולות, השדות והלוגיקה שה-Workflow צריך לכלול.
4. הVision מנתח את הבקשה ומזהה את ה-Actions, ה-Fields וההגדרות הנדרשות.
5. כאשר ה-Workflow דורש מיפוי של שדות, המשתמש מתבקש לאשר או להשלים את מיפוי השדות הרלוונטיים.
6. Vision יוצר ומגדיר את ה-Workflow בהתאם להנחיות שהתקבלו.
7. המערכת מוודאת שכל Action מתאים ל-Trigger שמפעיל את ה-Workflow, ומונעת הגדרות שאינן נתמכות.
8. המשתמש יכול לעבור על ה-Workflow שנוצר ולוודא שהפעולות, השדות והחיבורים הוגדרו בהתאם לדרישה.

שימושים עיקריים

• יצירת Workflows באמצעות הוראות בשפה טבעית במקום הגדרה ידנית של כל שלב.
• הגדרת Actions ו-Triggers באמצעות Genie AI.
• העתקה או המרה של רכיבי Workflow תוך שמירה על מיפוי נכון של שדות.
• יצירת Repeatable Groups כחלק מ-Workflow.
• הגדרת Workflows מורכבים הכוללים מספר Actions ושדות.
• מניעת הגדרות לא תקינות של Actions בהתאם לסוג ה-Trigger.
• סיוע למשתמשים שאינם מכירים לעומק את מבנה ה-Workflow וה-Actions הזמינים במערכת.

למי מיועד

• מנהלי מערכת – ליצירה והגדרה מהירה של Workflows ללא צורך להגדיר כל רכיב באופן ידני.
• מיישמים ואנשי Implementation – לבניית תהליכים אוטומטיים עבור לקוחות באמצעות Prompt.
• מפתחי אוטומציות – ליצירת Workflows מורכבים ולחיסכון בעבודה ידנית על הגדרות.
• משתמשים עסקיים – שרוצים לתאר את התהליך הרצוי בשפה טבעית ולקבל Workflow מתאים.

מה זה פותר / דוגמאות

• היכולת מאפשרת ל-Vision לא רק להבין Workflow קיים, אלא ליצור ולהגדיר Workflow חדש מתוך Prompt. בנוסף, היא מטפלת בבעיות שעלולות לגרום ל-Workflow שנוצר על ידי AI להיות לא תקין או לא ישים.
• דוגמה 1 – יצירת Workflow מתוך Prompt:
  המשתמש מבקש מVision ליצור Workflow שבכל פעם שרשומה חדשה נוצרת, המערכת תעתיק ערכים מסוימים לשדות אחרים ותבצע פעולה נוספת. Vision מזהה את ה-Actions הנדרשים ומגדיר את ה-Workflow.
• דוגמה 2 – מיפוי שדות:
  המשתמש מבקש להעתיק מידע משדה אחד לשדה אחר. Vision לא מניח את מיפוי השדות באופן אוטומטי כאשר נדרש אישור, אלא מבקש מהמשתמש לאשר איזה שדה מקור מתאים לאיזה שדה יעד.

Vision גם מעדכן: עריכת Workflows קיימים בשפה טבעית

הצעד הטבעי הבא. במקום ליצור Workflow חדש בכל פעם שמשהו משתנה, בוחרים תהליך קיים, מתארים את השינוי, ו-Vision מעדכן אותו במקום, תוך שמירה על שאר ההגדרות. הוספת Action, שינוי מיפוי שדות או שינוי התנאי שמפעיל את התהליך, הכל מ-Prompt אחד.

שלב אחר שלב

1. המשתמש נכנס ל-Vision.
2. המשתמש בוחר Workflow קיים שאותו הוא רוצה לשנות.
3. המשתמש מתאר באמצעות Prompt את השינוי שהוא רוצה לבצע ב-Workflow.
4. Vision מנתח את ה-Workflow הקיים ומזהה את הרכיבים שצריך לעדכן.
5. Vision מציע או מבצע את השינויים הנדרשים בהתאם להנחיה, תוך שמירה על שאר הגדרות ה-Workflow.
6. במידה שהשינוי דורש מיפוי של שדות או מידע נוסף, Vision מבקש מהמשתמש להשלים או לאשר את הפרטים הנדרשים.
7. המשתמש מאשר את השינויים.
8. המערכת מעדכנת את ה-Workflow הקיים בהתאם ל-Prompt, במקום ליצור Workflow חדש.
9. ניתן גם ליצור תהליכי עבודה יחד עם ישות חדשה.

שימושים עיקריים

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

למי מיועד

• מנהלי מערכת – לעדכון תהליכים קיימים במהירות, בלי לעבור ידנית על כל הגדרות ה-Workflow.
• אנשי Implementation – להתאמת Workflows קיימים לצרכים שונים של לקוחות.
• מפתחי אוטומציות – לביצוע שינויים מהירים בתהליכים קיימים.
• משתמשים עסקיים – שרוצים לתאר שינוי רצוי בשפה טבעית במקום להכיר את כל המבנה הטכני של Workflow.
• צוותי Operations – להתאמת תהליכים קיימים כאשר דרישות העבודה משתנות.
• צוותי תמיכה – לתיקון או התאמה של Workflows קיימים בהתאם לצורך שהתעורר במהלך העבודה.

מה זה פותר / דוגמאות

• היכולת מרחיבה את האפשרות של Vision מיצירת Workflows חדשים גם ל-עריכה ועדכון של Workflows קיימים. כך המשתמש לא צריך ליצור Workflow חדש בכל פעם שנדרש שינוי, ויכול לבצע התאמות ישירות באמצעות Prompt.
• דוגמה 1 – הוספת פעולה:
  המשתמש מבקש מ-Vision: “הוסף שליחת Email אחרי שהרשומה מתעדכנת.” Vision מזהה את ה-Workflow הקיים ומוסיף את ה-Action במקום המתאים.
• דוגמה 2 – שינוי Action קיים:
  המשתמש מבקש לשנות Action כך שבמקום לעדכן שדה אחד, הוא יעדכן שדה אחר. Vision מזהה את ה-Action הרלוונטי ומעדכן את ההגדרה שלו.
• דוגמה 3 – שינוי לוגיקה:
  המשתמש מבקש לשנות את התנאי שלפיו Workflow מופעל, למשל: “הפעל את התהליך רק כאשר הסטטוס משתנה ל-Approved.” Vision מעדכן את הלוגיקה הקיימת בהתאם.

מערכת תשלומים: קישורי תשלום וחיבור לספקי סליקה

אוריגמי גובה כסף. אפליקציית Payments החדשה מתחברת לספקי סליקה כמו Cardcom, Pelecard ו-Tranzila, מייצרת קישור תשלום מתוך Workflow, שולחת אותו ללקוח לעמוד תשלום ממותג שלא דורש התחברות למערכת, ומעדכנת את הרשומה אוטומטית ברגע שהתשלום עובר. עם אימות סכום ומטבע, מניעת חיוב כפול ו-Simulator לבדיקות לפני עלייה לאוויר.

שלב אחר שלב

עבור מנהל מערכת / מטמיע

1. יוצרים דף חדש מסוג אפליקציה.
2. נכנסים לאפליקציית Payments ומגדירים חיבור לאחד מספקי הסליקה הנתמכים, כגון Cardcom, Pelecard או Tranzila.
3. מגדירים את הגדרות החיבור הנדרשות עבור החשבון/הטרמינל.
4. ניתן להשתמש ב-Simulator לצורך בדיקות, או בחיבור Gateway אמיתי לצורך סליקה בפועל.
5. מגדירים Workflow שמייצר Payment Link עבור רשומה עסקית.
6. המערכת יוצרת קישור תשלום ושומרת אותו ברשומה הרלוונטית.
7. שולחים את הקישור ללקוח באמצעות הערוץ המתאים.
8. הלקוח פותח את הקישור ומגיע לעמוד תשלום ממותג של Origami.
9. הלקוח מזין את פרטי התשלום ומשלים את העסקה מול ספק הסליקה.
10. המערכת מאמתת את התשלום מול ה-Gateway ומוודאת שהסכום והמטבע תואמים לבקשת התשלום.
11. לאחר תשלום מוצלח, סטטוס התשלום מתעדכן והמערכת יכולה לעדכן שדות ברשומה המקורית באמצעות הגדרות On-paid.
12. מנהל המערכת יכול לעקוב אחר העסקאות וה-KPIs מתוך Dashboard התשלומים.
13. במקרה של ניסיון חוזר או שליחת callback כפולה, המערכת מזהה את האירוע ומונעת חיוב/עדכון כפול.

שימושים עיקריים

• יצירת Payment Links ושליחתם ללקוחות.
• קבלת תשלומים דרך ספקי סליקה חיצוניים.
• תמיכה במספר חיבורי Payment Gateway.
• מעקב אחר בקשות תשלום ועסקאות.
• עדכון אוטומטי של רשומת CRM לאחר תשלום.
• מניעת חיוב כפול במקרה של callback או ניסיון חוזר.
• אימות שהסכום והמטבע ששולמו תואמים לבקשת התשלום.
• שימוש ב-Simulator לצורך בדיקות לפני עבודה מול Gateway אמיתי.
• הצגת נתוני תשלומים ועסקאות ב-Dashboard.
• תמיכה בדפי תשלום ציבוריים שאינם דורשים מהלקוח להתחבר למערכת Origami.

למי מיועד

• עסקים שמקבלים תשלומים מלקוחות – יוצרים קישורי תשלום ושולחים אותם ללקוחות במקום לבצע גבייה ידנית.
• צוותי מכירות – יכולים לשלוח ללקוח קישור לתשלום ישירות מתוך תהליך המכירה.
• צוותי שירות ותפעול – יכולים לעקוב אחר סטטוסי תשלום ולעדכן את רשומת הלקוח בהתאם.
• מנהלי כספים / Billing – מקבלים תיעוד של בקשות ועסקאות ומעקב אחר תשלומים שהושלמו.
• Solution Builders – יכולים לבנות אוטומציות שמגיבות לתשלום, למשל עדכון סטטוס, שדה או נתון עסקי לאחר תשלום.

מה זה פותר / דוגמאות

• גבייה באמצעות קישור תשלום
  לדוגמה, נציג מכירות יוצר Payment Link עבור עסקה של 150 ₪ ושולח אותו ללקוח. הלקוח משלם דרך עמוד התשלום, והעסקה נרשמת במערכת.
• עדכון אוטומטי לאחר תשלום
  לאחר שהלקוח שילם, ניתן לעדכן אוטומטית את הרשומה המקורית, למשל לשנות Payment Status ל-Paid.
• מניעת חיוב כפול
  אם ספק הסליקה שולח את אותו אירוע יותר מפעם אחת, המערכת מזהה שהאירוע כבר טופל ולא מבצעת שוב את הפעולות על העסקה.
• הגנה מפני שינוי סכום
  אם מישהו מנסה לשנות את סכום התשלום במהלך תהליך התשלום, המערכת משווה את הסכום ששולם לסכום המקורי ומונעת קבלת תשלום שאינו תואם לבקשה.
• בדיקת חיבור לפני Production
  מנהל יכול להשתמש ב-Simulator כדי לבדוק את כל תהליך יצירת הקישור והתשלום לפני חיבור ל-Gateway אמיתי.
• עבודה עם ספקי סליקה שונים
  ניתן להגדיר חיבור לספקים שונים, כך שהמערכת אינה תלויה בספק סליקה יחיד.
• תשלום ללא התחברות ל-Origami
  הלקוח מקבל עמוד תשלום ציבורי ויכול להשלים את התשלום בלי צורך בחשבון או Session במערכת.
• דוגמה מלאה:
  חברת שירות שולחת ללקוח חשבון על סך 150 ₪. נציג יוצר Payment Link מתוך Origami ושולח אותו ללקוח. הלקוח פותח את הקישור, משלם באמצעות Cardcom, והמערכת מאמתת שהעסקה אכן בוצעה על סך 150 ₪. לאחר אישור התשלום, העסקה מסומנת כ-Paid, הרשומה המקורית מתעדכנת בהתאם להגדרות ה-On-paid, והעסקה מופיעה ב-Payments Dashboard.

שדה KPI: הנתון המצטבר יושב על כרטיס הלקוח

כמה הזמנות יש ללקוח הזה? כמה הוא הכניס לנו השנה? עד היום התשובה חיה רק ב-KPI Dashboard. שדה ה-KPI החדש מחשב ספירה או סכום מרשומות מקושרות ושומר את הערך על רשומת האב עצמה, כך שאפשר לסנן לפיו, למיין לפיו, לייצא אותו ולהפעיל עליו Workflows. הערך מתעדכן אוטומטית כשרשומות הבן משתנות.

שלב אחר שלב

1. נכנסים לעריכת קבוצת שדות ויוצרים שדה חדש מסוג KPI field.
2. בוחרים את הישות שבה יש שדה קישור לישות הנוכחית, שעליה רוצים לבצע את האגרגציה. משמע את ישות הבן שממנה רוצים לחשב את הנתון, למשל Orders.
3. בוחרים את שדה הקישור לישות בה אנחנו יוצרים את השדה. משמע את שדה הקישור שמחבר את רשומת הבן לרשומת האב, למשל Client.
4. בוחרים את סוג החישוב שרוצים לעשות:
   • Count – מספר הרשומות המקושרות דרך שדה הקישור שבחרנו.
   • Sum – סכום של שדה מספרי (שדה טקסט בפורמט ערך מספרי בלבד) ברשומות המקושרות.
5. במקרה של Sum, בוחרים את השדה המספרי שעליו יתבצע החישוב, למשל Amount.

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

1. בוחרים האם לכלול רשומות שנמצאות בארכיון (בישות הבן, הישות עליה מבצעים את האגרגציה).
2. שומרים את השדה.
3. המערכת מחשבת ושומרת את הערך באופן אוטומטי.
4. כאשר רשומות הבן משתנות, הערך מתעדכן אוטומטית לאחר עיבוד אסינכרוני.
5. המשתמש יכול להשתמש בערך כמו בשדה מספרי רגיל – לצפות בו, לסנן, למיין, לייצא ולהשתמש בו ב-Workflows.
6. השדה עצמו הוא Read-only ולא ניתן לערוך אותו ידנית.
7. אם אין מספיק Workflow Operations לחישוב מחדש, הערך האחרון נשמר והשדה מסומן כ-Stale, מבלי לחסום את שמירת רשומת הבן.

שימושים עיקריים

• ספירת רשומות ילדים – למשל מספר ההזמנות של לקוח.
• חישוב סכום מצטבר – למשל סך ההכנסות מכל ההזמנות של לקוח.
• סינון ומיון לפי נתון מצטבר – למשל הצגת לקוחות עם הכנסות מעל 100,000 ₪.
• שימוש בנתון ב-Workflows – למשל הפעלת תהליך כאשר מספר ההזמנות של לקוח עובר סף מסוים.
• ייצוא נתונים – הכנסת נתוני rollup לדוחות וייצוא מטבלאות.
• שימוש במסמכים וב-API – הערך נשמר כחלק מרשומת האב ולכן ניתן לצרוך אותו גם מחוץ ל-KPI Dashboard.

למי מיועד

• Solution Builders / Implementers – שרוצים לבנות קשרים וחישובים בין ישויות ללא כתיבת קוד.
• מנהלי CRM ומכירות – שרוצים לראות על כרטיס הלקוח נתונים מצטברים כמו מספר עסקאות או Total Revenue.
• מנהלי Operations – שרוצים לנהל רשומות אב לפי נתונים שנצברים מרשומות משנה.
• מנהלי צוותי שירות – למשל לראות כמה פניות פתוחות/היסטוריות קשורות ללקוח.
• משתמשים שעובדים עם טבלאות ודוחות – יכולים לסנן ולמיין לפי הערך המצטבר, בניגוד ל-KPI Dashboard שמבצע חישוב חי בלבד.

מה זה פותר / דוגמאות

• סכום מכירות ללקוח
  לפני: ניתן היה לראות KPI של מכירות ב-Dashboard, אבל לא היה ערך שמור על רשומת הלקוח.
  אחרי: ניתן ליצור KPI מסוג Sum על Orders → Amount, והסכום נשמר ישירות על הלקוח.
• מספר הזמנות ללקוח
  יוצרים KPI מסוג Count שמחובר ל-Orders. אם ללקוח יש 27 הזמנות, שדה ה-KPI יציג 27.
• סינון לקוחות לפי הכנסות
  לדוגמה, אפשר לסנן טבלת Clients כך שתציג רק לקוחות עם Total Revenue > 100,000.
• מיון לפי פעילות
  אפשר למיין לקוחות לפי מספר ההזמנות שלהם, מהלקוח עם הכי הרבה הזמנות לפחות.
• Workflow המבוסס על נתון מצטבר
  לדוגמה: כאשר סכום ההזמנות של לקוח משתנה ועובר סף מסוים, ניתן להפעיל Workflow בהתאם לערך החדש.
• מחיקת/עדכון הזמנה
  אם הזמנה נמחקת או הסכום שלה משתנה, ה-KPI של הלקוח הרלוונטי מתעדכן אוטומטית.
• העברת רשומה בין לקוחות
  אם הזמנה עוברת מלקוח A ללקוח B, המערכת מעדכנת את ה-KPI של שני הלקוחות – גם מורידה מהראשון וגם מוסיפה לשני.

Origami Schedule: כל טפסי זימון התורים במסך אחד

אפליקציה חדשה שמרכזת את כל טפסי ה-Web שמשמשים לזימון תורים. במקום להיכנס לכל טופס בנפרד כדי לבדוק אם הוא פעיל וכמה תורים נקבעו דרכו, מקבלים Dashboard אחד עם סטטוס כל טופס, מספר התורים העתידיים, סטטיסטיקת זימונים לאורך זמן ו-Booking Funnel שמראה איפה בדיוק המזמינים נוטשים.

שלב אחר שלב

1. המשתמש מוסיף דף חדש מסוג אפליקציה.
2. המשתמש נכנס לאפליקציית Origami Schedule החדשה.
3. במסך הראשי מוצג Dashboard מרכזי של כלל טפסי ה-Web במערכת שמכילים שדה Calendar ומשמשים לזימון תורים.
4. המשתמש רואה במקום אחד את כל טפסי הזימון, ללא צורך להיכנס לכל Web Form בנפרד.
5. עבור כל טופס מוצגים פרטי ניהול מרכזיים:
   • שם הטופס.
   • האם הטופס פעיל.
   • הישות שאליה הטופס משויך.
   • האם קישור הזימון פתוח וזמין למזמינים.
   • מספר התורים העתידיים.
   • נתונים נוספים הקשורים לפעילות הטופס.
6. המשתמש יכול לבחור טופס מסוים מתוך הרשימה ולהמשיך לניהול או לצפייה בפרטים שלו.
7. ב-Dashboard מוצגת סטטיסטיקה כללית של פעילות הזימונים לאורך זמן, כך שניתן לראות את היקף התורים בתקופות שונות ולזהות מגמות.
8. בנוסף מוצג Booking Funnel, שמציג את התהליך שעוברים המשתמשים מהגעה לעמוד הזימון ועד להשלמת הזמנה.
9. באמצעות הנתונים המרוכזים המשתמש יכול להבין אילו טפסי זימון פעילים, כמה תורים צפויים, ומה רמת השימוש וההמרה של תהליך הזימון.

שימושים עיקריים

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

למי מיועד

• מנהלי מערכת ו-Solution Builders שמנהלים מספר Web Forms המשמשים לקביעת תורים ורוצים לנהל אותם ממסך מרכזי.
• מנהלי Sales שמפעילים מספר טפסים לקביעת Demo או שיחות מכירה ורוצים לעקוב אחר היקף התורים.
• מנהלי HR שמנהלים טפסים לקביעת ראיונות ומעוניינים לראות את היקף הפעילות של כל טופס.
• מנהלי Support / Customer Success שמאפשרים ללקוחות לקבוע פגישות דרך מספר טפסים ורוצים לעקוב אחר התורים והביצועים.
• מנהלי Operations שרוצים לזהות אילו טפסי זימון פעילים, כמה תורים צפויים ומה מצב השימוש בהם.

מה זה פותר / דוגמאות

• אין צורך לחפש טפסי זימון בנפרד
  במקום להיכנס לכל Web Form כדי לבדוק אם הוא פעיל וכמה תורים נקבעו דרכו, כל הטפסים מופיעים ברשימה מרכזית באפליקציה.
• תמונת מצב על כלל מערך הזימונים
  לדוגמה, ארגון מפעיל 10 טפסים לקביעת תורים עבור Sales, HR ו-Support. ה-Dashboard מציג את כולם ומאפשר להבין במהירות אילו טפסים פעילים וכמה תורים עתידיים קיימים בכל אחד.
• מעקב אחר תורים עתידיים
  ניתן לראות שטופס מסוים כולל למשל 35 תורים עתידיים, בעוד שטופס אחר כולל 0, ולזהות הבדלים בפעילות.
• מעקב אחר מגמות לאורך זמן
  הגרף הסטטיסטי מאפשר לראות כמה תורים נקבעו בכל יום ולזהות תקופות של עלייה או ירידה בביקוש.
• ניתוח Booking Funnel
  ניתן לראות את המעבר בין שלבי הזימון, למשל משתמשים שנכנסו לעמוד הזימון, צפו בזמינות, התחילו תהליך Booking ולבסוף השלימו אותו. כך ניתן לזהות היכן משתמשים נוטשים את התהליך.
• זיהוי בעיות בטפסים
  אם טופס מסוים אינו פעיל או שהקישור שלו אינו פתוח, ניתן לזהות זאת ישירות מה-Dashboard במקום לגלות זאת רק לאחר שלקוח מדווח שאינו מצליח לקבוע תור.

ייצוא חשבוניות לחשבשבת בלחיצה אחת

סוף החודש הפך לפעולה של דקה. בוחרים חברה וטווח תאריכים, לוחצים ייצוא, ומקבלים קובץ ZIP עם קבצי הייבוא בפורמט של חשבשבת, מוכנים לייבוא ישיר. בלי הקלדה ידנית, בלי המרות, כולל מסמכים במטבע חוץ והתאמה אוטומטית לחשבונות הנהלת החשבונות של כל חברה.

שלב אחר שלב

1. נכנסים לאפליקציית החשבוניות.
2. נכנסים להגדרות, לחברה אותה רוצים לחבר.
3. מסמנים את האפשרות ״ייצוא לחשבשבת״.
4. מגדירים את טווח התאריכים של המסמכים לייצוא.
5. לוחצים על ייצוא.
6. המערכת יוצרת ומורידה קובץ ZIP המכיל את קבצי הייבוא בפורמט הנתמך על ידי חשבשבת.
7. מייבאים את הקבצים ישירות לחשבשבת באמצעות מנגנון הייבוא המובנה שלה.

שימושים עיקריים

• ייצוא חשבוניות וקבלות ישירות לפורמט הייבוא של חשבשבת.
• בחירת חברה וטווח תאריכים לפני ביצוע הייצוא.
• תמיכה במסמכים במטבע מקומי ובמטבע חוץ.
• התאמה אוטומטית לחשבונות הנהלת החשבונות שהוגדרו עבור כל חברה.
• יצירת קבצי ייבוא מוכנים לשימוש ללא צורך בהמרות ידניות.

למי מיועד

• צוותי הנהלת חשבונות.
• מנהלי כספים.
• מנהלי מערכת.
• ארגונים המשתמשים בחשבשבת לניהול הנהלת החשבונות.

מה זה פותר / דוגמאות

• מבטל את הצורך בהקלדה ידנית או בהמרת נתונים לפני ייבוא לחשבשבת.
• מאפשר להעביר כמות גדולה של חשבוניות וקבלות בצורה מהירה ואחידה.
• שומר על התאמה בין הנתונים במערכת Origami לבין מערכת חשבשבת.
• תומך גם במסמכים במטבע חוץ ובהמרתם בהתאם לשערי המטבע הרלוונטיים.
• לדוגמה: בסוף החודש, מנהל החשבונות בוחר חברה וטווח תאריכים, מוריד את קובץ ה-ZIP שנוצר ומייבא אותו ישירות לחשבשבת, כך שכל החשבוניות והקבלות נקלטות במערכת ללא עבודה ידנית.

שמירת פילטרים בכל סוגי הווידג׳טים

עד היום אפשר היה לשמור פילטרים רק ב-Datatable וב-Sortable List. בכל שאר הווידג׳טים המשתמש הגדיר את אותם תנאים מחדש בכל כניסה. מהגרסה הזו שמירת פילטרים זמינה בכל סוגי הווידג׳טים, כך שההתנהגות עקבית והדשבורד נפתח בבוקר עם התצוגה שרוצים.

שלב אחר שלב

1. המשתמש נכנס למסך שבו מוצג Widget כלשהו.
2. המשתמש פותח את אפשרויות הסינון של ה-Widget.
3. המשתמש מגדיר את תנאי הסינון הרצויים.
4. המשתמש בוחר באפשרות Save Filter.
5. המערכת שומרת את הגדרות הסינון ומאפשרת למשתמש להשתמש בהן שוב.
6. המשתמש יכול לחזור ל-Widget ולבחור את ה-Filter השמור במקום להגדיר מחדש את אותם תנאי סינון.
7. האפשרות לשמור Filters זמינה עבור כל סוגי ה-Widgets.

שימושים עיקריים

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

למי מיועד

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

מה זה פותר / דוגמאות

• כיום ניתן לשמור Filters רק ב-Datatable וב-Sortable List Widgets. עבור שאר סוגי ה-Widgets, המשתמש צריך להגדיר מחדש את אותם תנאי סינון בכל פעם שהוא חוזר ל-Widget. השינוי מאפשר לשמור Filters בכל סוגי ה-Widgets, וכך להפוך את ההתנהגות לעקבית ונוחה יותר.
• דוגמה 1 – Dashboard:
  המשתמש מציג Widget שמציג נתונים של לקוחות ומגדיר Filter שמציג רק לקוחות פעילים. המשתמש שומר את הפילטר ויכול להפעיל אותו שוב בעתיד בלחיצה אחת.
• דוגמה 2 – מעקב אחר משימות:
  המשתמש רוצה לראות רק משימות שטרם הושלמו ושמועד היעד שלהן בשבוע הקרוב. במקום להגדיר את התנאים מחדש בכל כניסה, הוא שומר את ה-Filter ומשתמש בו שוב.
• דוגמה 3 – מספר Filters לאותו Widget:
  המשתמש עובד עם Widget מסוים ורוצה לשמור מספר תרחישים:
  • לקוחות חדשים
  • לקוחות פעילים
  • לקוחות ללא פעילות לאחרונה. כל Filter נשמר בנפרד וניתן לבחור ביניהם בהתאם לצורך.
• דוגמה 4 – Widget מסוג שאינו Datatable או Sortable:
  המשתמש עובד עם Widget מסוג אחר שאינו תומך כיום בשמירת Filters. לאחר השינוי, הוא יכול להגדיר Filter, לשמור אותו ולחזור אליו בהמשך בדיוק כמו ב-Datatable וב-Sortable List.
• דוגמה 5 – עבודה יומיומית:
  משתמש נכנס בכל בוקר לאותו Dashboard ורוצה לראות את אותם נתונים מסוננים. במקום להגדיר מחדש מספר תנאים בכל יום, הוא מפעיל את ה-Filter השמור ומקבל מיד את התצוגה הרצויה.

ייצוא מהיר של Audit Trail ל-PDF או CSV

כל היסטוריית השינויים של רשומה, בקובץ אחד, בלחיצה. PDF לתיעוד ושיתוף, CSV לניתוח באקסל. הקובץ כולל גם את פרטי הייצוא עצמו: מי ייצא, מתי, איזו רשומה וכמה שורות. גם פעולת הייצוא עצמה מתועדת ב-Audit Trail. מי שעובד מול Compliance או ביקורת יבין מיד למה זה משנה.

שלב אחר שלב

1. המשתמש נכנס לרשומה הרצויה.
2. המשתמש פותח את ה-Audit Trail של הרשומה.
3. המשתמש בוחר את טווח התאריכים או הפילטרים הרצויים, במידה שקיימים.
4. המשתמש לוחץ על Quick Export.
5. המערכת מייצאת את נתוני ה-Audit Trail שהמשתמש מורשה לצפות בהם.
6. המשתמש מקבל את הקובץ בפורמט הנתמך, PDF או CSV, בהתאם לדרישה שאושרה.
7. הקובץ כולל את נתוני ה-Audit Trail וכן מידע על הייצוא עצמו, כגון המשתמש שביצע את הייצוא, תאריך ושעת הייצוא, הרשומה ומספר השורות.
8. פעולת הייצוא מתועדת גם היא ב-Audit Trail כאירוע חדש.

שימושים עיקריים

• ייצוא Audit Trail מלא של רשומה.
• שמירת היסטוריית פעולות כקובץ PDF לצורך תיעוד, שיתוף או ארכוב.
• ייצוא ל-CSV לצורך עבודה עם הנתונים ב-Excel או כלי ניתוח אחרים.
• ייצוא היסטוריה לאחר החלת טווח תאריכים או פילטרים.
• שיתוף היסטוריית הפעולות עם צוותי תמיכה, IT, Compliance או גורמים עסקיים.

למי מיועד

• מנהלי מערכת – לצורך תיעוד ובקרה של שינויים ברשומות.
• צוותי Compliance וביקורת – לצורך הפקת דוחות Audit Trail ושמירתם.
• צוותי תמיכה ו-IT – לצורך חקירת שינויים ופעולות שבוצעו ברשומות.
• מנהלים ואחראי תהליכים – לצורך סקירת היסטוריית הפעילות של רשומות.
• משתמשים שצריכים מסמך מתועד – יכולים להשתמש ב-PDF להצגה או שיתוף.
• משתמשים שצריכים לנתח את הנתונים – יכולים להשתמש ב-CSV ולעבד את הנתונים ב-Excel או בכלי חיצוני.

מה זה פותר / דוגמאות

• הפיצ’ר מאפשר למשתמש להוציא את ה-Audit Trail במהירות ובפורמט שימושי, בלי להעתיק ידנית את המידע או לבצע תהליך ייצוא מורכב.
• דוגמה 1 – תיעוד רשמי:
  המשתמש נדרש להעביר תיעוד של כל השינויים שבוצעו ברשומה. הוא משתמש ב-Quick Export ומפיק קובץ PDF שניתן לשמור או לשתף כמסמך מתועד.
• דוגמה 2 – ניתוח נתונים:
  המשתמש רוצה לנתח את הפעולות שבוצעו ברשומה לאורך זמן. הוא מייצא את ה-Audit Trail כ-CSV ופותח אותו ב-Excel לצורך סינון, מיון וניתוח.

Call Summary תומך ב-HTML: סיכומי שיחה מובנים מהמרכזיה

כשמערכת AI או PBX מייצרת סיכום שיחה עם כותרות, פסקאות ורשימות, אין סיבה שהוא יגיע ל-Origami כטקסט שטוח. שדה Call Summary תומך עכשיו ב-HTML דרך API, שומר על המבנה והעיצוב, ומחזיק תכנים ארוכים של עד כ-10,000 תווים.

שלב אחר שלב

1. המשתמש נכנס לדף האפליקציה של המרכזיה, או לישות בה מוגדר Omni Channel המחובר למרכזיה.
2. המשתמש ניגש לרשומה הרלוונטית של הלקוח, או לשורה שמסמכת את השיחה הרלוונטית.
3. המשתמש פותח את Call Summary על ידי לחצן העין (בדף האפליקציה), או על ידי הכפתור המיועד בתיעוד השיחה בOmni.
4. באמצעות קריאת API ניתן לשלוח כעת לשדה תוכן בפורמט HTML.
5. המערכת קולטת את תוכן ה-HTML ושומרת אותו בשדה כראוי.
6. בעת הצגת הרשומה, תוכן ה-Call Summary מוצג למשתמש בפורמט HTML ולא כטקסט רגיל.
7. מבנה התוכן נשמר בתצוגה, כולל אלמנטים כמו כותרות, פסקאות, רשימות והדגשות.
8. השדה תומך גם בתכנים ארוכים, כולל ערכים של עד כ-10,000 תווים.

שימושים עיקריים

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

למי מיועד

• צוותי מכירות – להצגת סיכומי שיחות שמגיעים אוטומטית ממערכת PBX.
• צוותי שירות ותמיכה – לשמירת סיכומי שיחה הכוללים פירוט של הבעיה, הפתרון ו-Next Steps.
• ארגונים שמשתמשים במערכות AI – כאשר מערכת חיצונית מייצרת סיכום שיחה מובנה ב-HTML.
• מערכות PBX ואינטגרציות חיצוניות – להעברת מידע עשיר ומובנה ישירות ל-Call Summary.

מה זה פותר / דוגמאות

• כיום Call Summary הוא שדה טקסט רגיל, ולכן תוכן HTML שמגיע ממערכת חיצונית עלול לאבד את המבנה והעיצוב שלו. השינוי מאפשר גם לקבל תוכן HTML דרך API וגם להציג אותו כ-HTML בשדה.
• דוגמה 1 – סיכום שנוצר על ידי AI:
  מערכת AI מייצרת סיכום הכולל:
  • תקציר השיחה
  • נושאים שעלו
  • בקשות הלקוח
  • Next Steps. התוכן נשלח ל-Call Summary כ-HTML ומוצג ברשומה באותו מבנה.
• דוגמה 2 – תוכן ארוך:
  מערכת PBX מייצרת סיכום שיחה של כ-10,000 תווים. התוכן נשלח דרך API ונקלט בשדה ללא חיתוך, ולאחר מכן מוצג בצורה תקינה למשתמש.
• דוגמה 4 – תוכן מעוצב:
  ה-API שולח תוכן הכולל תגיות HTML כמו כותרות, פסקאות ורשימות. במקום להציג את תגיות ה-HTML כחלק מהטקסט, המערכת מפרשת אותן ומציגה את התוכן בצורה מעוצבת.

URL ייעודי לכל עמוד בהגדרות ישות

לכל עמוד בהגדרות הישות יש עכשיו כתובת משלו: fields, views, workflows, recycle-bin, forms-documents. גם Tabs פנימיים כמו Visual Editor או Documents מקבלים URL ייעודי שנפתח ישירות.

שלב אחר שלב

1. נכנסים ל-Entity Settings של ישות.
2. לכל עמוד מרכזי בהגדרות יש כתובת URL ייעודית משלו.
3. ניתן לנווט ישירות לעמוד Fields באמצעות /fields.
4. ניתן לנווט ישירות לעמוד Views באמצעות /views.
5. ניתן לנווט ישירות לעמוד Workflows באמצעות /workflows.
6. ניתן לנווט ישירות ל-Recycle Bin באמצעות /recycle-bin.
7. ניתן לנווט ישירות ל-Forms & Documents באמצעות /forms-documents.
8. ניתן לחזור ישירות לעמוד הראשי של Entity Settings באמצעות /entity-settings.
9. גם עמודים פנימיים או Tabs בתוך הגדרות מקבלים URL ייעודי, למשל:
   • /fields/visual-editor
   • /forms-and-documents/documents
10. כאשר משתמש נכנס ל-URL של Tab פנימי, המערכת פותחת ישירות את ה-Tab המתאים במקום לפתוח את העמוד הראשי.
11. ניתן לשמור או לשתף URL ספציפי, וכאשר משתמש פותח אותו הוא מגיע ישירות למסך הרלוונטי.

שימושים עיקריים

• ניווט ישיר לעמוד מסוים בהגדרות ישות.
• שיתוף קישור ישיר בין אנשי צוות.
• שמירת עמודי Settings כ-Favorites/Bookmarks.
• פתיחה ישירה של Tabs פנימיים.
• שיפור ניווט והיסטוריית Browser.
• יצירת URLs יציבים עבור הדרכות, Support ותיעוד.

למי מיועד

• מנהלי מערכת – שמנהלים את הגדרות הישויות וצריכים להגיע במהירות למסך מסוים.
• Solution Builders – עובדים באופן שוטף עם Fields, Views, Forms ו-Workflows.
• אנשי Support – יכולים לשלוח למשתמש קישור ישיר למסך שבו נדרש שינוי או בדיקה.
• מטמיעים ואנשי Implementation – יכולים להשתמש ב-URL ישיר כחלק מהדרכה או תהליך הגדרה.
• מנהלי צוותים – יכולים לשתף קישורים ספציפיים להגדרות עם משתמשים אחרים.

מה זה פותר / דוגמאות

• ניווט מסורבל בתוך Settings
  לפני: URL כללי של הגדרות הישות לא אפשר להגיע ישירות לעמוד הרצוי.
  אחרי: לכל עמוד יש URL משלו.
• שיתוף קישור ל-Fields
  במקום להסביר למשתמש להיכנס ל-Entity Settings ואז לבחור Fields, ניתן לשלוח אותו ישירות ל-/fields.
• פתיחה ישירה של Visual Editor
  ניתן לשמור או לשתף URL שמוביל ישירות ל-/fields/visual-editor, במקום לפתוח קודם את Fields ואז לבחור את העורך.
• פתיחה ישירה של Documents
  URL כמו /forms-and-documents/documents יפתח ישירות את ה-Documents Tab ולא את העמוד הראשון של Forms & Documents.

Enter בחיפוש החכם פותח את View All

שיפור קטן שמרגישים בכל חיפוש. מקלידים, לוחצים Enter, ומקבלים את כל התוצאות, בלי לעבור לעכבר באמצע. ואם יש הצעת Autocomplete פעילה, Enter ממשיך לבחור אותה בדיוק כמו קודם.

שלב אחר שלב

1. המשתמש פותח את Smart Search.
2. מזין מילת חיפוש או ערך לחיפוש.
3. המערכת מציגה את תוצאות/הצעות החיפוש הרלוונטיות.
4. המשתמש לוחץ על Enter במקלדת.
5. המערכת פותחת אוטומטית את חלון View All עם תוצאות החיפוש.
6. התנהגות זו זהה ללחיצה ידנית על כפתור View All.
7. אם שדה החיפוש ריק, ההתנהגות זהה לזו של לחיצה על View All כאשר השדה ריק.

שימושים עיקריים

• פתיחת תוצאות החיפוש המלאות באמצעות המקלדת.
• חיפוש מהיר ללא צורך לעבור מהקלדת הטקסט לעכבר.
• שיפור חוויית השימוש ב-Smart Search.
• תמיכה בזרימת עבודה מהירה עבור משתמשים שמעדיפים ניווט באמצעות מקלדת.

למי מיועד

• כל משתמשי Origami שמשתמשים ב-Smart Search לאיתור רשומות ומידע.
• משתמשים שעובדים בעיקר עם מקלדת וצריכים לבצע חיפושים רבים ברצף.
• אנשי שירות, מכירות ו-Operations שמבצעים חיפושים תכופים במערכת.
• משתמשים שמחפשים ערכים שאינם מופיעים בהצעות הראשוניות וצריכים לעבור לתוצאות המלאות.

מה זה פותר / דוגמאות

• Enter שלא מבצע פעולה
  לפני: המשתמש מקליד John Smith, לוחץ Enter, ושום דבר לא קורה. כדי לראות את כל התוצאות הוא חייב ללחוץ ידנית על View All.
  אחרי: לחיצה על Enter פותחת ישירות את תוצאות View All.
• חיפוש ללא צורך בעכבר
  המשתמש יכול לבצע את כל הפעולה באמצעות המקלדת: להקליד, Enter, לקבל את כל התוצאות.
• שמירה על Autocomplete
  אם קיימת הצעה פעילה, Enter ממשיך לבחור אותה במקום לפתוח View All, כך שהשינוי לא פוגע בהתנהגות החיפוש הקיימת.
• התנהגות עקבית
  Enter מפעיל את אותה פעולה שמופעלת בלחיצה על View All, ולכן אין שתי לוגיקות ניווט שונות לאותה תוצאה.

תמיכה בקבצי SolidWorks בשדה העלאת קבצים

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

שלב אחר שלב

1. המשתמש נכנס לטופס או לרשומה שבה קיים File Upload Field.
2. המשתמש לוחץ על שדה העלאת הקובץ ובוחר קובץ מהמחשב.
3. המשתמש יכול להעלות גם קבצים בפורמטים SLDPRT ו-SLDDRW.
4. הקובץ מועלה ונשמר בשדה בהתאם להגדרות המערכת.

שימושים עיקריים

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

למי מיועד

• מיועד למשתמשים שעובדים עם קבצי SolidWorks ורוצים לצרף אותם לרשומות במערכת.

מה זה פותר / דוגמאות

• העדכון מרחיב את סוגי הקבצים הנתמכים בשדה העלאת הקבצים ומאפשר להעלות גם:
• .SLDPRT – קובץ חלק של SolidWorks.
• .SLDDRW – קובץ שרטוט של SolidWorks.

שיפורים במערכת התמיכה: מספר פנייה, חיפוש וסינון

מספר הפנייה של פורטל התמיכה מופיע עכשיו ישירות ברשימת הפניות בתוך Origami, זהה למספר שרואים ב-support.origami.ms. אפשר לצטט אותו בלי לפתוח את הפנייה, לחפש פניות בשורת החיפוש ולסנן את כולן לפי סטטוס.

שלב אחר שלב

1. המשתמש נכנס ל-Support מתוך סביבת Origami.
2. המערכת מציגה את רשימת הפניות שהמשתמש פתח דרך סביבת Origami.
3. עבור כל פנייה מוצג גם Ticket ID / מספר פנייה של פורטל התמיכה.
4. מספר הפנייה המוצג זהה למספר ה-Ticket שמופיע בפורטל support.origami.ms.
5. המשתמש יכול להעתיק או לצטט את מספר הפנייה בעת פנייה לצוות התמיכה, בלי לפתוח את הפנייה.
6. לחיצה על כפתור/קישור פתיחת הפנייה ממשיכה להפנות את המשתמש לפנייה המתאימה בפורטל ללא שינוי בהתנהגות הקיימת.
7. המשתמש יכול לחפש פניות בשורת החיפוש.
8. ניתן לסנן את כל הפניות לפי הסטטוס שלהן.

שימושים עיקריים

• זיהוי מהיר של פנייה לפי מספר.
• ציטוט מספר פנייה מול צוות התמיכה.
• איתור פנייה ספציפית ללא צורך לפתוח אותה.

למי מיועד

• משתמשי Origami שפותחים פניות לתמיכה וצריכים להפנות את צוות התמיכה לפנייה מסוימת.
• אנשי Support שמנהלים פניות בפורטל ורוצים שמשתמש יוכל לספק את אותו מספר פנייה שמופיע אצלם.
• מנהלי מערכת / אנשי Operations שמבצעים מעקב אחר פניות תמיכה וצריכים לזהות פנייה בין סביבת Origami לפורטל התמיכה.

מה זה פותר / דוגמאות

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

Origami User ID בייצוא המשתמשים

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

שלב אחר שלב

1. נכנסים ל-User Management.
2. בוחרים באפשרות לייצא את רשימת המשתמשים לקובץ אקסל.
3. המערכת מייצאת את המשתמשים בהתאם לסינון ולחלוקה הקיימים.
4. בגיליון All Users מופיעה עמודה חדשה בשם Origami User ID.
5. בכל שורת משתמש מופיע ה-Origami User ID המתאים לאותו משתמש.
6. גם בגיליונות של קבוצות המשתמשים מופיעה אותה עמודה עם ה-ID המתאים.
7. ניתן להשתמש ב-ID כטקסט, ללא שינוי פורמט, קיצור או איבוד ספרות.
8. יתר עמודות הייצוא, הסינון והקיבוץ נשארים ללא שינוי.

שימושים עיקריים

• זיהוי חד-משמעי של משתמשים שיוצאו מהמערכת.
• הצלבת משתמשים שיוצאו עם נתונים ממערכות או API אחרים.
• שימוש ב-User ID לצורכי תמיכה, ניתוח נתונים ואדמיניסטרציה.
• עבודה עם נתוני משתמשים מחוץ לממשק Origami.

למי מיועד

• מנהלי מערכת שמייצאים רשימות משתמשים לצורכי ניהול ובקרה.
• אנשי IT ו-Support שצריכים לזהות משתמש ספציפי לפי ה-ID הפנימי שלו.
• אנשי Operations / Data שמבצעים הצלבות בין נתוני משתמשים ממקורות שונים.
• מטמיעים ואנשי אינטגרציה שצריכים לקשר בין משתמשי Origami לבין מזהים במערכות אחרות.

מה זה פותר / דוגמאות

• זיהוי חד-משמעי של משתמש
  שמות וכתובות אימייל יכולים להשתנות או לא להיות ייחודיים, בעוד שה-Origami User ID מאפשר לזהות את המשתמש באופן חד-משמעי.
• הצלבת נתונים
  מנהל מייצא משתמשים ומעבד את הקובץ במערכת חיצונית. ה-Origami User ID מאפשר לקשר כל שורה למשתמש המתאים במערכת.
• עבודה עם קבוצות
  גם כאשר הייצוא מחולק לגיליונות לפי קבוצות, ה-ID נשמר בכל שורת משתמש ולכן ניתן לזהות את המשתמש ללא תלות בגיליון שבו הוא נמצא.

לסיכום

גרסה 6.3.5 מזיזה את Origami קדימה בשלושה כיוונים. AI שבאמת מזין את התהליך העסקי, עם בחירת מודל, Context מרשומות קשורות ותשובות מובנות, ו-Vision שכבר בונה ומעדכן Workflows מ-Prompt. כסף שנכנס, עם מערכת תשלומים מלאה, קישורי תשלום, חיבור לספקי סליקה וייצוא ישיר לחשבשבת. ונתונים שיושבים במקום הנכון, עם שדה KPI מצטבר על כרטיס הלקוח, אפליקציית זימון תורים, ייצוא Audit Trail ועוד עשרות שיפורים שנולדו מהשטח.

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