We replaced a paid referral tool with HubSpot and Zapier. Field notes.

The situation

The client runs a training business. Students enrol, finish a program, graduate, and some of them tell friends and coworkers about it. The company wanted to formalize that: give alumni a reason to refer, give new students a discount, and track the whole thing.

So they did what most teams do. They bought referral software. The tool had the standard shape. Each alum gets a code, new customers enter the code somewhere, the tool records who referred whom, and a dashboard counts it all up.

By the time they called us, the program had three problems.

• The data lived in the wrong place. Students and alumni lived in HubSpot. Referrals lived in the tool. Anyone who wanted to know whether a new enrolment was referred had to check a second system with its own login.
• The reward did not reach the invoice. The tool's coupon worked in the tool's own checkout widget. The client did not use that checkout. Enrolment ran through their own forms and invoices, so somebody applied the discount by hand and hoped it matched what the tool had promised.
• The bill arrived either way. The subscription renewed whether the program produced referrals or not.

The original ask was modest: "Can you make the referral tool talk to HubSpot?" That is how the project landed with us. We do this kind of CRM and automation work every week, so the honest answer should have come quickly. It did not, because we took the ask at face value.

What we tried first

We did what was asked. We built the integration.

Zapier sat between the referral tool and HubSpot. When the tool recorded a new referral, Zapier created or updated the contact in HubSpot and stamped a property with the referrer's name. The happy path worked within a day, and for a day we felt good about it.

Then the edge cases started.

• The tool kept its own contact list. The same person could exist in the tool under one email and in HubSpot under another. Syncing meant matching people across two databases that disagreed about who people were.
• An alum referred someone who was already a lead in HubSpot, mid pipeline, already talking to the team. The tool logged it as a fresh referral. The sales team did not see it that way. Nobody had written down a rule for this.
• The discount problem did not move at all. The coupon still lived in a checkout the client did not use. Integrating the two systems made the data tidier and left the actual money workflow exactly as manual as before.

At some point we stopped and did the exercise we now do first on every project like this. We wrote down, in one column, everything the paid tool contributed to the program. The list was short. It stored who referred whom. It generated unique codes. It promised a coupon that did not connect to anything the client used. We were building integration logic to keep two copies of the same people in sync, and the client was paying a subscription for the second copy.

The thing that mattered most

Strip any referral tool down to its working parts and you get four functions.

1. A registry. Who is allowed to refer, each with a unique identifier.
2. Attribution. A way to connect a new buyer to the person who sent them.
3. A reward. Discount math, and something that delivers it.
4. Noise. Notifications and a dashboard, so people believe the program is alive.

Now hold that list up against a CRM. The registry is a database keyed on people. HubSpot is a database keyed on people, and it already held every alum with a real email, a cohort, and a graduation date. Attribution is a lookup plus a link between two records, and HubSpot does record associations natively. The reward is arithmetic inside an invoice flow. The noise is a Slack message.

The only thing the paid tool owned that HubSpot did not was the code itself: one short unique string per alum. That is a single custom field, and generating it is one automation step.

That was the whole insight. The referral tool was a database with a coupon, and the CRM already was the database. Once we saw it that way, the integration project became a replacement project, and the replacement was smaller than the integration we had been building.

This generalizes well beyond referrals. A surprising number of point tools are one thin feature wrapped around a copy of your CRM data. The question to ask before any integration: what does this tool know that the CRM does not? If the answer is one field, you are probably looking at a small build, not an integration. If the answer is real capability, things like multi-tier commission math, cash payouts to hundreds of external affiliates, tax paperwork, or fraud detection, then the tool is doing real work and you should keep paying for it.

What shipped

The whole rebuild runs on HubSpot, Zapier, and Slack. No new logins, no new subscription. Four pieces.

1. Codes generate at graduation

When a student's record flips to graduated in HubSpot, a Zap fires. It builds a short, readable, unique code, checks that no other contact already holds it, writes it to a custom property on the alum's contact record, and sends the alum an email with the code and the terms. Nobody creates codes by hand. Nobody maintains a spreadsheet of them. Graduation is the trigger, so the registry of referrers grows on its own, in step with the people most likely to refer: the ones who just finished.

Storing the code as a contact property matters more than it sounds. It means any code resolves to exactly one human with a single HubSpot search, and every list, report, and workflow in the CRM can use it like any other field.

2. Attribution happens on the enrolment form

The enrolment form gained one optional field: referral code. On submission, Zapier searches HubSpot contacts for a matching code. A match stamps a referred-by property on the new contact and associates the two records, alum and applicant, inside HubSpot. No match posts an alert to Slack so a human can look, because a mistyped code is a person quietly not getting their discount. That is how referral programs decline: one disappointed person at a time.

3. The discount lives inside the invoice flow

