עד כמה באמת אפשר להתאים אישית את Chatwoot (Self-Hosted)

עד כמה באמת אפשר להתאים את Chatwoot כשמריצים אותו על שרת משלכם (Self-Hosted)? כמעט בלי גבול. אפשר לעצב ולתכנת מחדש את חלון הצ’אט (ה-Widget) שרואים באתר, להחליף את כל המיתוג של המוצר בשלכם (White-Label), להוסיף מסכים משלכם ממש בתוך המסך של הנציג, ולחבר הכל למערכות אחרות דרך שני ‘שערים’ (שנקראים API) והתראות אוטומטיות (Webhooks). אפשר גם לשלוף מידע ישירות מהמאגר, וכיוון שהתוכנה בקוד פתוח — אפילו לשנות את הקוד עצמו ולהחזיק גרסה משלכם (fork). לעומת זאת, בגרסה שהספק מנהל (Chatwoot Cloud), אתם יכולים להתאים רק את מה שהספק בחר לפתוח בפניכם.

רוב ההשוואות בין “מערכות לשירות לקוחות” מסתיימות באותה נקודה: אתם בוחרים תוכנה שהספק מנהל בשבילכם (SaaS — כלומר משלמים דמי שימוש חודשיים והוא דואג לכל השאר), מקבלים את המגבלות שלה, ומשלמים סכום קבוע על כל נציג — לתמיד. כאן זה עובד אחרת. ברגע שאתם מריצים את Chatwoot על השרת שלכם, השאלה “מה אפשר להתאים” מפסיקה להיות “אילו כפתורים הספק הסכים לתת לי” והופכת ל”מה הצוות שלי באמת צריך”. אני מריץ את המערכת הזאת אצל לקוחות אמיתיים מספיק זמן כדי לדעת בדיוק איפה עובר הגבול — אז הנה המפה הכנה של כמה רחוק אפשר לקחת את זה.

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

במערכת סגורה שהספק מנהל (SaaS), הגבול של מה שתוכלו לשנות הוא מה שהספק שם בדף ההגדרות. ב-Chatwoot שרץ על השרת שלכם, הגבול הוא פשוט מה שאתם מסוגלים לבנות — וכל ההבדל הזה הוא בעצם כל המאמר.

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

1. התאמת ה-Widget

חלון הצ’אט החי שרואים באתר (ה-Widget) הוא הדבר הכי גלוי לעין מכל המערכת, והוא גם הכי קל להתאמה. כדי לשים אותו באתר, מדביקים קטע קוד קטן של Chatwoot (מה שנקרא SDK — פשוט חבילת קוד מוכנה שמחברת את הצ’אט לאתר), ולפניו שמים רשימת הגדרות שקובעת איך הצ’אט ייראה ויתנהג. חשוב: את רשימת ההגדרות הזאת חייבים לשים לפני קטע הקוד עצמו. ככה זה נראה בפועל:

<script>
  window.chatwootSettings = {
    locale: "he",            // any locale Chatwoot ships, e.g. "en", "ar", "fr"
    position: "right",       // "left" or "right"
    type: "expanded_bubble", // "standard" or "expanded_bubble"
    launcherTitle: "דברו איתנו",
    darkMode: "auto",        // "light" or "auto"
  };

  (function (d, t) {
    var BASE_URL = "https://app.chatwoot.com"; // your self-hosted URL
    var g = d.createElement(t), s = d.getElementsByTagName(t)[0];
    g.src = BASE_URL + "/packs/js/sdk.js";
    g.defer = true; g.async = true;
    s.parentNode.insertBefore(g, s);
    g.onload = function () {
      window.chatwootSDK.run({
        websiteToken: "YOUR_WEBSITE_TOKEN",
        baseUrl: BASE_URL,
      });
    };
  })(document, "script");
</script>

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

// Identify the logged-in user so conversations attach to the right contact
window.$chatwoot.setUser("USER_IDENTIFIER", {
  name: "Jane Doe",
  email: "jane@example.com",
});

// Attach structured context that shows up on the agent side
window.$chatwoot.setCustomAttributes({
  plan: "business",
  signup_date: "2026-01-15",
});

