# כמה שדות מותאמים ב-CRM זה יותר מדי?

> כמה שדות מותאמים ב-CRM הם יותר מדי? המכסות של Zoho, בדיקה של מי משתמש בכל שדה, ההבדל בין הסרה למחיקה, וקיצור טפסים ב-Monday וב-Zoho.

- כתובת העמוד: https://crmers.co.il/crm-too-many-custom-fields/
- פורסם: 2026-10-14
- מאת: צוות Crmers
- חלק מהמדריך: [הטמעת CRM: מהאפיון ועד אחרי העלייה לאוויר](https://crmers.co.il/crm-implementation-guide/)

כמה שדות מותאמים אפשר להוסיף לכרטיס לקוח ב-CRM לפני שזה מתחיל להפריע לעבודה? המערכת עצמה תעצור אתכם רק מאוחר מאוד: ב-Zoho CRM, במהדורה הגבוהה, המכסה מגיעה ל-500 שדות מותאמים לכל מודול. מה בודקים לפני שמוסיפים שדה חדש פירטנו [במאמר על שלוש שאלות שמונעות עומס על הצוות](https://crmers.co.il/crm-questions-prevent-overload/).

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

## יש מספר מקסימלי של שדות מותאמים ב-CRM?

ב-Zoho CRM יש תקרה, והיא תלויה במהדורה. לפי טבלת השוואת המהדורות של Zoho, מכסת השדות המותאמים, כולל כל סוגי השדות, היא 10 לכל מודול במהדורת Standard, 155 ב-Professional, 300 ב-Enterprise ו-500 ב-Ultimate. במודול הפעילויות המכסה נמוכה יותר: 140 ב-Professional ו-230 ב-Enterprise וב-Ultimate. במהדורה החינמית אין שדות מותאמים בכלל.

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

## איך יודעים שעברתם את הגבול של שדות מותאמים?

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

ג'ארט כותבת על טפסים באתרים, וההקבלה ל-CRM היא המסקנה שלנו: ערכים סתמיים בשדות חובה ושדות שנשארו מגרסה קודמת של המערכת הם אותם שני סימנים בכרטיס לקוח. גם מבנה שדות שלא תואם את העבודה מחייב סידור מחדש: אצל [נטלי שירותי רפואה](https://crmers.co.il/case-studies/natali/), שהקימה את Zoho CRM בעצמה, מבנה הנתונים לא היה נכון, והפרויקט התחיל בארגון מחדש של מבנה המידע ושל השדות, כך שיתאימו לאופן שבו החברה עובדת בפועל.

## בדיקת שדות מותאמים קיימים: מי עדיין משתמש בכל שדה?

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

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

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

ג'ארט מסייגת שבארגון קטן, עם טופס קצר, שבו מוסיפים ומוחקים שדות בלי פגישות, כנראה אין צורך בפרוטוקול, ועדיף לערוך בדיקות שימושיות ולשנות את הטופס לפי הממצאים. בארגון שבו שדות נוספו לבקשת כמה מחלקות, ההמלצה שלנו היא שהבעלים של ה-CRM ימלא את הטבלה עם נציג של כל מחלקה ויחליט לפיה. הטבלה הזאת היא גם הבסיס [למילון שדות אחיד](https://crmers.co.il/crm-field-dictionary-import/).

## הסרה או מחיקה של שדה מותאם ב-Zoho CRM: מה קורה לנתונים?

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

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

שדה שנחוץ רק לצוות אחד לא חייב לרדת מהמערכת. מרכז העזרה מתאר הרשאות גישה לשדה: מסתירים אותו ממשתמשים בפרופיל מסוים, או מסמנים אותו לקריאה בלבד. ההרשאות האלה זמינות ממהדורת Professional ומעלה. על חלוקת הגישה בין צוותים כתבנו [במדריך להרשאות ב-CRM בלי לחסום עבודה](https://crmers.co.il/crm-permissions-without-blocking-work/).

במרכז העזרה מוסבר שיצירת שדות פתוחה למשתמשים שבפרופיל שלהם יש הרשאה להתאמה אישית של Zoho CRM. כדאי לתת את ההרשאה הזאת לבעלים של ה-CRM בלבד.

## איך מקצרים טופס עם הרבה שדות מותאמים ב-Zoho וב-Monday?

כדי להציג שדה רק כשהוא רלוונטי, משתמשים ב-Zoho CRM בכללי פריסה (Layout Rules). לפי מרכז העזרה, כלל כזה מציג או מסתיר שדות, סעיפים וטפסי משנה לפי תנאים על ערכי שדות, ויכול גם להפוך שדה לחובה רק כשהתנאי מתקיים. בדוגמה שם, בפריסה של בקשת הלוואה, סעיף הערכת האשראי מוצג רק כשסטטוס הבקשה הוא טיוטה. אפשר גם להגביל כלל לפרופילים מסוימים, כך שאותו מודול יתנהג אחרת אצל כל צוות.

לפני שמסתמכים על כללי פריסה, בדקו שלוש מגבלות. לפי טבלת המהדורות הם זמינים רק ב-Enterprise וב-Ultimate, עד 10 כללים לכל פריסה. הם לא פועלים על רשומות שנוצרות בייבוא, בטפסי אינטרנט או בדף המרת הליד, וביצירה או עריכה דרך ממשק תכנות (API) נתמכת רק הפעולה שהופכת שדה לחובה. וכשתהליך אוטומטי או API מעדכנים שדה שהכלל מבוסס עליו, העדכון גובר על הכלל: בדוגמה של מרכז העזרה, כלל שמחייב כתובת מייל כשמקור הליד הוא תערוכה לא יפעל אם המקור עודכן כך באוטומציה, והמייל יישאר ריק. אצל נטלי, לידים מכמה ספקים חיצוניים נכנסים ל-Zoho CRM דרך Make בלי שאיש מקליד אותם. המסקנה שלנו: כשרשומות נוצרות ומתעדכנות אוטומטית, אי אפשר לסמוך רק על כלל פריסה כדי לחייב שדה שצריך להיות מלא בכל ליד.

ב-monday CRM, לפי מרכז התמיכה של monday.com, הכלי המקביל הוא טופס יצירת הפריט: חלון קופץ שמופיע כשחבר צוות מוסיף פריט חדש ללוח באופן ידני. בעלי הלוח בוחרים אילו שדות יופיעו בו, אילו מהם יהיו חובה ובאיזה סדר, למשל השדות הקריטיים בראש. אפשר לסמן שדה כחובה רק אם הוא מוצג בטופס, ושדה מוסתר לא יכול להיות חובה. הסתרה של שדה בטופס לא מסתירה את העמודה בלוח או בטפסים שמחוברים אליו, ולכן העמודה והנתונים שלה נשארים. הטופס זמין בתוכניות Basic, Standard, Pro ו-Ultimate של monday CRM, ורק בעלי הלוח יכולים לערוך אותו.

## שדות חובה מותאמים: איך דורשים מידע רק בשלב שבו הוא נחוץ?

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

כללי אימות נתונים זמינים גם ב-monday CRM, בתוכניות Pro ו-Enterprise. כלל מותנה בנוי כ"אם, אז": אפשר לדרוש שתנאי בעמודה אחת יתקיים לפני שמעדכנים עמודה אחרת. אחת הדוגמאות של מרכז התמיכה היא למנוע מעסקה לעבור לסטטוס זכייה אם רמת הסיכון שלה אינה בינונית או נמוכה. הכללים נאכפים בלוחות, בטפסים, באוטומציות ובאינטגרציות, בדשבורדים, במובייל וב-API, ובכל לוח אפשר להגדיר עד 50 כללים. גם הם חלים רק מכאן והלאה: פריטים קיימים לא מושפעים עד שהערך שלהם יימחק ויוזן מחדש, ופריט שלא עומד בכלל לא ניתן לשכפול, להעברה או להמרה.

כמו בדוגמה של רמת הסיכון לפני זכייה, כדאי לדרוש את השדה שנחוץ רק בשלב מאוחר של העסקה בכלל מותנה שחל רק באותו שלב. מכיוון שעמודות חובה עלולות לשבש אוטומציות ואינטגרציות שיוצרות פריטים, בדקו אותן אחרי כל שינוי כזה. ב-Zoho המקבילה היא כלל פריסה שהופך שדה לחובה בתנאי, עם המגבלות שתיארנו. על הבחירה אילו שדות ראויים בכלל להיות חובה כתבנו [במאמר על שדה אחד שמשנה החלטות ניהוליות](https://crmers.co.il/critical-crm-field-decisions/).

## שדות מותאמים עם מידע אישי: מה תקנות אבטחת המידע מחייבות לבדוק?

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

טבלת הפרוטוקול מספקת חלק מהמידע שהתקנות דורשות, כי היא מראה לאיזו מטרה כל שדה משמש ומי צריך אותו. ב-Zoho CRM אפשר לסמן עד 30 שדות בכל מודול כמידע אישי, בכל המהדורות. זה תיאור עובדתי של התקנות ולא ייעוץ משפטי: את מה שנדרש מכם בפועל בדקו עם עורך דין, ועוד פרטים תמצאו [במאמר על תיקון 13 לחוק הגנת הפרטיות](https://crmers.co.il/crm-privacy-law-israel/).

## עוד מהבלוג

- [מסמכים וקבצים במעבר CRM: איך שומרים על הקישור לרשומה?](https://crmers.co.il/crm-documents-migration/)
- [CRM ללקוחות בחו״ל: איך מגדירים מטבע, אזורי זמן ושפה?](https://crmers.co.il/crm-multilingual-customers/)
- [עומס על צוות שירות: איך מודדים אותו מעבר למספר הקריאות?](https://crmers.co.il/crm-service-team-capacity/)

---

Crmers: אפיון והטמעה של מערכות CRM ומערכות מידע · [072-372-7806](tel:+972723727806) · [office@crmers.co.il](mailto:office@crmers.co.il) · [יצירת קשר](https://crmers.co.il/contact/) · [הנחיות לסוכני AI](https://crmers.co.il/agents.md)