Skill מאמר מאגר ידע ל-Claude

אם אתם רואים placeholder לא מוכר או צריכים לבדוק אילו כלים מחוברים, ראו CONNECTORS.md.

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

שימוש

/kb-article <בעיה שנפתרה, מספר כרטיסייה, או תיאור נושא>

דוגמאות:

• /kb-article How to configure SSO with Okta — resolved this for 3 customers last month
• /kb-article Ticket #4521 — customer couldn't export data over 10k rows
• /kb-article Common question: how to set up webhook notifications
• /kb-article Known issue: dashboard charts not loading on Safari 16

תהליך עבודה

1. הבנת חומר המקור

נתחו את הקלט לזיהוי:

• מה הייתה הבעיה? הבעיה המקורית, השאלה, או השגיאה
• מה היה הפתרון? ההחלטה, הפתרון העקיף, או התשובה
• מי מושפע? סוג משתמש, רמת תוכנית, או הגדרה
• כמה נפוץ זה? בעיה חד-פעמית או חוזרת
• איזה סוג מאמר מתאים ביותר? how-to, פתרון תקלות, FAQ, בעיה ידועה, או עיון (ראו סוגי מאמרים למטה)

אם ניתנת הפניה לכרטיסייה, חפשו את ההקשר המלא:

• ~~support platform: משכו את שרשרת הכרטיסייה, הפתרון, וכל הערות פנימיות
• ~~knowledge base: בדקו אם מאמר דומה כבר קיים (עדכון מול יצירה חדשה)
• ~~project tracker: בדקו אם יש דוח באג קשור או בקשת תכונה

2. ניסוח המאמר

תוך שימוש במבנה המאמר, תקני עיצוב, ושיטות עבודה מומלצות לחיפוש למטה:

• עקבו אחר התבנית לסוג המאמר הנבחר (how-to, פתרון תקלות, FAQ, בעיה ידועה, או עיון)
• יישמו שיטות עבודה מומלצות לחיפוש: כותרת בשפת הלקוח, משפט פתיחה בשפה פשוטה, הודעות שגיאה מדויקות, מילים נרדפות נפוצות
• שמרו על ניתנות לסריקה: כותרות, שלבים ממוספרים, פסקאות קצרות

3. יצירת המאמר

הציגו את הטיוטה עם מטא-נתונים:

## טיוטת מאמר KB

**כותרת:** [כותרת המאמר]
**סוג:** [How-to / פתרון תקלות / FAQ / בעיה ידועה / עיון]
**קטגוריה:** [תחום מוצר או נושא]
**תגיות:** [תגיות ניתנות לחיפוש]
**קהל יעד:** [כל המשתמשים / מנהלי מערכת / מפתחים / תוכנית ספציפית]

---

[תוכן מאמר מלא — תוך שימוש בתבנית המתאימה למטה]

---