// Route or segment by setting a conversation label
window.$chatwoot.setLabel("vip");

// Switch locale at runtime (e.g. when the user changes site language)
window.$chatwoot.setLocale("he");

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

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

2. White-Label / מיתוג מחדש

זו הדוגמה הכי נקייה למשהו שאפשר לעשות רק כשמריצים אצלכם. כדי להחליף את המיתוג, Chatwoot נותן כמה הגדרות פשוטות שממלאים בהן את הפרטים שלכם (בעולם הטכני קוראים להן “משתני סביבה”, אבל בפועל זו פשוט רשימה של ערכים שהמערכת קוראת בהפעלה):

# Replaces the product name across the dashboard and system emails
INSTALLATION_NAME="Acme Support"

# Brand name + URL used in branding references
BRAND_NAME="Acme"
BRAND_URL="https://acme.example.com"

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

וכדי לדייק לגבי הגבול: החלפת מיתוג מלאה אפשרית רק כשמריצים את המערכת אצלכם. בגרסה שהספק מנהל (Chatwoot Cloud) המיתוג שלו נשאר — וזה הוגן, זו הרי הגרסה שהוא מארח ומתחזק בשבילכם. אבל אם החלפת מיתוג מלאה (White-Label) היא דרישה שאתם חייבים — הדרישה הזאת לבדה כבר מכריעה את הכף לטובת הרצה על שרת משלכם.

3. שלושת ה-APIs של Chatwoot: Application, Client ו-Platform

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

Application APIs are designed for interacting with a Chatwoot account from an agent/admin perspective. Client APIs are intended for building custom messaging experiences over Chatwoot. Platform APIs are used to manage Chatwoot installations at the admin level.

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

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

curl -X POST \
  "https://app.chatwoot.com/api/v1/accounts/{account_id}/conversations/{conversation_id}/messages" \
  -H "api_access_token: USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Thanks for reaching out — an agent will be with you shortly.",
    "message_type": "outgoing"
  }'

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

curl -X POST "https://app.chatwoot.com/platform/api/v1/accounts" \
  -H "api_access_token: PLATFORM_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "New Client Workspace" }'

דרך קלה לזכור את ההבדל: ה-Application API הוא לעבוד בתוך חשבון; ה-Platform API הוא לנהל את החשבונות עצמם. רוב האוטומציה של היומיום מתרחשת ב-Application API. ה-Platform API הוא השכבה שמנהלת הרבה לקוחות יחד — ועצם קיומו הוא חלק מהסיבה ש-Chatwoot יכול לגדול מ”תיבת פניות אחת” ל”מערכת שלמה שאתם מריצים בשביל המון לקוחות”. שני השערים האלה מתועדים אצל Chatwoot פעולה אחר פעולה, ב-Chatwoot API reference.

4. Webhooks ואוטומציה

ההתראות האוטומטיות (Webhooks) הן עמוד השדרה של החיבור בין המערכות. הרעיון פשוט: בכל פעם שקורה משהו ב-Chatwoot, הוא שולח על כך הודעה אוטומטית לכתובת אינטרנט שאתם קובעים מראש. Chatwoot יודע לשלוח התראה כזאת על שלל אירועים בחשבון — נפתחה שיחה (conversation_created), נכנסה הודעה (message_created), שיחה שינתה סטטוס (conversation_status_changed), שיחה התעדכנה (conversation_updated) ועוד — לכל כתובת שתירשמו. זה הוו שדרכו מערכות חיצוניות יכולות להגיב בזמן אמת למה שקורה בתיבת הפניות.

השיטה שאני משתמש בה כל הזמן היא מעגל קטן: מ-Chatwoot אל n8n, ומ-n8n בחזרה אל Chatwoot. ככה זה עובד שלב-שלב:

