פתרון בעיות בשינויים שאינם מופיעים ב-Helpdesk

עקבו אחר שינוי חסר ב-Helpdesk דרך זכאות ב-Knowledge, בחירה, שפה, שמירה ופרסום. מדריך זה שומר על מיקוד העבודה בפתרון בעיות פרסום ב-Helpdesk ומספק נתיב חוזר שניתן למשתמש חדש ב-Humind לעקוב אחריו בלי לשנות תצורה לא קשורה...

עקבו אחר שינוי חסר ב-Helpdesk דרך זכאות ב-Knowledge, בחירה, שפה, שמירה ופרסום. מדריך זה שומר על מיקוד העבודה בפתרון בעיות פרסום ב-Helpdesk ומספק נתיב חוזר שניתן למשתמש חדש ב-Humind לעקוב אחריו בלי לשנות תצורה לא קשורה.

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

לפני שמתחילים

גישה: נדרשת גישת קריאה ל-Knowledge ול-Helpdesk. תיקון ופרסום דורשים הרשאת כתיבה.

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

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

תהליך עבודה שלב אחר שלב

  1. אשרו את ההיקף ואת המצב הנוכחי

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

    • ודאו את החברה הפעילה ואת ה-Agent לפני העריכה.
    • תעדו את המצב הנוכחי כדי שניתן יהיה להשוות את התוצאה לאחר השינוי.
    • עצרו אם המסך או ההרשאה אינם תואמים למשימה המתוכננת.
  2. הכינו את השינוי

    פתחו את תוכן ה-Helpdesk וודאו שמצב הכל-ציבורי או המצב הנבחר כולל את הפריט ואת כל הצאצאים הצפויים.

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

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

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

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

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

מגבלות חשובות והערות תפעול

  • שמירה מוצלחת מאשרת התמדה, לא כל סנכרון המשך או עדכון ציבורי.
  • הרשאות סביבת עבודה יכולות להסתיר אזור או לאפשר קריאה בלי לאפשר שינויים.
  • אל תעתיקו עובדות משתנות של קטלוג, חשבון או לקוח אל תוכן נרטיבי כפתרון עקיף.
  • בדקו רק יכולות נתמכות שגלויות ומוגדרות עבור החברה הנוכחית.
  • השאירו שינויים בפתרון בעיות פרסום של Helpdesk נפרדים מעבודה לא קשורה ב-Agent, ב-Knowledge, בקטלוג, ב-Inbox או ב-Helpdesk.

אמתו את התוצאה

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

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

פתרון בעיות

המועמד נכון, אבל האתר הציבורי ישן

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

המאמר מופיע בשפה אחת בלבד

בדקו את תרגומי המאמר, את האזורים הלשוניים המופעלים ב-Helpdesk, את שמות התיקיות המקומיים ואת האזור הלשוני המבוקש. אל תפעילו שפה לא שלמה רק כדי לחשוף תוכן בשפת המקור.

מדריכים קשורים

האם המאמר היה מועיל?