When a subsidiary agency moves to a new parent company, most systems quietly reprice it to match. This CRM freezes its negotiated terms the moment it moves.
A national subsidiary of a large travel agency network gets reorganized under a different regional parent. Nothing about the commercial relationship with the hotel group actually changed, the same rooms, the same rate the two sides spent months negotiating, but in a lot of systems that reorg alone is enough to quietly reprice the subsidiary to whatever the new parent's terms happen to be. Nobody asked for that. It's just what falls out of treating "belongs to this parent" and "bills at this parent's rate" as the same fact.
A real agency network isn't a flat list of accounts. A group like a major tour operator's regional arms, one head office over several national subsidiaries, is one commercial relationship wearing several legal entities. The CRM models that directly: any account can have a parent, capped at three levels deep, and one single, shared piece of logic decides what counts as a family, walking that structure the same way everywhere it's asked, on the account page, in reporting, in the reservations a subsidiary produced. Five separate places in the codebase used to each walk that structure their own slightly different way. Now there's one definition, and everything reads from it.
Here's the actual rule, and it's the part worth understanding precisely, because the two directions behave in genuinely opposite ways. When a brand-new subsidiary account is created underneath a parent, it inherits that parent's commercial terms for whatever it leaves blank, commission rate, payment terms, credit limit, cancellation policy. That's the sensible default: a brand-new account has no negotiating history of its own, so starting from the family's terms is less surprising than starting from nothing.
An existing account that moves to a different parent, or detaches from one entirely, does the opposite. Whatever it was inheriting gets written down as its own fixed value, calculated against its old parent chain, at the exact moment before the parent link actually changes. An account that was effectively billing at ten percent commission keeps billing at ten percent. It does not silently recalculate against whatever the new parent's rate happens to be. That account has real negotiated history and a live commission ledger already accruing against it, and repricing it automatically the moment an org chart changes would move real money with nobody in the room actually agreeing to it.
The three-level cap sounds like a simple number to enforce, and the naive version of enforcing it only checks one direction: does moving this account under a new parent push it too deep. That check alone misses a real case. Moving an account that already has its own children underneath it doesn't just move that one account, it drags its entire subtree down a level too. Checking only how deep the account being moved would sit, without checking how far its own descendants would then extend below it, can let a move through that quietly pushes grandchildren past the limit while the move itself looks perfectly fine. The real check measures both: how deep the destination sits, and how tall the subtree being moved actually is, added together, before allowing the move at all.
Commission accrual reads from this same inheritance logic. When a reservation attributed to an account is checked out and ready to accrue a commission, the system needs an actual rate to calculate against. If the account itself has no rate set of its own, meaning it's genuinely inheriting rather than carrying a frozen value, the calculation walks up the ancestor chain, up to three levels, until it finds one that does have a rate, and uses that. An account with its own frozen rate from an earlier move never does this walk at all. Its own number is already sitting there, exactly where the freeze rule put it.
That's multi-level agency commission tracking behaving the way a hotel group would actually want it to: a genuinely new subsidiary rides the family's rate automatically, while an account with real negotiating history keeps the number that history actually produced, all the way through to what gets accrued against a real booking.
Viewing a parent account, a hotel group can flip a single control to see figures rolled up across the whole family, every reservation, every commission entry, every contact, summed across the parent and all its descendants, rather than just that one entity's own numbers. That toggle lives in one place and is read by every tab on the account, reservations, contacts, deals, activities, commissions, production, so switching it once changes what every one of those views is actually counting, rather than needing to be re-set separately on each screen. It defaults to on for an account that actually has children, and off for one that doesn't, which is the behavior a hotel group would expect without ever touching the control at all.
Bulk-importing a whole agency network from a spreadsheet has an ordering problem a naive import misses entirely: a child row can appear in the file before the parent it's supposed to link to even exists yet. Processing strictly top to bottom would fail to link that child, or worse, link it inconsistently depending purely on which order the rows happened to be typed in. The real import creates every account first, then resolves every parent-child relationship in a second pass, working through the whole set in an order that guarantees every parent is already resolved before any of its children are linked, regardless of what order they appeared in the original file. A row whose stated parent can't be found, or whose linking would breach the depth cap or create a cycle, still imports, just as a standalone top-level account with a warning attached, rather than failing the entire batch over one bad row. A successfully linked child also inherits the family's terms on import, the same as it would creating one by hand.
None of this is really about org charts for their own sake. It's about the fact that a commercial relationship with an agency network doesn't reset every time someone in that network redraws a reporting line. A B2B CRM that reprices an account the moment its parent changes is optimizing for a tidy hierarchy over an honest one. The hierarchy should follow the business relationship. The pricing should follow what was actually agreed.
Thirty minutes, your real properties, no generic demo environment.
Every agency and tour operator deal at your hotel group already lives in a CRM contact record, with server-enforced commission gates instead of a spreadsheet column.
Most CRMs give a user full edit access or none. This one lets a hotel group lock a single deal field, like commission rate, to a named few, with a propose option instead of a hard no.
Most sales teams manually tick off a follow-up the moment a reply lands. This CRM matches the reply to the exact email it answers and closes the loop on its own.
