תכנון שדות מותאמים אישית ב-CRM Bitrix24 מפתח-עד-מפתח

תכנון שדות מותאמים אישית ב-Bitrix24: היכן נשבר הרישום

כרטיס העסקה חי יותר מהנוהל שלפיו הוא נוצר. תחילה מופיע שדה «הערה למחסן», אחר כך «הערה למחסן (חדש)», אחר כך מישהו מוסיף את זמן האספקה כמחרוזת — ובאותה ישות כבר יש שלושה שדות על אותו דבר.

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

במקביל מתפזר מדריך הערכים: את הערכים מזינים ידנית — «ООО Ромашка», «Ромашка ООО», «ромашка», שלוש רשומות במקום אחת. מדריך ערכים שהתנפח מפסיק לעבוד כמסנן: אי אפשר לקבץ לפיו דוח, והפקה לפי כיוון נותנת מספרים שלא מתאימים לטבלאות שהמנהלים מנהלים אצלם במחשב.

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

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

מה נותנת סכמת מאפיינים אחידה בכרטיסי עסקאות

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

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

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

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

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

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

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

אפשרויות מימוש מדריכים: השוואת גישות

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

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

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

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

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

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

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

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

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

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

מה מוסרים לידיים: קונפיגורציות, סכמות, הוראות

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

מה נכלל בערכה

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

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

מקרה בוחן: כיצד הסירו את ההזנה הידנית בכרטיסי מחלקת המכירות

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

מה שינו

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

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

מדדים לפני ואחרי

• שדות בכרטיס: 34 → 12, זמן המילוי הצטמצם כמעט פי שלושה.
• זמן הטיפול בפנייה: מ-11 דקות ל-4.
• שיעור הפעולות הידניות: מ-58% ל-19%.
• פניות שהוחזרו לתיקון: מ-21% ל-5%.

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

מה לעשות אם ב-Bitrix24 כבר נוצרו מאפיינים משלכם?

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודות

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

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

האם לא יופיעו שני שדות עם אותה משמעות?

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

האם השדה החדש יעבור ל-1C ויחזור בחזרה?

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

האם השדה ישבור דוחות ומשפך קיימים?

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

האם העומס על המחלקה לא יגדל?

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

נדון במשימה ונחזור עם אומדן ותוכנית

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

מה לאסוף מצדכם מראש:

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

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