- 01
A CRM built around how you actually sell.
Pipelines, properties and permissions mapped to your real sales process, not the default setup.
Six services. One revenue system.
Services
A CRM built around how you actually sell.
Pipelines, properties and permissions mapped to your real sales process, not the default setup.
Six services. One revenue system.
Services
Page Pros sells across the US and Canada. We built a single HubSpot architecture both regions work inside — shared where the team works, separated where the numbers are read — without the Business Units add-on.
Page Pros, a Canadian e-commerce services firm, sells three products across the US and Canada. The default move is to give each region its own portal, or its own everything inside one — and it fails the same way every time. The team ends up mentally running two platforms. A property means one thing on one side and something slightly different on the other. Within a year, nobody can produce a single number that covers the whole business.
The owner wanted two regions to read separately without the team feeling like it worked in two systems.
So anyone moving between them works in one system with one vocabulary. The separation happens at the reporting layer instead — metrics break out cleanly by country.
We did it with property architecture and reporting rather than the Business Units add-on, which is cheaper and, for two regions sharing one business model, the right answer anyway.
The sales pipeline tracks a deal from first contact to payment, with closed-won set by the payment completing — not by a rep deciding the deal feels done. The stage reflects an event that happened in the world. What follows the payment is a creation order, and the order is the finding.
The emails below are gated on this. Build them in the obvious order and they fire into a gap.
Onboarding and discovery, strategy and setup, then maintenance and review on a repeating rhythm — instead of a template that would only have tracked whether someone replied to an email. Alongside it, the renewal cycle runs on the same record, month after month, without anyone touching it.
Two rhythms on the same record. Neither depends on anyone remembering.
When a payment fails, three statuses change at once, three people are told, and the retries run on a schedule. Whichever way it resolves, the record says so.
A cancelled customer receiving a cheerful monthly invitation is a small failure that tells them exactly how well your systems talk.
The history stays on the company. The customer does not come back as a stranger.
Last payment date and next payment date make renewal timing queryable.
Last status change date exposes accounts that have sat still.
A multi-checkbox product field holds any combination of the three products, so a two-product customer is one record rather than a compromise.
Ownership is assigned by event, not by a rule someone maintains. Booking the onboarding meeting through a round-robin link is the same action that assigns the account manager, so there’s no gap between a customer becoming active and someone owning them.
And property creation is restricted to super admin, because a schema anyone can extend becomes six fields meaning the same thing within a year.
That risk doubles across two regions, where a property invented on one side is a property the other side doesn’t have.
A shared vocabulary the whole team reads the same way.
Country-level reporting the owner can trust — via property architecture, not a paid add-on.
Three pipelines matching the real sales, delivery, and renewal motions.
A schema disciplined enough that someone who has never opened the portal could read the property list and understand the business.
Every element exists because a decision in the business needed it — none of it because HubSpot offered the field.