Company hierarchy σε CRM: μητρικές, θυγατρικές και B2B accounts χωρίς διπλή εικόνα
Στις B2B πωλήσεις, «ο πελάτης» δεν είναι πάντα μία εταιρεία με μία διεύθυνση. Ένας όμιλος μπορεί να έχει μητρική, θυγατρικές, υποκαταστήματα, διαφορετικά ΑΦΜ και ξεχωριστές ομάδες προμηθειών. Αν όλα μπουν σε μία εγγραφή, χάνονται οι διαφορές. Αν δημιουργηθούν ανεξάρτητες εγγραφές χωρίς σύνδεση, η ομάδα δεν βλέπει τη συνολική σχέση.
Η company hierarchy στο CRM οργανώνει αυτές τις εταιρείες ως συνδεδεμένα αλλά διακριτά accounts. Στόχος δεν είναι να αναπαραστήσει ολόκληρη τη νομική δομή του κόσμου. Στόχος είναι να δώσει σε πωλήσεις, support και διοίκηση τη σωστή εικόνα για τη συγκεκριμένη επιχειρησιακή απόφαση.
Πότε χρειάζεται ιεραρχία εταιρειών
Η λειτουργία γίνεται σημαντική όταν μία εμπορική σχέση περιλαμβάνει περισσότερες νομικές οντότητες ή τοποθεσίες. Παραδείγματα:
- ένας όμιλος με κεντρική συμφωνία και τοπικές θυγατρικές
- αλυσίδα με καταστήματα που παραγγέλνουν ξεχωριστά
- franchise με κοινό brand αλλά ανεξάρτητους ιδιοκτήτες
- εταιρεία με διαφορετικά billing και service entities
- δημόσιος οργανισμός με διευθύνσεις και περιφερειακές μονάδες
- πελάτης όπου η μητρική αποφασίζει, αλλά η θυγατρική χρησιμοποιεί την υπηρεσία
Χωρίς hierarchy, οι πωλητές μπορεί να προσεγγίζουν θυγατρική που ήδη καλύπτεται από εταιρική σύμβαση ή να δίνουν ασύμβατες τιμές σε δύο μέρη του ίδιου ομίλου.
Parent-child σχέση και association labels
Το απλούστερο μοντέλο έχει μία parent company και πολλές child companies. Η επίσημη τεκμηρίωση του HubSpot περιγράφει ακριβώς αυτή τη δομή: μία μητρική μπορεί να έχει πολλές θυγατρικές, ενώ μία θυγατρική συνδέεται με μία μητρική στο συγκεκριμένο default relationship.
Σε custom CRM χρειάζεται να αποφασιστεί αν αυτό αρκεί. Μια εταιρεία μπορεί να έχει περισσότερους τύπους σχέσης: subsidiary of, branch of, franchise of, billing managed by ή reseller for. Δεν είναι όλες ιεραρχικές και δεν πρέπει να συμπιεστούν σε ένα γενικό parent-child. Τα association labels βοηθούν να εκφραστεί το νόημα της σύνδεσης.
Το data model χρειάζεται επίσης προστασία από κύκλους. Η Α δεν μπορεί να είναι parent της Β ενώ η Β είναι ancestor της Α. Οι μετακινήσεις μέσα στην ιεραρχία πρέπει να ελέγχονται σε transaction και να αφήνουν audit trail.
Τι ανήκει στην εταιρεία και τι κληρονομείται
Κάθε νομική οντότητα κρατά δικά της στοιχεία: επωνυμία, ΑΦΜ, διεύθυνση τιμολόγησης, συμβάσεις, contacts, deals και tickets. Η μητρική δεν πρέπει να αντικαθιστά αυτά τα δεδομένα. Η hierarchy προσθέτει συγκεντρωτική προβολή, όχι συγχώνευση εγγραφών.
Ορισμένες πολιτικές μπορούν να κληρονομούνται, αλλά μόνο ρητά. Για παράδειγμα:
- κοινός τιμοκατάλογος με δυνατότητα τοπικής εξαίρεσης
- κεντρικός account owner και τοπικός υπεύθυνος
- όριο πίστωσης σε επίπεδο ομίλου ή ξεχωριστά ανά ΑΦΜ
- κοινή σύμβαση με διαφορετικά service entitlements
- permissions που δίνουν σε group manager πρόσβαση στις θυγατρικές
Η κληρονομικότητα πρέπει να δείχνει πηγή και override. Ένα πεδίο «τιμοκατάλογος Β» χωρίς ένδειξη αν ορίστηκε τοπικά ή ήρθε από τη μητρική δημιουργεί δύσκολα λάθη.
Contacts και ρόλοι μέσα στον όμιλο
Ένα contact μπορεί να εργάζεται για μία θυγατρική αλλά να αποφασίζει για ολόκληρο τον όμιλο. Το CRM δεν πρέπει να αντιγράφει το ίδιο άτομο σε κάθε εταιρεία. Χρειάζεται μία επαφή με πολλαπλές associations και ρόλους, όπως decision maker για τον όμιλο, billing contact για δύο entities και user σε μία θυγατρική.
Οι ρόλοι είναι διαφορετικοί από το job title. Το «CFO» δεν λέει αυτόματα σε ποιες εταιρείες εγκρίνει αγορές. Η association ανάμεσα σε contact και company πρέπει να μπορεί να περιγράψει scope και ισχύ.
Κατά την αποστολή email ή την ανάθεση task, η εφαρμογή πρέπει να γνωρίζει ποιο account context χρησιμοποιείται. Έτσι αποφεύγεται να σταλεί σε κεντρικό contact πληροφορία που αφορά μόνο άλλη θυγατρική.
Deals, pipeline και συνολική έκθεση
Κάθε deal συνδέεται με τη νομική οντότητα που αγοράζει ή υπογράφει. Προαιρετικά συνδέεται και με ultimate parent για reporting. Το ποσό δεν πρέπει να αντιγράφεται και στα δύο accounts, γιατί τότε διπλασιάζεται το pipeline.
Η συγκεντρωτική προβολή του ομίλου υπολογίζει rollups από τις θυγατρικές: ανοικτό pipeline, κλεισμένα έσοδα, tickets και ληξιπρόθεσμες υποχρεώσεις. Οι υπολογισμοί χρειάζονται σαφή χρονικό διάστημα, νόμισμα και κανόνα αποφυγής διπλομέτρησης.
Για forecast, η ομάδα μπορεί να φιλτράρει είτε ανά owning entity είτε ανά corporate group. Αυτές είναι διαφορετικές ερωτήσεις και πρέπει να εμφανίζονται με διαφορετικές διαστάσεις στο reporting.
Deduplication χωρίς λάθος συγχώνευση
Παρόμοια domains ή επωνυμίες δεν σημαίνουν απαραίτητα duplicate. Οι θυγατρικές μπορεί να χρησιμοποιούν το ίδιο email domain αλλά να είναι διακριτές εταιρείες. Αντίστροφα, ένα υποκατάστημα μπορεί να έχει διαφορετική εμπορική ονομασία αλλά να ανήκει στην ίδια νομική οντότητα.
Οι κανόνες deduplication πρέπει να εξετάζουν ΑΦΜ, registration number, domain, χώρα και ρητές associations. Μια πιθανή αντιστοιχία παρουσιάζεται για έλεγχο αντί να συγχωνεύεται αυτόματα. Το merge είναι διαφορετική ενέργεια από τη δημιουργία parent-child σχέσης.
Σε imports, οι parent records πρέπει να υπάρχουν ή να αναγνωρίζονται με σταθερό external ID. Η HubSpot τεκμηριώνει bulk association με Record ID ή company domain, αλλά σε πολυεθνικά και σύνθετα δεδομένα ένα μοναδικό εσωτερικό ID είναι συνήθως ασφαλέστερο από το domain μόνο.
Permissions και απομόνωση δεδομένων
Η hierarchy δεν πρέπει να παρακάμπτει τα permissions. Το ότι ένας χρήστης βλέπει τη μητρική δεν σημαίνει αυτόματα ότι δικαιούται όλα τα δεδομένα κάθε θυγατρικής. Σε άλλα σενάρια, ένας global account manager χρειάζεται πράγματι πρόσβαση σε ολόκληρο το subtree.
Η πολιτική μπορεί να βασίζεται σε ownership, team, territory και association type. Κάθε query και export πρέπει να εφαρμόζει τους ίδιους κανόνες, όχι μόνο η κύρια οθόνη. Ιδιαίτερη προσοχή χρειάζεται στα rollups: ένας αριθμός ομίλου μπορεί έμμεσα να αποκαλύπτει δεδομένα εταιρείας που ο χρήστης δεν επιτρέπεται να δει.
UX που βοηθά την ομάδα να καταλάβει τη σχέση
Μια καλή σελίδα account δείχνει breadcrumb προς τη μητρική, άμεσα παιδιά και συνοπτικό tree. Δεν φορτώνει ολόκληρο πολυεπίπεδο όμιλο κάθε φορά. Ο χρήστης μπορεί να αλλάξει context και βλέπει καθαρά αν εργάζεται σε τοπική εταιρεία ή σε group view.
Οι κρίσιμες ενέργειες εμφανίζουν scope: «δημιουργία συμφωνίας για τη θυγατρική Α» ή «εφαρμογή τιμοκαταλόγου σε όλες τις θυγατρικές». Οι bulk αλλαγές χρειάζονται preview, permissions και audit log.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry ξεκινάμε από το πώς λειτουργούν πραγματικά οι πωλήσεις και οι συμβάσεις της επιχείρησης. Διαχωρίζουμε νομική οντότητα, εμπορικό account, location και corporate group, ώστε το CRM να μην προσπαθεί να λύσει διαφορετικές ανάγκες με μία εγγραφή.
Στα custom CRM και B2B portals που αναπτύσσουμε, υλοποιούμε typed associations, έλεγχο κύκλων, explicit inheritance και rollups χωρίς διπλομέτρηση. Συνδέουμε hierarchy με permissions, account ownership, pricing και reporting, ενώ το UI δείχνει πάντα το ενεργό scope. Δίνουμε επίσης ασφαλή εργαλεία import και reconciliation για να καθαριστούν υπάρχοντα δεδομένα χωρίς αυθαίρετα merges.
Checklist για σωστή company hierarchy
- Είναι σαφές τι σημαίνει parent, child, branch και franchise;
- Παραμένει κάθε νομική οντότητα ξεχωριστή εγγραφή;
- Φαίνεται ποια πεδία κληρονομούνται και ποια έχουν override;
- Συνδέονται contacts με ρόλο και scope χωρίς αντίγραφα;
- Τα deals μετρώνται μία φορά στο pipeline;
- Αποτρέπονται κύκλοι και λανθασμένα bulk updates;
- Εφαρμόζονται permissions και στα rollups και exports;
- Ξεχωρίζει το merge από τη δημιουργία εταιρικής σχέσης;
Η σωστή ιεραρχία δεν είναι διακοσμητικό οργανόγραμμα. Είναι ο μηχανισμός που επιτρέπει στην ομάδα να βλέπει ταυτόχρονα τη λεπτομέρεια κάθε εταιρείας και τη συνολική αξία της σχέσης με τον όμιλο.