Data governance in the CRM: where a university starts

Every education institution running a CRM (Customer Relationship Management, the system that centralises relationships with applicants and students) reaches the same scene: two reports on the same period show different application numbers. The discussion turns into distrust of the tool, when the problem sits somewhere else.

What is missing in those cases is data governance. Without clear rules on creating, updating and discarding records, the CRM becomes a warehouse of repeated contacts, empty fields and statuses nobody can trace.

The difference between a reliable database and a warehouse is not in the software. It is in the agreement the institution makes about how data is born, circulates and dies inside the system.

What does data governance solve in an institution's CRM?

Data governance solves four concrete problems in an education institution's operation: reports that do not reconcile, duplicate contacts that inflate the funnel, fields filled differently by each team, and information that should have been deleted and is still stored with no purpose.

Caption: data governance starts by stopping the same applicant from becoming two records in the CRM

None of those problems shows up as a system failure. They show up as a long meeting about which number is right, and the real cost is the time the team spends reconciling spreadsheets instead of deciding.

The first symptom is a counting mismatch. Marketing reports a thousand applicants, the registrar sees eight hundred, and the difference is repeated records created by channels that do not talk to each other.

The second symptom is the free-text field. When “programme of interest” is open text, the same degree appears spelled five ways and no report by programme comes out reliable.

The third is lost memory. The applicant who dropped out last semester applies again and is treated as a new contact, because the history stayed on another record.

It is worth separating two things that often get confused. CRM adoption is about getting the team to use the tool, while governance is about the quality of what the team records when it does.

The good news is that governance compounds. Every rule written today avoids years of retroactive cleaning, and the gain shows up first in student recruitment and retention reports, which start matching the registrar's reality.

How do you model the contact lifecycle at an education institution?

The HubSpot CRM already ships default lifecycle stages: subscriber, lead, marketing qualified lead, sales qualified lead, opportunity, customer, evangelist and other, according to the documentation on using contact and company lifecycle stages.

The problem is a different one. Those stages follow a sales logic and do not cover applicant, enrolled, student and alumnus, so they have to be adapted. HubSpot lets you create and customise lifecycle stages on all products and plans, with super admin permission, and that modelling work belongs to the institution.

Every transition needs three things: an objective entry criterion, an owner and a piece of data that changes on the record.

The difference from the generic sales model matters. In traditional sales, the cycle ends at the close, while in education the contact stays alive for years after enrolment and may come back as a postgraduate applicant.

That is why the design has to allow for the return: an alumnus coming back for a specialisation reuses the same record, with the accumulated history.

The transition criterion is the point that generates the most internal argument. “Applicant” cannot mean one thing to marketing and another to sales, because both numbers land in the same report.

A definition works when it is verifiable without opinion. “Applicant” as “person with a paid or waived application confirmed in the student system” works; “applicant” as “a well-qualified lead” solves nothing.

Here is how the stages usually organise themselves at a higher education institution:

Table: a contact lifecycle model for a private higher education institution, the first layer of data governance

That design also sustains student retention. When the record follows the person from the first click to graduation, the team can spot risk signals before dropout, rather than in next term's report.

The importance of CRM for organisations becomes clear at exactly that point: the value is not in storing contacts, but in keeping a single timeline per person.

Video: the relationship fundamentals that data governance has to turn into rules inside the CRM, on the mkt4edu channel (in Portuguese)

How do you prevent and fix duplicate contacts in the HubSpot CRM?

Duplicate contacts are fought on two fronts: prevention at entry and clearing the backlog. For prevention, you define a unique identification key and restrict manual record creation. For the backlog, you run a periodic merge routine with a documented rule on which value prevails.

The unique key is the most important decision and the most postponed. At education institutions, email tends to fail as an identifier, because applicants change addresses and share a family member's inbox.

A national ID number solves identification better, but it is not always available at first contact. A common route is to adopt email as the initial key and promote the ID number to definitive identifier as soon as the application happens.

The second prevention point is the form. Masked fields, standardised phone numbers and closed lists instead of free text eliminate most of the variations that create parallel records.

The third is the entry channel. Spreadsheet imports, integrations with the student system and records typed by hand at the front desk are the three doors that create the most duplicates, and each one needs the same verification rule.

In the HubSpot CRM, the data quality tools bring together a duplicates view for contacts and companies to review and merge, alongside formatting fixes and a per-property insights panel, with an alert when duplicates exceed the daily limit. They help with volume, but they do not decide the criterion, which remains governance work.

Before merging, write down the prevalence rule. Deciding that the oldest record keeps the source and the newest keeps the contact details stops each person on the team resolving the conflict their own way.

Badly designed integrations manufacture duplicates at scale too. When an SDR agent integrated with the CRM creates a contact for every new conversation without checking the base, the volume grows within days.

Which privacy law rules affect an education CRM?

Brazil's LGPD affects an education CRM at four practical points: the legal basis that authorises each processing activity, the principles of purpose and necessity, the data subject's rights over their own data and the duty to delete information once processing has ended. None of them is solved by a cookie banner.

This article does not replace legal advice, and reading each obligation depends on the institution's context. What follows are the provisions that show up most often for whoever administers the database.

The first point is the legal basis. Article 7 of Lei 13.709/2018 lists the situations that authorise processing, and consent is only the first of them, alongside performance of a contract and the controller's legitimate interests.