1. ברגע שנכנסת הודעה חדשה, Chatwoot שולח על כך התראה אוטומטית ל-n8n (זהו ה-message_created), ו-n8n קולט אותה.
2. n8n מקבל יחד עם ההתראה את כל פרטי ההודעה — מי שלח, מה נכתב, לאיזו שיחה ולאיזו תיבה זה שייך — ומריץ עליהם כל דבר שהלקוח צריך: להבין מה הלקוח רוצה, לחפש אותו במערכת ניהול הלקוחות (CRM), או לשלוח את השאלה למודל AI שיענה.
3. לבסוף, n8n חוזר ומדבר עם Chatwoot דרך ה-Application API — כדי לשלוח את התשובה, להצמיד תווית, או לעדכן פרט על איש הקשר.

המעגל הקטן הזה הוא בדיוק האופן שבו בונים מענה ראשוני אוטומטי מבוסס AI, סנכרון מלא עם מערכת ניהול לקוחות (CRM), או כלל ניתוב חכם הרבה יותר מכל מה שדף הגדרות רגיל מציע — והכל בלי “אפליקציה” מיוחדת מהספק. וכיוון שמדובר פשוט בהתראות אוטומטיות (Webhooks) ובשפה תקנית שבה תוכנות מדברות זו עם זו (REST) — אותה שיטה בדיוק מחברת את Chatwoot ל-n8n, ל-Make, לשרת שלכם, או לכל השלושה ביחד. אם בא לכם לראות דוגמה חיה של AI שרץ מעל Chatwoot, המדריך לבוט שירות לקוחות עוסק בתכנון השיחה, המדריך המלא לאוטומציה עסקית מראה איפה שכבת התמיכה משתלבת בתוך תמונה גדולה יותר, והמדריך המלא ל-n8n מסביר גם איך מריצים את מנוע האוטומציה עצמו על התשתית שלכם.

Automation Rules ו-Macros (ללא קוד)

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

• חוקי אוטומציה (Automation Rules) — כללים בסגנון אם קורה כך, עשה כך, שמגדירים ישירות מתוך לוח הבקרה. למשל, ברגע שנפתחת שיחה חדשה אפשר לשייך אותה אוטומטית לצוות המתאים, להצמיד לה תווית, לשלוח תשובה מוכנה מראש, או לסמן פרט מסוים — הכל לפי תנאים שאתם קובעים, ובלי לכתוב שורת קוד אחת.
• מאקרו (Macros) — רצף פעולות שמור מראש, שהנציג מפעיל בלחיצה אחת (למשל: “שלח את הודעת ההחזר הכספי, סמן את השיחה כ-billing, וסגור אותה”). מושלם לטיפולים חוזרים שיש בהם כמה שלבים.

כלל אצבע פשוט: לתהליכים שמתרחשים בתוך המערכת עצמה — השתמשו בחוקי האוטומציה ובמאקרו; וכשאתם צריכים מידע ממערכת חיצונית או לוגיקה מורכבת באמת — פנו להתראות האוטומטיות (Webhooks) ולשערי החיבור (API).

5. אינטגרציות מותאמות ו-Dashboard Apps

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

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

// Inside your embedded dashboard app
window.addEventListener("message", function (event) {
  // Chatwoot posts the conversation + contact context here
  try {
    var data = JSON.parse(event.data);
    if (data.event === "appContext") {
      // data.data.conversation and data.data.contact are available
      renderCustomerPanel(data.data);
    }
  } catch (e) {
    /* ignore non-Chatwoot messages */
  }
});

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

6. למה Self-Hosted פותח את מה ש-Cloud/SaaS לא יכול

כל זה בכלל אפשרי מסיבה אחת: Chatwoot היא תוכנת קוד פתוח אמיתית — 33,000+ כוכבים ב-GitHub, 7,900+ forks, ורישיון MIT (chatwoot/chatwoot). רישיון ה-MIT הזה (סוג של אישור חוקי מאוד מתירני) הוא מה שנותן לכם לקרוא את הקוד, לתקן אותו, ולבנות ממנו גרסה משלכם — בלי לבקש רשות מאף אחד. הגרסה שהספק מנהל (Chatwoot Cloud), לעומת זאת, היא שירות מנוהל שעולה $0 לנציג בחודש בחבילה החינמית ועד $99 לנציג בחודש בחבילת ה-Enterprise — נוח מאוד, אבל גבול ההתאמה שלכם הוא מה שהספק בחר לפתוח. (להשוואת יכולות מפורטת מול מתחרה מנוהל, ראו Chatwoot מול Intercom.)

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

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

