A CRM built years ago probably still has a “customer” tag sitting in it somewhere. Under TRESA that tag describes a relationship that does not legally exist any more, and segmentation built around it is segmenting against a model that has already changed.
Key takeaways
Before TRESA, a lot of CRM setups defaulted to three buckets: client, customer, and everyone else. RECO’s Bulletin 2.6 removed the middle one outright: “customer relationships and customer agreements are not permitted under TRESA”, and “there is no equivalent to a customer or a customer agreement under TRESA”. (reco.on.ca) A “customer” segment sitting in a CRM today either describes contacts who should have been migrated to a real category back in 2024, or it is being used loosely as a synonym for “lead,” which invites exactly the confusion the rule change was meant to end.
Bulletin 2.6 is explicit that a person in a trade is either “a client of a brokerage, or a self-represented party”. (reco.on.ca) Bulletin 2.4 spells out what the second category actually means in practice, down to the words an agent is expected to say out loud: “I am representing my client and my client’s best interests. I do not represent you or your best interests. I cannot provide you with any services, opinions, or advice.” (reco.on.ca) That is not a soft distinction to fold into a general “prospect” tag — it is a defined legal relationship with its own required disclosure script.
Bulletin 2.4 also makes clear this is not a permanent tag once assigned: “a self-represented party is free to enter into a representation agreement with a brokerage at any point”. A CRM field that records “self-represented party” as a static, unchanging status will be wrong the moment that person signs a representation agreement — which can happen at any point in an active file. Segmentation built on representation status has to be something that gets checked and updated as a file moves, not a one-time classification made at first contact.
Representation status answers who you owe duties to and what you can say to them inside an active file. It says nothing about whether you can legally email a past client a newsletter two years after their file closed — that is a CASL question, running on the implied-consent clock covered elsewhere on this hub, (laws-lois.justice.gc.ca). A useful segmentation layers both axes rather than collapsing them: a past client can be well inside the consent window and still not be a “client” in the representation sense on any new matter, and a self-represented party in an active file has a consent basis of their own, separate from whether they have signed anything.
A single flat “past clients” segment hides two different problems. It cannot distinguish a closed-file client who is still inside the two-year CASL window from one whose implied consent lapsed eighteen months ago, so a mass send risks non-compliant messages to the second group. And it cannot distinguish a genuinely closed relationship from a self-represented party from an old file who never became a client at all — someone a broader marketing send may be entirely inappropriate for, given the narrow, no-advice relationship Bulletin 2.4 describes. Two axes, tracked separately, catch both problems a flat list misses.
Representation status and consent basis are the two axes the law actually forces. A third, purely practical one is worth adding on top for content relevance: whether a contact is a buyer, a seller, or has been both at different times. A past client segmented correctly on the first two axes but tagged generically still risks getting seller-focused market updates the year after they bought, or buyer content the year they are gearing up to list. It is not a compliance requirement the way the other two axes are, but it is the difference between a segmented list and a merely labelled one — and it costs nothing extra to capture at the point a file opens, when the transaction type is already known.
A CRM still carrying legacy customer tags from before 2024 needs each one individually reassigned, not bulk-relabelled, because the two replacement categories are not interchangeable — a contact tagged “customer” under the old regime might now be a closed client, an active self-represented party, or simply a cold lead with no live status at all, and only a look at the actual file history answers which. This pairs naturally with the broader database cleanup and consent-tagging work covered elsewhere on this hub — a legacy-tag migration is a good occasion to run both projects at once rather than separately.
A CRM rebuild replaces the old client/customer/prospect fields with two: a representation-status field (client – active, self-represented party – active, closed) and a consent-basis field (express, implied – transaction, implied – inquiry, lapsed) with a linked date. Segmenting by representation status alone answers “who am I currently acting for.” Segmenting by consent basis alone answers “who can I legally email today.” Together, a query for “closed clients, implied consent still valid” produces exactly the list a quarterly newsletter should go to — a query neither field could answer correctly alone.
None of this requires expensive software. The two fields are ordinary picklists in any system that supports custom fields, and the third, practical buyer/seller/both tag is a checkbox added at file-open. The discipline that actually makes segmentation work is keeping the fields current as files move, not the sophistication of the platform they live in — a disciplined spreadsheet will out-perform an expensive CRM whose fields nobody bothers to maintain.
Related: what is your duty to a customer, self-represented party, defined and customer service agreement, defined.
No. RECO's Bulletin 2.6 says so directly — the term is not a replacement or a rebrand. A customer relationship allowed a more flexible service arrangement that TRESA removed entirely; a self-represented party gets narrow, no-advice assistance only, by a different set of rules.
Yes — the two are independent. Representation status governs the current file and what duties apply inside it; CASL consent governs whether you can send that person a commercial electronic message. A contact can score differently on each axis at the same time.
Not necessarily in name or detail — TRESA is Ontario law specifically. Other provinces' regulators draw comparable representation-status lines through their own legislation, and their own rules should be checked before assuming Ontario's exact categories apply elsewhere.
At minimum whenever a file's status changes — an assistance interaction turning into a signed representation agreement, or a file closing. A static field set once at first contact and never revisited will drift out of accuracy exactly at the moments it matters most, per Bulletin 2.4's own point that a self-represented party can become a client at any time.
A short call is enough to map the two axes onto fields your CRM can actually query.
