National Storage
99.99%
Data sync rate, up from 0.3%
230
Centres across Australia and New Zealand
53.5%
Email open rate
RevOps + HubSpot
The revenue system underneath. Architected properly, then automated.
You can’t automate your way out of a bad data model.
Every revenue system that actually works starts in the same place, and it is not the automation. It is the model underneath: the objects, the properties, the associations and the definitions that decide whether your pipeline is a forecast or a guess.
So we architect the CRM properly. Lifecycle stages, ownership, routing, the lot, built so your pipeline reports something you would happily take into a board meeting and your best rep stops keeping a private spreadsheet on the side.
We have been building on HubSpot for more than a decade, across every Hub, in portals running since the start and in ones that opened empty last week. If HubSpot is already in the building and nobody believes the dashboard, that is the job, and it is a very solvable one.
Businesses we build for
What we built, and what it moved.
Bring us the pipeline nobody trusts and the reports that never agree.
Book a callWhat RevOps covers here.
The data model comes first because everything else is built on top of it. Most projects are two or three of these, and your statement of work spells out which.
Data model and object architecture
Objects, properties and the relationships between them, designed around how your business actually sells. A default portal can’t know that.
Lifecycle and pipeline design
Stages that mean something, each with a written entry and exit condition. If two people can disagree about what stage a deal is in, the pipeline is not built yet.
Integrations and sync
The direction of every sync, the system of record for every field, and what happens when the two disagree. Decided before it is built, because otherwise it gets decided during an argument.
Reporting and attribution
Reports built off the data model itself, never off a spreadsheet somebody maintains at the side. If a number cannot be traced back to the record that produced it, it does not go in the report.
Migration
Getting out of the old system with the history intact: the mapping, the deduplication rules, the test load, and the day you actually cut over.
The portal after the project
Someone who knows your architecture, on a scope we agree up front, so a small change doesn’t turn into a rebuild eighteen months later.
How we usually build it.
Easy to buy is not the same as easy to run. Most portals we are handed were turned on in an afternoon, and everything built since has inherited whatever that afternoon guessed.
This is roughly the order we work in, and every project bends it a bit. Some need all six steps. Plenty start with the data model, because that’s the layer everything else was built on. What your project includes gets agreed in your statement of work.
Scope How the business actually sells, what breaks today, and who owns which field.
- What the sales process really is. The one your team actually runs, which is rarely the one on the slide.
- What breaks today, named. The report nobody trusts, the field nobody fills, the handover that drops.
- Who owns which field. Worth settling early, before two systems both decide they do.
Data model Objects, properties and associations designed around how you sell, instead of how a default portal ships.
- The object model, designed. Everything else inherits this layer, which is why we like to sort it before much else is switched on.
- Properties that earn their place. If nobody needs a field to do their job, it won’t get filled, so we either cut it or tie it to the work.
- Associations that match the business. Labels that reflect how deals, companies and contacts actually relate, instead of whatever the import guessed.
Pipeline Stages that mean something, ideally each with a clear way in and a clear way out.
- Entry and exit conditions. We try to agree these with you before deals start moving through.
- The stall stage named. Most pipelines have one stage where deals sit and go cold. Naming it, and tracking time in stage, is usually half the fix.
- Required fields that are actually required. Tied to the work, so filling them is how the job gets done instead of admin on top of it.
Build Pipelines, automation and integrations, with a direction and a system of record per field.
- The direction of each sync. Which system wins for each field, worked out before either one starts reading the other.
- Automation that a person can follow. Trigger, condition, branch and stop, usually written up so the next person is not reverse engineering it.
- Reporting built off the model. Reports and dashboards read from HubSpot objects and properties, so each number traces back to a record.
Migration Getting out of the old system with the history intact.
- The mapping, field by field. Including the ones that have nowhere to go, and what we do about them.
- Deduplication rules, agreed early. Which record wins when two of them are the same person.
- A test load first, where the data allows it. Then a cutover day that suits you, and a way back if it goes wrong.
Upkeep Portals drift as the business changes. Keeping an eye on it costs a lot less than a rebuild later.
- A named owner. Someone who knows the portal, so a small change stays a small change.
- The model reviewed as the business changes. New product, new region, new team: the architecture gets a look before it gets a workaround.
- Adoption tracked. If a field isn’t being filled, we look at why before anyone suggests more training.
HubSpot partnership
We are a HubSpot Diamond Partner and we have been building on the platform for more than a decade, across every Hub.
In practice, that gives you three things:
- A team that has already solved it. Whatever your portal is doing, we have almost certainly seen it before.
- A direct line into HubSpot. For the times something is genuinely broken rather than misconfigured.
- Enough time on the platform to know its edges. Which parts to trust, and which to build over.
17 HubSpot Impact Awards sit behind those three, across Technical Expertise, Platform Excellence, Platform Migration Excellence and Product Excellence. Each one is a real client’s system, with the figures attached. We are also Certified HubSpot Trainers, and we run Brisbane’s official HubSpot User Group.
See the HubSpot workMeet the engineers
-
Sophie CostelloAI & Digital Strategist -
Beau LeachAI & Digital Strategist -
Alex BaileyAI & Digital Strategist -
Cassy WoodforthAI & Digital Strategist
Big portals do not get fixed by starting again.
At this size, starting again is usually the riskier option. Three things tend to be true at once:
- Integrations nobody documented. Found by reading what the portal actually does, because nobody remembers.
- A sales team mid quarter. They keep selling right through it.
- A board reading the same dashboard every Monday. It keeps reporting while the model underneath it changes.
So the work happens in place and in the right order, with the reporting still standing while it does, because the alternative is asking a company to stop selling for a quarter.
These are the organisations that trust the work: ASX listed, household names, and businesses running national operations on portals we architected. Most had a live pipeline and a team mid quarter while we did the work, so we plan around that.
- 17HubSpot Impact Awards, 2020 to 2026
- 200+Businesses helped
- 10+Years as HubSpot partners
Where the data sits, and who holds what.
Your CRM stays the one place your data lives. We access client platforms as authorised users under least privilege and revoke at project end.
We do not migrate your CRM into Neighbourhood-owned infrastructure, and your records stay in HubSpot. When a tool we build for you needs a working copy of some records, like the deal fields a forecast reads, that copy sits on a Neighbourhood server in Sydney, kept separate for each client. On written request, we delete or return it within 30 days of the engagement ending. For Australian and New Zealand clients, HubSpot data is hosted in Sydney, inside Australian data centres and under Australian data sovereignty.
Where a build calls a model, it calls Anthropic, which operates under SOC 2 Type II. Fathom, which we use for meeting records, holds the same certification. Neighbourhood does not hold SOC 2 itself and does not imply otherwise.
Some of our work is performed by autonomous agents, and they run under a published action policy. Routine actions proceed and are logged. Actions in the middle tier notify the team first. Anything in the top tier stops and waits for an explicit human go, and a senior person reviews that queue before it moves. A narrow set of org control actions is reserved for the Director and cannot be performed by any agent, at any tier.
Read where your data lives
“They gave us a system that actually works and supports growth at scale. Cassy didn’t just help ‘set up’ HubSpot, she took the time to understand our business, our people, and the unique challenges of recruitment in real estate.”
Trent P
Head of Brand, The Agency · Read the case study
Your CRM stays yours. And it stays in Australia.
Once the data model is sorted, we deal with what’s already in the portal. Years of exports and half finished imports leave a mess, and cleaning it up is often most of the project. We would rather price that properly up front than automate a problem instead of fixing it.
After that, the rest gets a lot easier. Routing, scoring, sequences, quoting, forecasting, service tickets. Lifecycle and attribution that finance and marketing both agree with. Reporting your leadership reads without asking a question underneath it. All of it on data you can actually trust.
What breaks in a HubSpot build.
Six things we walk into over and over, written from real portals.
-
The portal was bought in an afternoon and architected never.
Someone turned it on, imported a spreadsheet, and the object model became whatever the import guessed. Every report built afterwards inherits that guess.
-
The deal stages describe a process from four years ago.
Nobody updates them because everyone has a workaround, so the pipeline report is a picture of the workarounds.
-
Two systems both think they own the same field.
Nobody wrote down which one wins, so the value flips depending on which sync ran last. The person who notices is usually a customer.
-
Nobody fills in the fields, and the answer is always more training.
It is almost never training. The field is not needed to do the job, so it does not get filled. Delete it, or make it load bearing.
-
The reporting is built off exports.
The moment a number lives in a spreadsheet it stops matching the CRM, and the meeting about the difference costs more than the report ever saved.
-
There is no owner after go-live.
The portal was a project, so it ended. Portals do not end. They drift, and a year later somebody is quoting a rebuild.
What operations leads ask us.
We already have HubSpot and nobody trusts the dashboard. Where do you start?
With the object model and the definitions. The dashboard is usually reporting exactly what it was told to, so the disagreement starts further up.
Do we have to rebuild everything?
Almost never. Most portals need the model corrected and three or four things untangled. We will tell you which one you are looking at after the diagnostic, and the cheaper answer is the more common one.
Can you work with our existing team?
That is the preferred shape. We build so your team can run it, and handover includes the documentation and the training. If you would rather we looked after it, that is a partnership with a named person and a stated monthly scope.
How do we defend this spend internally?
The diagnostic produces the case, priced, with the failure modes named and what each one is costing you now. That is the document you take upstairs.
What about the data we have been avoiding?
That is usually the actual project. Years of exports and half finished imports leave a mess nobody wants to own. We will quote it honestly, including when it is bigger than you hoped.
Tell us what’s not working.
A few lines is enough. You will get a human reply within one business day. After a first call with Matt, one PM plans it and builds it.
Got it, there.
We will be back to you within one business day. Rather not wait? Pick a time with Matt below and skip the email round, or call 1300 71 61 41.