Loading
The CRM has the customer as an account. The helpdesk has them as an organisation. Finance has them as a ledger contact with a different legal name, and the delivery tool has them as a project prefix. Each version is correct in its own system and collectively they guarantee that somebody, eventually, will tell the customer something untrue.
Syncing does not solve this; it postpones it. Two-way integrations move fields, not meaning, so the moment one system allows a value the other does not, the record forks. Then the reconciliation work begins — usually performed by the person with the least context and the most patience.
Treepie keeps one row and gives each product a view of it. Hierarchy is real structure rather than a naming convention, contacts who change employer keep their history in both places, and permissions decide which fields a given team can see without splitting the record into copies.
Parent companies, subsidiaries and the people who move between them stay connected, so history follows the relationship rather than the email address.
Because every product reads the same row, there is nothing to sync, nothing to reconcile, and no argument about which system is authoritative.
Importing records is the part teams dread and the part that pays for itself fastest. The first pass usually reveals that ten to fifteen per cent of “separate customers” are the same group under different spellings, and that a meaningful share of contacts left two years ago. Reviewing the flagged matches takes an afternoon and removes an entire category of future confusion.
After that, the change is quiet. Support stops opening a second tab to find out who the customer is. Delivery stops asking sales whether the caveat was agreed. Finance stops maintaining a parallel contact list with slightly different legal names. Nobody celebrates it, and nobody wants to go back.
The permission model is what makes a single record politically possible. Because access is decided by field as well as by record, the organisation can be genuinely shared without exposing pricing to everyone who answers a ticket — the usual reason companies end up with four copies in the first place.
It does not enrich records from third-party data by default; what is in your account is what you put there.
It will not merge duplicates automatically — matches are proposed and a human decides.
It is not a data-quality service. Bad inputs stay visible rather than being quietly normalised.
This is the feature the rest of the platform quietly depends on: every other connection in Treepie is really just two products reading this row.
They are flagged rather than merged silently. You review the matches, and a merge keeps both histories with a record of what was combined and by whom.
Yes — by team, owner or individual record, and by field within a record. The record stays whole for the people who should see all of it.
No. They read the same row. That is the entire point: there is no sync to fall behind and no authoritative-system argument to have.
Parents, subsidiaries and sites are real relationships, so reporting rolls up without a spreadsheet mapping and support load is visible at group level.
They keep their history where it happened and can be attached to a new organisation, so the relationship survives the job change.
Yes — read and write, with webhooks on change, so a product you build yourself can use the same row rather than a copy of it.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.