• שליפת מידע ישירה מהמאגר. Chatwoot שומר את כל המידע במאגר בשם PostgreSQL (מאגר מידע מקצועי ובקוד פתוח). כשאתם רוצים דוחות מעבר למה שלוח הבקרה מציע מוכן, אתם יכולים לשלוף את הנתונים ישירות מהמאגר או לחבר אותו לכלי גרפים וניתוח (BI). מערכת סגורה, לעומת זאת, תיתן לכם רק את מה שמסך הייצוא שלה מאפשר.
• שינוי קוד וגרסה משלכם. זו תוכנת קוד פתוח. אם משהו לא מתנהג כמו שאתם רוצים — אתם יכולים לשנות אותו ולהריץ גרסה משלכם שערכתם (fork). התיקונים הקטנים של הטקסטים והאייקון שסיפרתי עליהם למעלה הם בדיוק דוגמה לזה — שינויים קטנים וממוקדים, שבמערכת מנוהלת פשוט בלתי אפשריים.
• בלי המגבלות של הספק על התקשורת. כשמריצים אצלכם, הדבר היחיד שמגביל את קצב התקשורת עם המערכת (ה-API) הוא כוח השרת שלכם — ולא תקרה מלאכותית שהספק קובע. סנכרונים כבדים ובוטים שמטפלים בהמון פניות לא נחסמים באמצע כי “עברתם את המכסה של החבילה”.
• חיבור ערוצים משלכם. מעבר לערוצים המובנים, יש ב-Chatwoot דבר שנקרא API channel, שמאפשר להזרים הודעות מכל מקור שתרצו אל תוך תיבת Chatwoot ולשלוח תשובות בחזרה — כך שאפילו מערכת הודעות ביתית שבניתם הופכת פשוט לעוד תיבה בתוך Chatwoot. באותה דרך בדיוק גם מספר WhatsApp Business API מתחבר ל-Chatwoot כערוץ לכל דבר.
• החלפת מיתוג מלאה. כמו שכבר הסברנו למעלה — המותג שלכם, מההתחלה ועד הסוף.
• בעלות ושליטה על המידע. כל שיחה נשמרת על תשתית שאתם בחרתם. בענפים מפוקחים או במקומות עם דרישות מחמירות להגנה על מידע, זה לרוב תנאי שאי אפשר להתפשר עליו.

שום דבר מכל זה הוא לא ביקורת על מערכות מנוהלות. זה פשוט תיאור של שתי עסקאות שונות: הגרסה המנוהלת (Cloud) נותנת לכם אפס תחזוקה בתמורה לפחות גמישות; הגרסה שרצה אצלכם (Self-Hosted) נותנת לכם שליטה מלאה בתמורה לכך שהתחזוקה על הכתפיים שלכם. איזו מהן “הנכונה” תלוי לגמרי בשאלה אחת: האם ההתאמות שדיברנו עליהן הן בשבילכם “נחמד שיהיה”, או דרישה של ממש.

מילה מציאותית של זהירות

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

כל גרסה משלכם שאתם מתחזקים (fork) היא עוד דבר שתצטרכו לבדוק מחדש בכל עדכון, וכל התראה אוטומטית (Webhook) היא עוד דבר שעלול להתקלקל בשתיים בלילה. מה שהופך את Chatwoot שרץ אצלכם למשתלם באמת זו דווקא היכולת להתאפק — לא לשנות כל דבר רק כי אפשר.

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

על הכותב

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

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

ואם דווקא הגרסה המנוהלת (Cloud) מתאימה לכם יותר, נרשמים כאן ל-5% הנחה עם הקוד ACHIYACUST (קישור שותפים). שני המסלולים טובים — העיקר לבחור את זה שמתאים לצורך האמיתי שלכם, ולא את זה שנועל אתכם פנימה.