7 Red Flags to Watch For When You're Hiring a RevOps Partner

The CRM setup industry has a dirty secret: it is very easy to look like you know what you are doing before the contract is signed.

A confident second meeting. A case study page full of customer names. A methodology PDF with a lot of arrows in it. None of that tells you whether the person who will configure your pipeline has done it for a company your size, or is going to work it out alongside you at your expense.

If you run 60 to 200 people, you are not buying this off a thirty minute call. There is a shortlist, two or three rounds of meetings, a security review, a procurement step, and someone in finance who wants to know why the number is the number. That process is your advantage. Every red flag below is visible during it, and every one of them is cheap to test with a single question.

Miss them and you spend the first six months of the partnership undoing the build you paid for.

1. The proposal arrives before anyone has looked inside your portal

The clearest sign of a partner selling a product is a number that arrives before discovery.

If a provider can price the work after one introductory call, without seeing your portal, your data, your integrations list or how your team is structured, they are pricing a template. At your size that template breaks in the same three places every time: several pipelines with different qualification rules, a marketing team and a sales team who disagree about what a qualified lead is, and years of records where nobody's company name is spelled the same way twice.

Scoping this properly takes either a paid discovery phase or a fortnight of real access to your portal. Both are reasonable. A fixed price with neither behind it is a guess wearing a suit.

Ask this: what do you still need to know about our business before that number is accurate? A good partner has a list. A red flag partner has a price.

2. Nobody asks how you actually sell

A CRM configured around the way your team already sells gets used. One configured around a generic template of what a sales process should look like gets worked around, then ignored, then blamed.

By 60 people you almost certainly have more than one sales motion. Inbound demos and outbound enterprise deals do not share a pipeline, and a partner who has not asked which is which will build you one pipeline with a stage for everything and a fit for neither. Ask how they will handle the second motion. If the answer is a deal stage, keep looking.

HubSpot's default deal stages (Appointment Scheduled, Qualified to Buy, Presentation Scheduled, Decision Maker Bought In, Contract Sent) are a starting point for a company that has never had a CRM. A provider who leaves them in place and calls the pipeline configured has not done the work. This is why we push clients to finish mapping your sales process before any CRM onboarding starts, on a whiteboard, before a single property gets created.

Ask this: walk us through how you would map our process to the CRM before you configure anything. The answer should describe a workshop and an artefact you get to approve.

3. The data migration is one sentence long

"We will help you move your data across" is not a migration process. It is a reassurance with nothing behind it.

A proper data migration has at least five steps: an audit of the source data, a field mapping document showing where every field ends up in HubSpot, deduplication before the import runs, a test import on a sample, and validation that the records arrived with the right company and deal associations attached.

Skip any of those and the CRM starts life with duplicate contacts, broken company associations or missing deal history. At 200 people that is not a tidy-up job for later. It is the reason your sales manager keeps a spreadsheet in month four, and once that spreadsheet exists you have two CRMs and no source of truth.

Ask this: walk us through your migration process step by step, then count the steps. Four or five means they have done this before. One means "we will do an import".

4. The contract does not say who owns what they build

This is the one that gets skipped in every evaluation we see, and it is the most expensive.

Under Australian law the default is not what most buyers assume. IP Australia puts it plainly: IP created by a contractor is the property of the contractor unless otherwise stated in the contract, while employers own the IP their employees create in relation to the business. So what your own staff build is yours. An agency is not your staff, and unless the agreement says otherwise, what they build stays theirs.

For a CRM setup that mostly does not matter, because HubSpot configuration is settings inside your own portal. The moment there is custom code it matters a great deal: middleware between HubSpot and your ERP, a custom coded workflow action, a serverless function, a CMS theme, the scripts that run your migration. The IP in all of that sits with whoever wrote it unless your contract moves it. Plenty of partners are relaxed about this right up until you want to leave.

Ask this: does the agreement assign us ownership of the code you write, and does the source live in a repository we control? A partner with nothing to hide says yes to both and sends you the clause. If they offer a licence instead of ownership, read what happens to that licence when the partnership ends.

5. Training is one session for everyone

A single platform overview for the whole company is not training. It is an introduction to an interface nobody will use confidently once the meeting ends.

At 120 people, one session means a room of people who need different things, a recording almost nobody finishes, and a support queue that comes to you instead of the partner. The sales rep who needs to manage deals, log calls, enrol contacts in sequences and use the mobile app needs a different session to the marketing manager building workflows and smart lists and reading campaign attribution reports. Train them together and both leave knowing HubSpot exists.

The role most evaluations forget is the internal admin who inherits the portal. Somebody in your business is going to own permissions, properties and workflows after the partner steps back. If the training plan does not name that person and give them their own sessions, the plan has a hole in it shaped like your operations manager.

Ask this: which roles get their own session, what does each cover, and what does the handover training for our internal admin look like?

6. Integrations are phase two

"We will deal with the integrations once the core setup is done" is the sentence that precedes a go-live delay, a scope dispute, and the discovery that connecting your finance system needs custom development nobody budgeted for.

Every external system that has to talk to HubSpot belongs in scoping: email and calendar, advertising platforms, your support desk, and above all whatever your finance team runs. Xero, MYOB and NetSuite each connect differently, and the gap between a native marketplace integration and a custom build is significant in cost, in timeline and in who maintains it in two years. At your size there is usually a data warehouse question as well, and the answer to it changes the design.

Ask this: here is our full tech stack. Which of these are native HubSpot integrations, which need custom work, and who owns each one after go live? A prepared partner answers in the meeting. A red flag partner says they can connect anything without asking what you are connecting.

7. There is no handover pack, and no name against you after go live

Documentation is part of what a proper CRM setup engagement actually delivers. An engagement that ends with a configured portal and nothing written down has handed you a car with no manual. You know it works because someone turned the key. You have no idea what anything does or why it was built that way.

Real documentation is specific to your build. It describes your pipeline stages, what each workflow does and what triggers it, which properties are required and why, and how every integration is configured and authenticated. That is what lets your team change things without booking a call, and what makes bringing in a different partner survivable.

The same goes for the weeks after go live, which is when the real questions arrive: a workflow firing on the wrong contacts, a report that does not answer the question it was built for, a new starter who missed training. If the engagement stops at go live with nothing defined, you are on your own from the moment it gets interesting.

Ask this: show us an anonymised handover pack from another client, name our point of contact after go live, and tell us the response time and whether there is a structured check-in at 30 and 60 days. Then ask for two references: one client 12 months past go live, and one whose partnership has ended. The second call is the honest one.

What all seven have in common

Every red flag here is the same problem wearing a different hat: a provider selling a service they have already built, to a business they have not looked at yet. The tell is always in the detail, or the absence of it. Vague answers, a generic process, and confident reassurance that dissolves under one follow-up question.

A partner worth hiring does not mind hard questions. They have answered these before and they have the specifics ready, including the clause about who owns the code.

So here is the thing to do this week, and it has nothing to do with your shortlist. Go and find the IP clause in your last agency contract. If there is not one, what exactly did you buy?

We have answers to all seven and we will show you the contract language. Here is how NBH builds RevOps and HubSpot systems, or start with how to choose a CRM setup service in 2026. If you would rather just talk it through, start a conversation with us.

Our HubSpot tutorials are on YouTube.