The reward is a discount of about 20 percent. When a referred applicant's deal reaches the paying stage, the automation applies the discount and runs the invoice flow with the adjusted amount. The discount is not a coupon sitting in a third-party checkout. It is a number inside the same flow that produces the invoice, which means finance never reconciles the tool's promises against what was billed. There is nothing to reconcile.

4. Slack tells the team it is working

Every redemption posts a message to a Slack channel: which alum referred, who enrolled, what discount applied. We expected this to be the throwaway part. It turned out to matter. The team watched referrals arrive in real time, in the place they already worked, and that visibility kept them mentioning the program to students. A dashboard you have to remember to open does not do that.

Here is the before and after, part by part.

Function	The paid tool	The rebuild
Referrer registry	Its own contact list, synced against the CRM	HubSpot contacts, already there
Unique codes	Generated inside the tool	One Zapier step at graduation, stored as a contact property
Attribution	Tracked in the tool's database	A referred-by property and a record association in HubSpot
Discount	A coupon in a checkout the client did not use	About 20 percent, applied inside the invoice flow
Notifications	Inside the tool, if you logged in	A Slack message per redemption
Reporting	The tool's dashboard	HubSpot lists and reports, same as the rest of the business
Ongoing cost	A recurring subscription	$0

The paid referral software was retired. Ongoing software cost for the program is $0, because the client already paid for HubSpot, Zapier, and Slack for everything else. The first referrals came in during week one, before anyone had promoted the program, which told us the demand had been there the whole time. The old tool had not been creating referrals. It had been storing them, expensively, somewhere the team did not look.

What we would do differently

Field notes are only useful if they include the misses. Ours, in order of cost.

Start with the parts list, not the integration. We spent the first stretch of this project building sync logic we later threw away, because the ask was "integrate the tool" and we answered the ask instead of the problem. Now the parts list comes first: what does the tool do, and what does it know that the CRM does not. That exercise takes an hour. It would have saved us days. It is also why we put scope in writing before we build, because writing the scope forces that conversation.

Settle attribution rules before writing a single Zap. The awkward conversation on this project was the alum who referred someone already in the pipeline. Who gets credit? We had to pause the build, take it to the owner, and get a ruling: the code counts unless the person already had an open deal. That rule should have been in the scope document from day one. Every referral program has these questions. Does a code expire? Can two alumni refer the same person? Does the referrer get a reward too? All of them surfaced once real codes were in the wild. Write them down first.

Prefill the code. We shipped a typed code field on the form. It works, but typing is where typos live, and our Slack alert for unmatched codes exists mostly because of that choice. If we built it again, the graduation email would carry a personalized link with the code already filled in, and the typed field would be the fallback, not the main path.

Say earlier who does not need this. If you get a handful of referrals a year, you do not need software or a consultant. A column in a spreadsheet and a manual discount is the right amount of engineering. If you pay cash commissions to a large network of external affiliates, with payout schedules and tax paperwork, buy purpose-built affiliate software, because there the tool does real work. The build described here fits the middle case: your customers already live in your CRM, your reward is a discount on your own product, and you are paying a subscription for a database you already own.

This was one build among the 600+ workflows we have shipped, and it is the one we point to when someone asks what "the CRM is already the database" means in practice. If you want help working out whether your referral tool, or any point tool, falls into that category, we charge a flat $150 per hour CAD, scope is quoted in writing before work starts, and hours never expire. Sometimes the answer is that you do not need us, and we will say so. Get in touch if that sounds useful.

FAQ

Do we need referral software at all?

Probably not, if two things are true: your customers already live in a CRM, and your reward is a discount on your own product. In that case the referral tool mostly stores a copy of data you already own, plus one extra field for the code. You do need purpose-built software when the reward is cash paid to many external affiliates, when commissions have tiers, or when payouts come with tax paperwork. That is real machinery, not a field.

Why Zapier instead of Make or n8n?

Every step in this build is a plain trigger and action between HubSpot, a form, and Slack, which is the case Zapier handles with the least setup, and the referral volume was never going to make per-task pricing hurt. With a different starting stack or higher volume the decision changes, and we wrote up how we choose in Zapier vs Make vs n8n.

How do the codes stay unique?

Two ways at once. Each code is built from a short fragment of the alum's name plus random characters, which makes collisions unlikely, and the Zap searches HubSpot for the code before writing it, which stops a duplicate from ever being stored. Because the code lives as a property on exactly one contact record, any code resolves to exactly one person.

What does a build like this cost?

We charge a flat $150 per hour CAD, we put the scope and the estimate in writing before any work starts, and unused hours never expire. A build like this is small by automation standards: a handful of Zaps, a few custom properties, one form change, and the rules conversation. The rules conversation is the part people underestimate, and it is the part that decides whether the program survives contact with real customers.