WEBVTT 00:00:00.000 --> 00:00:07.680 מוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure, והאנשים שמעצבים את עתיד העבודה. 00:00:07.860 --> 00:00:12.320 בינואר הקרוב, M365Con חוזרת, ואנחנו הולכים בגדול. 00:00:12.520 --> 00:00:18.700 הצטרפו אלינו למפגשים חיים, הדגמות מהעולם האמיתי, וידע מעשי ממומחי MVP ומומחי תעשייה מכל העולם. 00:00:18.920 --> 00:00:29.280 בלי שקפים גנריים, בלי אינסוף מילות buzzes, אנחנו מתמודדים עם האתגרים האמיתיים Copilot Studio, סוכני AI, Fabric, אבטחה, ממשל ואוטומציה. 00:00:29.280 --> 00:00:35.020 בין אם אתם אנשי איט, מפתחים או מובילים עסקיים, יש מפגשים שתוכננו במיוחד עבורכם. 00:00:35.480 --> 00:00:40.360 עם עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית. 00:00:40.800 --> 00:00:44.700 צפו בשידור חי וקחו תובנות מעשיות חזרה לארגון שלכם. 00:00:45.020 --> 00:00:49.300 ינואר 2027, עשרה ימים, קהילת Microsoft 1. 00:00:49.540 --> 00:00:50.880 ההרשמה פתוחה כעת. 00:00:53.100 --> 00:00:54.660 הבטיחו את מקומכם היום. 00:00:56.340 --> 00:00:59.300 זה בכתובת M365Con.net. 00:00:59.300 --> 00:01:05.100 הצטרפו עכשיו ל-M365Con.net ונתראה בשידור חי בינואר. 00:01:05.220 --> 00:01:11.500 חישבו על לקוח שקונה זקט באתר שלכם, בוחר באיסוף מהחנות, ואז מחליט שהוא לא מתאים ומחזיר אותו במיקום אחר. 00:01:11.680 --> 00:01:17.000 נשמע פשוט מספיק, נכון, אבל עבור עסקים רבים, הרכישה האחת הזו נוגעת במערכות נפרדות. 00:01:17.000 --> 00:01:25.380 האתר מכיר את ההזמנה, הקופה בחנות מכירה את ההחזרה, מערכת מלאי עוקבת אחרי מיקום הזקט, ופרטי הלקוח נמצאים במקום אחר לגמרי. 00:01:25.600 --> 00:01:28.280 זה יוצר פערים, עיכובים ושיחות מביכות בדל פה. 00:01:28.520 --> 00:01:34.880 אני מרקו פיטרס מ-M365FM, וטיפ הידע הזה מפרק את Dynamics 365 Commerce לשפה פשוטה. 00:01:35.040 --> 00:01:37.040 דמיינו עסק כמעוניי כבניין משרדים. 00:01:37.040 --> 00:01:42.580 האתר והחנויות הפיזיות הן כניסות שונות, אבל מאחורי הקלעים, כולם צריכים להוביל לאותו מרחב מקושר. 00:01:42.700 --> 00:01:45.720 אז מה זה בעצם Dynamics 365 Commerce? 00:01:47.140 --> 00:01:50.460 מה זה באמת Dynamics 365 Commerce? 00:01:51.200 --> 00:01:53.580 הנה הבעיה שכמעוניי עומד בפניה. 00:01:53.740 --> 00:02:02.020 אתם צריכים תצוגה משותפת אחת של הבסיס, אילו מוצרים אתם מוכרים, מה העלות של כל אחד, איפה נמצא המלאי, אילו הזמנות דורשות טיפול, ומה הלקוח קנה בעבר. 00:02:02.020 --> 00:02:05.920 ללא תצוגה משותפת, אנשים מבלים את היום בבדיקת מערכות זו מול זו. 00:02:05.920 --> 00:02:11.120 או עובד בחנות רואה מחיר אחד, האתר מציג אחר, ומישהו מבטיח פריט שלא באמת זמין. 00:02:11.280 --> 00:02:12.400 אף אחד לא נהנה מזה. 00:02:12.620 --> 00:02:18.980 Dynamics 365 Commerce מחבר את העבודה שמאחורי מחירת מוצרים בחנויות, באתרים ובצוותי הבק אופיס. 00:02:19.140 --> 00:02:23.780 הוא נותן לעסק פלטפורמה אחת מקושרת שמטפלת בכל מה שהלקוחות רואים ובכל מה שהם לא. 00:02:23.940 --> 00:02:26.340 עכשיו, שימו לב שלא קראתי לזה בוני אתרים. 00:02:26.340 --> 00:02:32.440 בוני אתרים עוזר לכם ליצור דפים שאנשים גולשים בהם, ומערכת קופה עוזרת למישהו לקבל תשלום בדל פה. 00:02:32.440 --> 00:02:42.240 Dynamics 365 Commerce יכולה לתמוך בשניהם, אך היא גם מחברת ביניהם לבין פרטי מוצרים, מלאי, תמחור, רישומי לקוחות, הזמנות והעבודה העסקית הרחבה שמאחוריהם. 00:02:42.360 --> 00:02:44.580 החיבור המשותף הזה משנה את השיחה. 00:02:44.720 --> 00:02:51.960 במקום לשאול איזו מערכת מחזיקה בתשובה הנכונה, הצוות שלך הפועל מתוך אותו מידע עסקי גם כשלקוחות נכנסים דרך דלתות שונו. 00:02:51.960 --> 00:03:00.060 Commerce צמחה מ-Dynamics 365 Retail, שהתמקדה בחנויות פיזיות ובנקודות מחירה, אך מייקרוסופט הרחיבה אותה כי הקניות כבר לא נשארות במקום אחד. 00:03:00.240 --> 00:03:06.420 אדם עשוי להסתכל על מוצר באינטרנט במהלך ארוחת הצהריים, לבקר בחנות אחרי העבודה ולבקש עזרה משירות הלקוחות מאוחר יותר. 00:03:06.640 --> 00:03:10.060 הרכישה יכולה לעבור בין ערוצים בעוד העסק שומר על אותו רישום. 00:03:10.060 --> 00:03:17.480 דמיינו שוב את בניין המשרדים ההוא, או-או, החנות הפיזית היא כניסה אחת, החנות המקוונת היא אחרת, ומוקד טלפוני יכול להיות כניסה נוספת. 00:03:17.560 --> 00:03:23.180 מאחורי כל דלת, Commerce מחברת אנשים לחדרים משותפים עבור מוצרים, מחירים, מלאי, הזמנות ולקוחות. 00:03:23.360 --> 00:03:25.820 זה לא אומר שכל עסק מתנהל בדיוק באותה דרך. 00:03:26.000 --> 00:03:31.960 כמעוני יכול להגדיר מגוון מוצרים, מחירים ומבצעים לערוצים שהוא מפעיל, בעוד צוותי המשרד האחורי מנהלים את הכללים העסקיים. 00:03:31.960 --> 00:03:36.680 עובדי החנות וקונים מקוונים משתמשים אז בכללים האלה דרך מסקים שתוכננו עבור התפקידים שלהם. 00:03:36.800 --> 00:03:46.740 Commerce מתחברת גם ליישומי Dynamics 365 אחרים ולשירותי מייקרוסופט, או-ניהול שרשרת ההספקה מטפל במוצרים, במלאי, במחסנים, בהובלה ובהפצה. 00:03:46.900 --> 00:03:53.140 פייננס מנהלת את הצד הפיננסי של פעילות החנות והפעילות המקוונת, ו-Dataverse עוזרת ליישומים עסקיים לשתף מידע. 00:03:53.260 --> 00:03:57.900 לכל אפליקציה יש תפקיד משלה, אך Commerce מחברת את פעילות המכירה לשאר חלקי העסק. 00:04:01.960 --> 00:04:05.540 מסע לקוח אחד בכל ערוץ 00:04:05.540 --> 00:04:13.500 ברוכים הבאים לפרק נוסף. היום אנחנו מנתחים את מסע הלקוח בכל ערוץ. בואו נצלול פנימה. דמיינו שמעיה מחפשת מעיל. 00:04:13.500 --> 00:04:20.160 היא פותחת את אתר האינטרנט של הכימונאי בטלפון שלה, מוצאת את הצבע והמידה שהיא רוצה, ובודקת אם לחנות הקרובה יש מלאי לפני שהיא עוזבת את הבית. 00:04:20.260 --> 00:04:25.520 תשובת המלאי הזו חייבת להיות מדויקת. אם האתר אומר שזה זמין, כדאי מאוד שזה יהיה על המדף. 00:04:25.520 --> 00:04:34.980 דיינמיקס 365 Commerce מחברת את החנות המקוונת למלאי בזמן אמת מחנויות וממחסנים. כך, לקוחות רואים את מה שהעסק באמת יכול להבטיח ולא כל מוצר בקטלוג. 00:04:34.980 --> 00:04:43.780 מעיל עשוי להופיע ברשימת המוצרים, אך זה לא אומר שהוא נמצא על מדף בקרבת מקום. כאשר מיה רואה שהמידה שלה זמינה לאיסוף, היא מבצעת את ההזמנה אונליין ואוספת אותה בחנות. 00:04:43.780 --> 00:04:50.660 אם הסניף המקומי לא מחזיק את המוצר, היא יכולה לבחור במשלוח לבית במקום. העסק יכול אפילו לשלוח את המעיל מחנות אחרת שבה הוא נמצא במלאי. 00:04:50.660 --> 00:04:59.020 עבור מיה, האפשרויות הללו מופיעות במהלך התשלום. מאחורי הקלעים, העסק צריך לדעת בדיוק איפה הפריט נמצא, איזה מיקום יכול להכין אותו ובאיזו מהירות הוא יגיע אליה. 00:04:59.160 --> 00:05:06.280 חנות היא כבר מזמן לא רק מקום שאנשים נכנסים אליו וקונים דברים. היא יכולה להכין הזמנות מקוונות, להחזיק הזמנות לאיסוף ולשלוח פריטים ללקוחות. 00:05:06.280 --> 00:05:16.340 זה נותן לקונים יותר דרכים לרכוש מבלי להכריח אותם להבין איך הכימונה היא מנהלת המלאי שלו. עכשיו, כאן זה נהיה מעניין. נניח שמאיה אוספת את המעיל, לוקחת אותו הביתה ומשנה את דעתה. 00:05:16.340 --> 00:05:26.880 כעבור כמה ימים, היא מבקרת בסניף אחר ומבקשת להחזיר אותו שם. איש הצוות צריך להיות מסוגל למצוא את ההזמנה המקוונת המקורית, לראות מה מאיה קנתה ולאבד את ההחזרה מבלי לבקש ממנה ליצור קשר עם האתר קודם. 00:05:26.880 --> 00:05:37.480 הזמנה ורישום הלקוח עוברים יחד עם הרכישה, למרות שהמכירה החלה אונליין וההחזרה מתבצעת בחנות אחרת. זה מסיר את אחד התסכולים הנפוצים ביותר בכימונאות, כשנאמר ללקוח שפריט שייך למערכת אחרת. 00:05:37.480 --> 00:05:45.000 יש עוד רגע שימושי בדלפק החנות. גם כן, מאיה מבקרת בסניף כדי למדוד נעליים מוצאת את הזוג הנכון, אבל מגלה שהמידה שלה עזלה במקום הזה. 00:05:45.000 --> 00:05:52.500 חנות לא מחוברת יכולה רק למשוך בכתפיים ולשלוח אותה למקום אחר. עם גישת, מדף אינסופי, איש המחירות יכול להסתכל מעבר למדפים של אותה חנות בלבד. 00:05:52.640 --> 00:05:58.940 הם יכולים לבדוק מלאי בחנות או במחסן אחר לבצע הזמנה עבור מאיה ולתאם משלוח לביתה או איסוף במקום שנוח לה. 00:05:58.940 --> 00:06:06.280 המדף הפיזי מפסיק להיות המגבלה המלאה של מה שהחנות יכולה למכור. כמובן, מי שהוא עדיין צריך להחליט מאיפה כל הזמנה צריכה להגיע. 00:06:06.280 --> 00:06:13.600 אם מספר חנויות ומחסנים מחזיקים את אותה נעל, שליחתה מהמקום הלא נכון יכולה להוסיף עלויות, להעט את המשלוח או להשאיר חנות מקומית ללא מלאי. 00:06:13.600 --> 00:06:17.920 Dynamics 365 Commerce כוללת ניהול הזמנות מבוזר עבור התפקיד הזה. 00:06:18.080 --> 00:06:23.760 במילים פשוטות, היא משתמשת בחוקים עסקיים כדי לבחור מקום מתאים לביצוע הזמנה בהתבסס על הבחירות שהכימונאי מגדיר. 00:06:23.760 --> 00:06:28.620 החוקים האלה לוקחים בחשבון מלאי זמין, הבטחת משלוח והמקומות שיכולים לבצע את ההזמנה. 00:06:28.700 --> 00:06:32.460 כך, הזמנה לא סתם נוחתת בתור אחד גדול שמחכה שאדם ינחש מה לעשות. 00:06:32.460 --> 00:06:39.720 המערכת מכוונת אותה לעבר חנות או מחסן שמתאימים לחוקי הכימונאי בזמן שהצוות מטפל בעבודת הליכות, האריזה, האיסוף או המשלוח בפועל. 00:06:39.840 --> 00:06:42.340 מאיה רואה אפשרות פשוטה, איסוף או משלוח. 00:06:42.340 --> 00:06:48.780 הכימונאי רואה שרשרת החלטות מקושרות שחייבת להישאר מלוכדת מהחיפוש הראשון אחר מוצר ועד להחזרה הסופית. 00:06:48.780 --> 00:06:57.220 מסע הלקוח הזה עובד רק כאשר האנשים בחנות יכולים לפעול על סמך אותו מידע, והם זקוקים לכלים המיועדים לדלפק לרצפת המחירה ולמחסן. 00:06:58.440 --> 00:07:01.620 החנות הפיזית, המסחר הכימונאי, הוא נקודת המחירה. 00:07:01.620 --> 00:07:04.080 בדלפק, הצוות זקוק לתשובות מהירות. 00:07:04.220 --> 00:07:09.640 הם לא יכולים לעצור לקוח באמצע הרכישה כדי לפתוח כמה מערכות ולחפש הזמנה בזמן שתור גדל מאחוריהם. 00:07:09.760 --> 00:07:14.820 הם צריכים מסך אחד שמאפשר להם למכור, להחזיר, לבדוק מלאי ולעזור לאדם שעומד ממש שם. 00:07:14.960 --> 00:07:17.060 הכלי הזה הוא אפליקציית StoreCommerce. 00:07:17.280 --> 00:07:22.860 StoreCommerce היא אפליקציית נקודת המחירה שלעיתים קרובות מקוצרת כפוז עבור אנשים העובדים בחנות פיזית. 00:07:22.860 --> 00:07:28.580 קופה היא משתמש בה בקופה קבועה, ואיש מחירות נושא אותה במכשיר נייד כדי לעזור ללקוחות בכל מקום שבו הם נמצאים. 00:07:28.700 --> 00:07:31.540 אותה אפליקציה פועלת על מחשב שולחני, טאבלט או טלפון. 00:07:31.680 --> 00:07:34.300 היא עובדת על Windows, iOS, Android ומקוס. 00:07:34.480 --> 00:07:35.900 זה מעניק לכימונאים גמישות. 00:07:35.900 --> 00:07:38.660 חנות גדולה עשויה להשתמש בדלפקי תשלום הסורתיים. 00:07:38.800 --> 00:07:41.060 חנות קטנה יותר עשויה להשתמש בטאבלטים. 00:07:41.180 --> 00:07:43.740 אבל כך או כך, המחירה היא אותו סוג של עסקה. 00:07:43.840 --> 00:07:46.600 תארו לעצמכם איש מחירות ליד מאיה והנעליים. 00:07:46.820 --> 00:07:48.600 מאיה שואלת עם המידה שלה זמינה. 00:07:48.780 --> 00:07:52.840 העובד מחפש, בודק מלאי, מוצא את הפריט ומשלים את הרכישה ממש שם. 00:07:52.980 --> 00:07:59.020 אם מאיה רוצה להחזיר משהו במקום זאת, העובד יכול למצוא את פרטי הלקוח או ההזמנה שלה ולהתחיל את ההחזרה מאותו כלי. 00:07:59.020 --> 00:08:02.200 דברים רגילים, נכון, אבל הכל תלוי במידע טוב. 00:08:02.420 --> 00:08:07.980 סטור קאמרס תומכת במחירות במזומן, איתור לקוחות, בדיקות מלאי, טיפול בהזמנות, החזרות ודיווחים. 00:08:08.120 --> 00:08:14.620 צוות החנות יכול גם לנהל דברים סביב המחירה כמו משמרות וניהול מזומנים, במקום להתייחס לקופה כאל מכשיר תשלום בלבד. 00:08:14.780 --> 00:08:17.580 נקודת מחירה הופכת לכלי עבודה עבור כל החנות. 00:08:17.580 --> 00:08:25.400 איכות החיבור חשובה גם היא, האינטרנט לא תמיד מושלם בחנויות, במיוחד בבניינים גדולים, מיקומים מרוחקים או מקומות שבהם הרשת מתנתקת לעתים. 00:08:25.500 --> 00:08:31.040 המסחר מתנהל בענן, אך הוא יכול להשתמש גם בהגדרות קצה קרובות יותר לחנות, כך שכימונאים יכולים להיערך לתנאים המקומיים שלהם. 00:08:31.160 --> 00:08:36.600 לקוחות עדיין מצפים שהדלפק יעבוד. זה לא אומר שעובד חנות צריך להבין במערכות ענן או בתכנון רשתות. 00:08:36.600 --> 00:08:40.140 הם פותחים את האפליקציה, עוקבים אחר השלבים עבור התפקיד שלהם ועוזרים ללקוח. 00:08:40.280 --> 00:08:44.260 מאחורי הקלעים, הקימונאי בוחר את ההגדרה ששומרת על פעילות החנויות כאשר הכישוריות משתנה. 00:08:44.380 --> 00:08:46.700 מסכים מבוססי תפקידים שומרים על כך בצורה פרקטית. 00:08:46.860 --> 00:08:48.840 קופי זקוק לדרך פשוטה לאבד מחירה. 00:08:48.980 --> 00:08:50.740 מנהל חנות זקוק לאפשרויות אחרות. 00:08:50.740 --> 00:08:52.640 עובד במחסן זקוק למידע על מוצרים. 00:08:52.820 --> 00:08:56.480 קומרס יכולה להתאים את החוויה לכל תפקיד במקום להציג כל כפתור לכולם. 00:08:56.660 --> 00:08:57.900 והנה נקודה מרכזית. 00:08:58.080 --> 00:09:01.460 מחירה בחנות פועלת לפי אותם חוקים עסקיים של מחירה מקוונת. 00:09:01.640 --> 00:09:07.340 מחירים, פרטי מוצר, פרטי לקוח ורישומי הזמנות לא צריכים חוקים שונים לאתר ולאולם התצוגה. 00:09:07.460 --> 00:09:10.500 הצוות משתמש בסטור קומרס, הקונים בחזית החנות, 00:09:10.500 --> 00:09:12.680 אך שניהם נשענים על אותה תשתית קומרס. 00:09:12.820 --> 00:09:16.640 זה שומר על חוויה עקבית, והצוות לא צריך לזכור המון חריגים. 00:09:16.800 --> 00:09:20.040 כך, חנות פיזית הופכת ליותר מאשר מדפים וקופה. 00:09:20.160 --> 00:09:22.340 היא הופכת לחלק מקושר מהפעילות כולה, 00:09:26.480 --> 00:09:28.860 מוצרים באמצעות המידע שהעסק כבר מנהל. 00:09:29.140 --> 00:09:32.600 אבל כל מסקי הצוות האלה צריכים מוח משותף מאחוריהם. 00:09:32.720 --> 00:09:37.460 מקום אחד שמטפל במוצרים, הזמנות ומחירים לפני שכל מסך דורש תשובה. 00:09:37.820 --> 00:09:39.600 המנוע שמאחורי חזית החנות. 00:09:39.600 --> 00:09:43.960 אז, למוח המשותף שדיברתי עליו יש שם יחידת קנה המידע של המסחר, קומרס סקייל יוניט. 00:09:44.120 --> 00:09:48.880 זה נשמע טכני, אבל תחשבו על זה כחדר המכונות שמריץ כל חוק מחירה מאחורי הערוצים של הכימונאי. 00:09:48.880 --> 00:09:53.760 בין אם לקוח קונה דרך אתר, אפליקציית חנות או אפליקציית קניות מותאמת אישית שהעסק בנה, 00:09:53.940 --> 00:09:55.380 המנוע הזה מטפל בכל בקשה. 00:09:55.540 --> 00:09:56.820 לקוחות לעולם לא רואים אותו. 00:09:56.960 --> 00:10:00.140 הם רואים דף מוצר, מסך תשלום או מכשיר של איש מחירות. 00:10:00.140 --> 00:10:06.660 מאחורי הקלעים, יחידת הקומרס סקייל יוניט מקבלת את הבקשות שהמסקים שולחים ומיישמת את אותם חוקי מסחר בכל מקום שבו אנשים קונים. 00:10:06.860 --> 00:10:08.280 סט לוגיקה אחד לכל ערוץ. 00:10:08.480 --> 00:10:09.440 זה הכסם שבדבר. 00:10:09.660 --> 00:10:11.080 זה מביא אותנו למסחר ללא ממששק. 00:10:11.080 --> 00:10:11.780 Headless Commerz. 00:10:11.880 --> 00:10:15.360 Headless פשוט אומר שמנוע המחירות חי בנפרד מהמסך שהאדם מסתכל עליו. 00:10:15.480 --> 00:10:20.840 למנוע לא אכפת אם לקוח משתמש באתר, אפליקציה בטלפון, קיוסק בשירות עצמי או טאבלט של עובד חנות. 00:10:20.840 --> 00:10:24.680 הוא מקבל בקשה, מריץ את החוקים העסקיים ושולח בחזרה את התשובה. 00:10:24.760 --> 00:10:29.460 המסך הוא הפנים, יחידת הקומרס סקייל יוניט היא החלק שעובד מאחורי אותם פנים. 00:10:29.700 --> 00:10:32.000 שימו לב שלא אמרתי שהמסך לא עושה כלום. 00:10:32.160 --> 00:10:34.640 הוא עושה הרבה, אבל הלוגיקה נשארת נפרדת. 00:10:34.640 --> 00:10:42.520 הפרדת השניים מאפשרת לכימוני לשנות או לבנות חוויית לקוח מבלי לבנות מחדש את כל החוקים למוצרים, מחירים, מלאי, מבצעים והזמנות בכל פעם. 00:10:42.520 --> 00:10:45.520 תארו לעצמכם כימוני שמשיק אפליקציה חדשה לנייד. 00:10:45.680 --> 00:10:52.300 ללא גישה זו, הצוות עשוי להצטרך לבנות מחדש את הלוגיקה שבודקת זמינות מוצרים, מחשבת מחירים, מכילה הנחות ויוצרת הזמנות. 00:10:52.300 --> 00:10:57.920 עם קומרס, האפליקציה החדשה יכולה פשוט להתחבר לאותו מנוע שכבר נמצא בשימוש על ידי החנות המקוונת ואפליקציית הסטור קומרס. 00:10:58.060 --> 00:11:00.520 מערכת חוקים אחת תומכת בחוויות לקוח רבות. 00:11:00.720 --> 00:11:01.520 זה כל העניין. 00:11:01.720 --> 00:11:03.420 והנה הסיבה לכך שזה חשוב. 00:11:03.620 --> 00:11:06.880 ללקוחות לא אכפת איזו מערכת טכנית ענתה על השאלה שלהם. 00:11:07.040 --> 00:11:12.260 אכפת להם שהמחיר בטלפון שלהם תואם למחיר בחנות, ושאפשר להזמין פריט שמופיע כזמין. 00:11:12.260 --> 00:11:16.180 החיבור בין מסך לבין יחידת המסחר עובד באמצעות ממשקי API. 00:11:16.460 --> 00:11:20.600 API מייצג ממשק תכנות יישומים, אבל לא צריך לזכור את השם המלא. 00:11:20.800 --> 00:11:22.720 דמיינו דלפק שירות בחנות גדולה. 00:11:22.920 --> 00:11:26.160 אתר אינטרנט שואל את הדלפק מה המחיר של הפריט הזה. 00:11:26.320 --> 00:11:29.160 הדלפק בודק את חוקי המסחר ומחזיר את המחיר. 00:11:29.360 --> 00:11:35.920 בקשה אחרת עשויה להיות האם הלקוח הזה יכול להזמין את הפריט הזה לאיסוף, או ען עצור הזמנה עבור המוצרים האלה. 00:11:35.920 --> 00:11:40.340 ה-API מעביר את הבקשות האלה בין המסך מול הלקוח לבין מנוע המסחר. 00:11:40.480 --> 00:11:44.020 האתר לא צריך לדעת איך מחירים או הזמנות עובדים מאחורי הקלעים, 00:11:44.300 --> 00:11:49.580 הוא רק מבקש את התוצאה דרך הדלפק, ויחידת המסחר מיישמת את חוקי הכימוני לפני המענה. 00:11:49.720 --> 00:11:53.840 המבנה הזה גם נותן לעסקים מרחב לבנות משהו מעבר לחזית החנות הסטנדרטית. 00:11:53.860 --> 00:11:56.780 הם עשויים ליצור חוויית קנייה בתוך אפליקציית מוביימי שלהם. 00:11:56.940 --> 00:11:59.160 שותף עסקי יכול לבנות ערוץ מחירות נוסף. 00:11:59.160 --> 00:12:01.420 אותו מנוע המסחר יכול לתמוך בחוויות האלה, 00:12:01.580 --> 00:12:05.760 כך שהעסק לא מתחיל מחדש עם סט חוקי מחירה שונה בכל פעם שהוא פותח דלת חדשה. 00:12:05.880 --> 00:12:10.000 כעת, דיינמיקס 365 קומרס מגיע גם עם חזית חנות e-commerce משלו. 00:12:10.160 --> 00:12:16.680 זוהי מערכת האתר שהלקוחות באמת רואים ולוחצים דרכה על מידע מוצר, תמונות, תפריטים, תוצאות חיפוש ושלבי תשלום. 00:12:16.840 --> 00:12:21.660 הוא משתמש בריאק, מסגרת פיתוח אתרים שעוזרת לצוותים לבנות דפי אינטרנט אינטראקטיביים. 00:12:21.660 --> 00:12:25.180 אתם לא צריכים להיות מפתחי אתרים כדי להבין את החלק הפרקטי. 00:12:25.300 --> 00:12:29.700 חזית החנות יכולה להכין חלקים מדף בשרת לפני שהוא מגיע לדפדפן של הלקוח, 00:12:29.980 --> 00:12:35.680 והיא גם יכולה להדכן חלקים מהדף בדפדפן כשהלקוח לוחץ, מחפש, מסנן או מוסיף מוצרים לעגלה. 00:12:35.880 --> 00:12:39.820 השילוב הזה עוזר לאתר לטעון דפים ולהגיב במהירות לפעולות הלקוח. 00:12:39.980 --> 00:12:41.860 כמעוני יכול גם להשתמש בסייט בילדר. 00:12:42.100 --> 00:12:45.200 הכלי מבוסס האינטרנט עבור אנשים שמנהלים דפים ותוכן שיווקי. 00:12:45.200 --> 00:12:51.180 הם יכולים לעבוד על האתר מול הלקוח בלי לשנות את מנוע המסחר שמטפל בבקשות מוצר, מחיר והזמנה מאחוריו. 00:12:51.300 --> 00:12:55.840 לאתר ולמנוע יש תפקידים שונים, אך לא כל הכימונאים מנהלים חנויות באותם תנאים. 00:12:56.000 --> 00:12:59.720 מיקום אחד עשוי להנות מאינטרנט יציב ולעבוד היטב עם שירותי ענן, 00:12:59.960 --> 00:13:02.700 בעוד אחר נמצא במקום עם קישוריות חלשה או לא אמינה. 00:13:02.860 --> 00:13:04.540 קומרס נותן מענה להבדל הזה. 00:13:04.540 --> 00:13:08.980 יחידת מסחר יכולה לרוץ בענן של מייקרוסופט, שם מייקרוסופט מנהלת את השירות. 00:13:09.020 --> 00:13:14.000 היא יכולה גם לפעול כי יחידה בניהול עצמי קרוב יותר לחנות, שבה הכימונאים מנהלת ההגדרה המקומית הזו. 00:13:14.160 --> 00:13:16.220 עסק יכול להשתמש בשילוב של שניהם. 00:13:16.420 --> 00:13:22.140 בחירה זו מאפשרת לכימונאים לתכנן לפי אופן הפעולה של כל מיקום, במקום לכפות על כל חנות הגדרה טכנית אחת. 00:13:22.140 --> 00:13:27.760 יחידה בניהול עצמי יכולה לשמור על אותו היגיון מסחרי קרוב יותר לחנות במקומות שבהם דישה לאינטרנט עלולה לגרום לי ועיות, 00:13:27.960 --> 00:13:31.640 בעוד שיחידות ענן תומכות בערוצים דרך אזורי אשוור המנוהלים על ידי מייקרוסופט. 00:13:31.740 --> 00:13:34.820 צוות החנות לא צריך לחשוב על כל זה בזמן שהוא עוזר ללקוח. 00:13:34.980 --> 00:13:38.900 הם משתמשים במסך שלפניהם, והקונה משתמש באתר או באפליקציה שלפניו. 00:13:38.900 --> 00:13:45.560 ובכל זאת, כל ערוץ תלוי בחדר המנועים שיגיב עם מידע המוצר, המחיר, נתוני המלאי ופעולת ההזמנה הנכונים. 00:13:45.780 --> 00:13:53.540 ברגע שהמחירות מתחילות לזרום, המידע חייב להישאר מחובר גם כן, כי מוצרים, רשומות לקוחות ומלאי לא יכולים לחיות כל אחד במגירה נפרדת. 00:13:53.640 --> 00:13:55.880 נתונים, נאמנות וקנייה בטוחה יותר. 00:13:56.120 --> 00:14:02.280 בכל פעם שאתה מבצע מחירה, אתה יוצר מידע. מוצר, מחיר, חנות, לקוח, פרטי הזמנה או הכל. 00:14:02.280 --> 00:14:07.560 אם המידע הזה נשאר מפוזר, עסק יכול למכור כל היום ועדיין להתקשות לראות מה אנשים באמת קונים. 00:14:07.780 --> 00:14:12.880 דיינמיקס 365 Commerce מחברת נתונים עסקיים עם דייטוורס ויחסון Azure Data Lake. 00:14:13.120 --> 00:14:17.040 דייטוורס פועל כמו ארון טיוק עסקי משותף עבור יישומים עסקיים של מייקרוסופט. 00:14:17.140 --> 00:14:21.240 מסחר, מחירות ושירות לקוחות יכולים להשתמש בו כדי להכסן ולשתף מידע עסקי, 00:14:21.440 --> 00:14:25.060 כך שצוותים לא נאלצים להעתיק את אותם פרטי לקוח או חשבון בין כלים נפרדים. 00:14:25.060 --> 00:14:27.100 זה יוצר רשומת לקוח ברורה יותר. 00:14:27.300 --> 00:14:33.060 הנה העניין, לקוח עשוי לקנות מהאתר, לדבר עם איש מחירות בחנות, ואז ליצור קשר עם התמיכה מאוחר יותר. 00:14:33.240 --> 00:14:39.860 כאשר האפליקציות המחוברות משתמשות במידע משותף, כל צוות יכול לעבוד עם אותם פרטי לקוח במקום להתחיל את השיחה מאפס. 00:14:40.020 --> 00:14:42.940 איחסון Azure Data Lake מטפל בסוג אחר של עבודה. 00:14:43.160 --> 00:14:45.500 דמיינו את זה כמחסן גדול לנתונים עסקיים. 00:14:45.720 --> 00:14:49.520 המסחר יכול לשלוח לשם נתוני עסקאות, יחד עם מידע מהחנות המקוונת, 00:14:49.520 --> 00:14:53.480 כך שהעסק יוכל ללמוד פעילות לאורך זמן במקום רק להסתכל על המחירה האחרונה. 00:14:53.640 --> 00:14:56.100 זה נותן לצוותים יותר מרחב לשאול שאלות מועילות. 00:14:56.260 --> 00:14:58.360 אילו מוצרים נמכרים היטב בחנויות מסוימות? 00:14:58.520 --> 00:15:01.240 אילו קטגוריות מביאות מחירות אך משאירות שולי רווח קטנים? 00:15:01.420 --> 00:15:03.080 איזה ערוץ מניב את רוב ההזמנות? 00:15:03.260 --> 00:15:09.260 דיווח מסחרי יכול לעזור למנהלים להסתכל על מוצרים, קטגוריות, עובדים, מסופים, חנויות וערוצי מחירה. 00:15:09.260 --> 00:15:16.700 עובד חנות יכול גם לראות דוחות המחוברים למקודת המחירה, בעוד שאנשים במשרד האחורי יכולים לבחון פעילות בכל העסק לאחר סמכרון הנתונים. 00:15:16.880 --> 00:15:19.160 הדוחות לא מנהלים את החנות עבור אף אחד. 00:15:19.340 --> 00:15:26.320 הם מעניקים לאנשים תמונה ברורה יותר של מה שקרה, כך שמנהל יכול לזהות דפוסים לפני שהוא מחליט מה לשנות במלאי, בתמחור או במבצעים. 00:15:26.480 --> 00:15:29.080 נאמנות לקוחות יושבת באותה תמונה מקושרת. 00:15:29.260 --> 00:15:32.680 כמעוני יכול להקים תוכנית נאמנות שבה רכישות מזכות בנקודות. 00:15:32.680 --> 00:15:38.660 לקוח יכול מאוחר יותר לממש את הנקודות הללו ברכישה עתידית, בין אם העסק מאפשר זאת בחנויות, באינטרנט או בשניהם. 00:15:38.800 --> 00:15:41.500 זה הופך רכישה פשוטה למערכת יחסים מתמשכת. 00:15:41.680 --> 00:15:46.700 כאשר לקוח בוחר להזדהות, המסחר יכול גם להביא את היסטוריית הרכישות שלו לתוך השיחה. 00:15:46.860 --> 00:15:55.420 איש מחירות עשוי לראות מידע שעוזר לו לדבר בצורה ברורה יותר על מה שאותו אדם קנה בעבר, בעוד שהחנות המקוונת יכולה להציג המלצות מוצרים המבוססות על דפוסי קנייה. 00:15:55.420 --> 00:16:02.260 המלצות לא קוראות את המחשבות של הלקוח. הן משתמשות במידע על קניות ורכישות כדי להציע פריטים של לקוח עשוי לרצות לראות. 00:16:02.400 --> 00:16:09.360 זה יכול לעזור לאנשים למצוא מוצרים קשורים, אך הכמעוני עדיין זקוק לנתוני מוצר הגיוניים ולחוויית קנייה שמתייחסת ללקוחות בכבוד. 00:16:09.540 --> 00:16:11.440 גם ביקורות מקוונות זקוקות לטיפול. 00:16:11.640 --> 00:16:19.580 המסחר כולל דירוגים וביקורות לחנויות אינטרנטיות, כך שלקוחות יכולים לפרסם משוב וכמעונאים יכולים להציג דירוגים בדפי המוצר. 00:16:19.580 --> 00:16:29.580 Azure Cognitive Services יכול לסנן באופן אוטומטי מילים גסות בית מינוס 40 שפות, ולכמעונאים יש גם כלי ניהול לטיפול בדאגות, משוב, בקשות הסרה ובקשות מידע. 00:16:29.700 --> 00:16:36.920 מערכת ביקורות זקוקה ליותר מאשר ציון כוכבים. היא צריכה דרך לשמור על דפי מוצר שימושיים מבלי להשאיר כל בעיה לאדם שימצא אותה ידני. 00:16:37.020 --> 00:16:41.360 הונאת תשלומים יוצרת דאגה נוספת, במיוחד כאשר הזמנות מגיעות דרך ערוצים דיגיטליים. 00:16:41.360 --> 00:16:46.480 Dynamics 365 Fraud Protection יכול להתחבר למסחר כדי לתמוך בהחלטות הונאה בזמן אמת. 00:16:46.660 --> 00:16:53.020 השירות משתמש במידע מרשת הגנת ההונאה שלו, באותות מכשירים ובכללים שנקבעו על ידי העסק כדי לסייע בהערכת עסקאות. 00:16:53.160 --> 00:16:54.820 שום תוכנה לא מסירה כל סיכון. 00:16:54.980 --> 00:16:58.360 כי מונאי עדיין זקוק למדיניות ברורה ולאנשים שיכולים לטפל בחריגים, 00:16:58.600 --> 00:17:03.380 אך כלי הונאה המחוברים יכולים לעזור לעסק לבדוק הזמנות מקוונות מבלי להתייחס לכל לקוח כאל בעיה. 00:17:03.380 --> 00:17:07.960 אז המסחר מרכז נתוני מחירות, נאמנות לקוחות, ביקורות ובדיקות הונאה סביב הרכישה. 00:17:08.060 --> 00:17:10.020 זה עשוי להישמע כמו הרבה, כי זה אכן כך. 00:17:10.140 --> 00:17:15.980 השאלה הבאה פשוטה יותר, אילו עסקים באמת זקוקים לפלטפורמה הזו ואיזו עבודה היא עדיין משאירה לאנשים? 00:17:16.860 --> 00:17:19.320 מי משתמש במסחר ומה זה לא מחליף? 00:17:19.460 --> 00:17:22.740 דמיינו מותג אופנה עם חנויות פיזיות ואתר אינטרנט משלו. 00:17:22.740 --> 00:17:27.940 העסק הזה צריך את אותו מידע על מוצרים, מחירים, מספרי מלאי ופרטי הזמנה הזמינים בשני המקומות. 00:17:28.060 --> 00:17:31.820 דיינמיקס 365 קומרס מחבר את כל הערוצים הללו כך שהכל נשאר עקבי. 00:17:31.960 --> 00:17:34.460 אה, לא עוד שליחת גיליונות אלקטרוניים בדואר אלקטרוני הלוך ושוב. 00:17:34.620 --> 00:17:36.920 האם זה משנה אם אתם מנהלים חנות אחת או חמישים? 00:17:37.060 --> 00:17:37.600 לא ממש. 00:17:37.760 --> 00:17:44.120 מה שחשוב הוא שהחנות, האתר וצוות המשרד האחורי משתמשים כולם באותו מידע משותף במקום להעביר עדכונים בין מערכות נפרדות. 00:17:44.120 --> 00:17:46.080 זה היה הרעיון המרכזי של טים. 00:17:46.260 --> 00:17:49.900 מסחר מתאים גם ליצרנים ולמפיצים שמוכרים לעסקים אחרים. 00:17:50.120 --> 00:17:56.300 נניח שיצרן נותן למפיצים שלו פורטל בשירות עצמי שבו הם בודקים מלאי, מעיינים במוצרים ומבצעים הזמנו. 00:17:56.480 --> 00:18:01.640 זה היה המסחר בין עסקים של טים ומסחר תומך בחוויות הקנייה הללו באמצעות ממשקי ה-API שלו. 00:18:01.780 --> 00:18:04.520 שימו לב שהקונה הפעם אינו טים לקוח מזדמן. 00:18:04.520 --> 00:18:09.620 זו יכולה להיות חברה שמבצעת הזמנות חוזרות, בודקת זמינות או מתאמת משלוח עבור הלקוחות שלה. 00:18:09.720 --> 00:18:11.800 עכשיו, האם המסחר מחליף את האנשים? 00:18:12.040 --> 00:18:18.780 לא. צוותי המשרד האחורי עדיין מטפלים בהגדרת מוצרים, תמחור ומבצעים, מעקב אחר מלאי והזמנות ודוחות מחירות ורווחים. 00:18:18.940 --> 00:18:24.000 מסחר נותן לצוותים האלה כלים מחוברים, אבל הוא לא הופך את הכמעונאות למערכת שפועלת מעצמה. 00:18:24.160 --> 00:18:25.580 אנשים הם עדיין חיוניים. 00:18:25.580 --> 00:18:29.700 רוב האנשים שומעים מסחר וחושבים שזה אומר רק להקים חנות מקוונת. 00:18:29.880 --> 00:18:39.700 חנות מקוונת יכולה להיות חלק מזה, אבל מסחר מגיע הרבה מעבר לכך, אל דלפק החנות, רשומות הלקוחות, תוכניות נאמנות, הגדרת מוצרים, טיפול בהזמנות וכל הנתונים שמאחורי המשימות האלה. 00:18:40.000 --> 00:18:43.280 הוא לא מחליף את המחסן, עובדי החנות, אנשי המשלוחים.