### הערות פרסום
- **מקור:** [כרטיסייה #, שיחת לקוח, או דיון פנימי]
- **מאמרים קיימים לעדכון:** [אם זה חופף עם תוכן קיים]
- **נדרשת סקירה מ:** [מומחה לנושא או צוות אם נדרש אימות דיוק טכני]
- **תאריך סקירה מוצע:** [מתי לחזור לבדיקת הדיוק]

4. הצעת צעדים הבאים

לאחר יצירת המאמר:

• "רוצים שאבדוק אם מאמר דומה כבר קיים ב-~~knowledge base שלכם?"
• "האם להתאים את העומק הטכני עבור קהל יעד אחר?"
• "רוצים שאנסח מאמר מלווה (למשל, how-to שילווה מדריך פתרון תקלות זה)?"
• "האם ליצור גרסה פנימית בלבד עם פרטים טכניים נוספים?"

מבנה מאמר ותקני עיצוב

יסודות מאמר אוניברסליים

כל מאמר KB צריך לכלול:

1. כותרת: ברורה, ניתנת לחיפוש, מתארת את התוצאה או הבעיה (לא ז'רגון פנימי)
2. סקירה כללית: 1-2 משפטים המסבירים מה המאמר מכסה ועבור מי הוא
3. גוף: תוכן מובנה המתאים לסוג המאמר
4. מאמרים קשורים: קישורים לתוכן מלווה רלוונטי
5. מטא-נתונים: קטגוריה, תגיות, קהל יעד, תאריך עדכון אחרון

כללי עיצוב

• השתמשו בכותרות (H2, H3) לפיצול תוכן לחלקים ניתנים לסריקה
• השתמשו ברשימות ממוספרות לשלבים עוקבים
• השתמשו ברשימות נקודות לפריטים לא עוקבים
• השתמשו בטקסט מודגש לשמות רכיבי ממשק, מונחים מרכזיים, והדגשה
• השתמשו בבלוקי קוד לפקודות, קריאות API, הודעות שגיאה, וערכי הגדרה
• השתמשו בטבלאות להשוואות, אפשרויות, או נתוני עיון
• השתמשו בהתראות/הערות לאזהרות, טיפים, והסתייגויות חשובות
• שמרו פסקאות קצרות — מקסימום 2-4 משפטים
• רעיון אחד לכל חלק — אם חלק מכסה שני נושאים, פצלו אותו

כתיבה לחיפוש

מאמרים אינם שימושיים אם לקוחות לא יכולים למצוא אותם. מטבו כל מאמר לחיפוש:

שיטות עבודה מומלצות לכותרות

אופטימיזציה למילות מפתח

• כללו הודעות שגיאה מדויקות — לקוחות מדביקים טקסט שגיאה לחיפוש
• השתמשו בשפת הלקוח, לא בטרמינולוגיה פנימית — "לא יכול להיכנס" ולא "כשל אימות"
• כללו מילים נרדפות נפוצות — "מחק/הסר", "dashboard/דף הבית", "ייצא/הורד"
• הוסיפו ניסוחים חלופיים — טפלו באותה בעיה מזוויות שונות בסקירה הכללית
• תייגו עם תחומי מוצר — ודאו שקטגוריה ותגיות תואמות את אופן חשיבת הלקוחות על המוצר

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

התחילו כל מאמר במשפט שמנסח מחדש את הבעיה או המשימה בשפה פשוטה:

• How-to: "מדריך זה מראה לכם כיצד ל[השיג X]."
• פתרון תקלות: "אם אתם רואים [תסמין], מאמר זה מסביר כיצד לתקן זאת."
• FAQ: "[שאלה בדברי הלקוח]? הנה התשובה."
• בעיה ידועה: "חלק מהמשתמשים חווים [תסמין]. הנה מה שאנחנו יודעים וכיצד לעקוף זאת."

תבניות סוגי מאמרים

מאמרי How-to

מטרה: הוראות שלב אחר שלב להשגת משימה.

מבנה:

# כיצד ל[השיג משימה]

[סקירה כללית — מה המדריך מכסה ומתי תשתמשו בו]

## דרישות מוקדמות
- [מה נדרש לפני התחלה]

## שלבים
### 1. [פעולה]
[הוראה עם פרטים ספציפיים]

### 2. [פעולה]
[הוראה]

## אימות הצלחה
[כיצד לאשר שהשגתם]

## בעיות נפוצות
- [בעיה]: [תיקון]

## מאמרים קשורים
- [קישורים]

שיטות עבודה מומלצות:

• התחילו כל שלב עם פועל
• כללו את הנתיב הספציפי: "עברו אל Settings > Integrations > API Keys"
• ציינו מה המשתמש אמור לראות לאחר כל שלב ("אמורה להופיע באנר אישור ירוק")
• בדקו את השלבים בעצמכם או אמתו מול פתרון כרטיסייה אחרונה

מאמרי פתרון תקלות

מטרה: אבחון ופתרון בעיה ספציפית.

מבנה:

# [תיאור בעיה — מה המשתמש רואה]

## תסמינים
- [מה המשתמש צופה]

## סיבה
[מדוע זה קורה — הסבר קצר בלי ז'רגון]

## פתרון
### אפשרות 1: [תיקון עיקרי]
[שלבים]

### אפשרות 2: [חלופה אם אפשרות 1 לא עובדת]
[שלבים]

## מניעה
[כיצד למנוע זאת בעתיד]

## עדיין נתקלים בבעיות?
[כיצד לקבל עזרה]

שיטות עבודה מומלצות:

• פתחו עם תסמינים, לא סיבות — לקוחות מחפשים את מה שהם רואים
• ספקו מספר פתרונות כאשר אפשרי (התיקון הסביר ביותר קודם)
• כללו חלק "עדיין נתקלים בבעיות?" שמצביע לתמיכה
• אם סיבת השורש מורכבת, שמרו את ההסבר ללקוח פשוט

מאמרי FAQ

מטרה: תשובה מהירה לשאלה נפוצה.

מבנה:

# [שאלה — בדברי הלקוח]

[תשובה ישירה — 1-3 משפטים]

## פרטים
[הקשר נוסף, עדינויות, או הסבר אם נדרש]

## שאלות קשורות
- [קישור ל-FAQ קשור]
- [קישור ל-FAQ קשור]

שיטות עבודה מומלצות:

• ענו על השאלה במשפט הראשון
• שמרו על תמציתיות — אם התשובה צריכה הדרכה, זה how-to, לא FAQ
• קבצו FAQs קשורים וצרו קישורים ביניהם

מאמרי בעיה ידועה

מטרה: תיעוד באג ידוע או מגבלה עם פתרון עקיף.

מבנה:

# [בעיה ידועה]: [תיאור קצר]

**סטטוס:** [חוקרים / פתרון עקיף זמין / תיקון בתהליך / נפתר]
**מושפעים:** [מי/מה מושפע]
**עודכן לאחרונה:** [תאריך]

## תסמינים
[מה משתמשים חווים]

## פתרון עקיף
[שלבים לעקיפת הבעיה, או "אין פתרון עקיף זמין"]

## לוח זמנים לתיקון
[תאריך תיקון משוער או סטטוס נוכחי]

## עדכונים
- [תאריך]: [עדכון]

שיטות עבודה מומלצות:

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

לוח זמנים לסקירה ותחזוקה

בסיסי ידע מתדרדרים ללא תחזוקה. עקבו אחר לוח זמנים זה:

מחזור חיי מאמר

1. טיוטה: נכתב, ממתין לסקירה
2. מפורסם: פעיל וזמין ללקוחות
3. דורש עדכון: מסומן לעדכון (שינוי מוצר, משוב, או גיל)
4. בארכיון: לא רלוונטי עוד אך נשמר לעיון
5. פוטר: הוסר מ-knowledge base

מתי לעדכן מול יצירת חדש

עדכנו קיים כאשר:

• המוצר השתנה ושלבים צריכים רענון
• המאמר ברובו נכון אך חסר פרט
• משוב מצביע שלקוחות מבולבלים מחלק ספציפי
• נמצא פתרון עקיף או פתרון טוב יותר

צרו חדש כאשר:

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

קישור וטקסונומיה של קטגוריות

מבנה קטגוריות

ארגנו מאמרים להיררכיה התואמת את אופן חשיבת הלקוחות:

התחלה מהירה
├── הגדרת חשבון
├── הגדרה ראשונית
└── מדריכי התחלה מהירה

תכונות ו-How-tos
├── [תחום תכונה 1]
├── [תחום תכונה 2]
└── [תחום תכונה 3]

אינטגרציות
├── [אינטגרציה 1]
├── [אינטגרציה 2]
└── עיון API

פתרון תקלות
├── שגיאות נפוצות
├── בעיות ביצועים
└── בעיות ידועות

חיוב וחשבון
├── תוכניות ותמחור
├── שאלות חיוב
└── ניהול חשבון

שיטות עבודה מומלצות לקישור

• קישור מפתרון תקלות ל-how-to: "להוראות הגדרה, ראו [כיצד להגדיר X]"
• קישור מ-how-to לפתרון תקלות: "אם נתקלים בשגיאות, ראו [פתרון תקלות X]"
• קישור מ-FAQ למאמרים מפורטים: "להדרכה מלאה, ראו [מדריך ל-X]"
• קישור מבעיות ידועות לפתרונות עקיפים: שמרו את השרשרת מבעיה לפתרון קצרה
• השתמשו בקישורים יחסיים בתוך ה-KB — הם שורדים שינוי מבנה טוב יותר מ-URLs מוחלטים
• הימנעו מקישורים מעגליים — אם A מקשר ל-B, B לא צריך לקשר חזרה ל-A אלא אם שניהם נקודות כניסה שימושיות באמת

שיטות עבודה מומלצות לכתיבת KB

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