That distinction changes the operation. Treating everything as consent creates the expectation that any withdrawal erases the academic history, which is not how the law is designed.

The second point is the principles in article 6, among them purpose, necessity, data quality and transparency. The law defines necessity as limiting processing to the minimum needed to achieve its purposes, and it is the strongest argument against forms asking for data with no defined use.

The data quality principle is the one that speaks most directly to governance. The law guarantees data subjects accuracy, clarity, relevance and up-to-date data, which is exactly what a database full of duplicates stops delivering.

The third point gathers the data subject rights listed in article 18. A person can request confirmation of processing, access, correction of incomplete, inaccurate or outdated data, deletion, portability and withdrawal of consent.

In practice, that requires knowing where each piece of data sits. If the same applicant exists in three records, honouring a correction request on only one of them does not honour the request.

The fourth point is the end of processing. Articles 15 and 16 cover termination and deletion, and article 16 authorises retention in specific situations, two of them tied to anonymisation: use for study by a research body, anonymised whenever possible, and exclusive use by the controller, with third-party access forbidden and the data anonymised.

Notice what the law does not do: it sets no deadline in months for keeping the contact details of an applicant who never enrolled. Defining that period, documenting it and applying it is the institution's decision, supported by the declared purpose.

There is also the duty to report incidents. Article 48 requires communicating a security incident to the national authority and to the data subject, and the ANPD (Autoridade Nacional de Proteção de Dados, Brazil's data protection authority) set a three-business-day deadline for that communication, based on Resolução CD/ANPD nº 15/2024 and subject to any period set by specific legislation.

Education institutions deal with an audience that includes minors, and the law covers the topic in its own article. Article 14 requires that processing of children's and adolescents' data happen in their best interest, with specific and prominent consent from at least one parent or guardian in the case of children.

The technical configuration of consent, forms and policies is usually settled during the HubSpot implementation, while governance handles what happens afterwards, once the database is in daily use.

For the broader discussion on CRM and data privacy, what matters is that privacy implemented well does not block education marketing strategies; it reduces the risk of running a student recruitment database without knowing what you keep.

What monthly hygiene routine should you keep on the CRM database?

A sustainable monthly hygiene routine fits in about two hours and covers six checks: pending duplicates, contacts missing a required field, invalid emails, records stuck at the same stage, data past its retention period and fields created without approval. The value is in consistency, not in the size of the clean-up.

The checklist below works as a starting point and should be adjusted to the size of the operation:

• Review the suggested duplicates queue and merge the confirmed pairs.
• List contacts created this month with no programme of interest or no source filled in.
• Handle addresses that bounced during the period's sends.
• Identify records stuck at the same stage beyond the expected window.
• Apply the retention rule to contacts that lost their purpose.
• Check whether any new field was created outside the approval process.

One important caveat: applying retention means deleting or anonymising, not hiding the record. Article 16 of Lei 13.709/2018 requires deletion after processing ends and only authorises retention in the situations it lists.

High-volume operations can automate part of the checking. HubSpot lets you email or export reports and dashboards on a recurring daily, weekly or monthly schedule, available on all products and plans, which reduces the routine to judging the exceptions. That is how data at scale becomes decisions instead of becoming backlog.

How do you measure data quality and keep the data dictionary?

Data quality is measured with four simple indicators: the fill rate of critical fields, the estimated duplicate rate, the share of contacts with an identified source and the average age of active records. Measured month by month, they show whether the database is improving or merely growing.

The fill rate is the most actionable indicator. If only 60% of contacts have a programme of interest, no report by programme can be treated as a faithful picture of demand.

The duplicate rate is usually estimated by sampling. Checking a hundred random records and counting how many have a pair in the base gives a reading good enough to track the trend.

The share with an identified source defines what you can decide about budget. A contact with no source does not enter the cost-per-enrolment calculation, and a large slice of anonymous records distorts any comparison between channels.

The data dictionary is the document that sustains those numbers. It lists every CRM field with its name, type, accepted values, who can edit it, where the data comes from and what it is for.

The rule that protects the dictionary most is about process, not technology. No new field enters without a declared owner, a written purpose and a definition of what happens to it once the campaign ends.

Institutions that treat the HubSpot CRM as the system of record for the operation, rather than one team's tool, tend to keep that document alive. It is what separates a CRM operation with method from a database that grows without control.

Video: what AI becomes able to do once data governance has delivered a reliable base, on the mkt4edu channel (in Portuguese)

Frequently asked questions about data governance

Where do you start data governance in an education CRM?

Start with the contact lifecycle. Until marketing, sales and the registrar use the same definition of applicant, registered and enrolled, any database clean-up will be undone next cycle by the operation itself.

Then attack duplicates. Defining the unique key and closing the entry doors stops the merge effort becoming a permanent task with no end in sight.

Only then write the data dictionary and the retention rule. With stages and identification settled, the rest of governance becomes documentation rather than redesign.

When those three layers stand, education marketing strategies stop arguing about which number is true and start discussing what to do with it. That is the difference between a reconciliation meeting and a decision meeting.

A governed base is what makes it possible to predict behaviour, not just record it. The article on artificial intelligence in retention service shows what becomes viable once the data is organised.