If you run a channel, your partners, dealers or resellers are constantly asking your team for things. Is my deal registered? Has it been approved? What is my commission this quarter? Where is the latest datasheet? Each question is a small interruption, but multiplied across a partner network it becomes a full-time job for someone on your side. That someone is usually copying data out of your CRM, formatting it into an email or a spreadsheet, and sending it back. Your team is doing a system's job.
A custom partner portal replaces that work with software your partners run themselves. They register deals, submit the information you need, check status and commissions, and pull resources without going through a human. The portal sits on top of your CRM so the data they see is the same data your RevOps team works from. This post explains why these portals have to be built that way, what belongs inside them, and how to scope one without it sprawling into an open-ended product.
For the wider context on why mid-market B2B companies are moving to portals, start with our pillar on customer portals for mid-market B2B. This post is the channel-specific version of that argument.
Why a partner portal must sit on your CRM
The defining problem with channel operations is that the same record exists in several places at once. A deal a partner registered lives in their head, in an email to your team, in a spreadsheet your channel manager keeps, and eventually in your CRM. None of those copies agree for long. The partner thinks the deal is protected; your sales team has already logged it against a direct rep; the commission calculation runs off whichever version someone happened to export that month.
A partner portal solves this only if there is a single source of truth, and for a B2B services or product business that source is your CRM. When deal registration writes straight into the CRM as a deal or custom object, there is no second copy. When a partner views their pipeline, they are reading the live CRM record, filtered to what they are allowed to see. When commissions are calculated, they run off the same closed-won data your finance team already trusts. The portal is a controlled window onto the CRM, not a separate database that has to be reconciled.
Bolt-on PRM tools usually get this wrong. They hold partner data in their own system and sync it to your CRM on a schedule, which reintroduces the two-copies problem you were trying to remove. A custom portal built on your CRM keeps the CRM as the system of record and treats the portal as the interface. If you want the deeper version of this argument, our post on the build versus buy decision for customer portals walks through where off-the-shelf tools break down and when a custom build pays off.
What belongs in a partner, dealer or reseller portal
Channel portals tend to converge on the same handful of jobs. You do not need all of them on day one, but these are the journeys that earn their place.
- Deal registration. Partners submit opportunities, see whether a deal is approved or already claimed, and get a clear protection status. This is the most valuable journey because it removes the most disputes.
- Status and pipeline visibility. Partners see where their registered deals sit in your process without emailing for an update. Stage, owner and next step come straight from the CRM.
- Commissions and rebates. Partners view what they have earned, what is pending and what has been paid, calculated from the same deal and revenue data your finance team uses. No more quarterly spreadsheets passed back and forth.
- Submitting information. Onboarding details, certifications, marketing claims and end-customer information: structured forms that write into the CRM rather than landing in an inbox.
- Resources and enablement. Datasheets, pricing, contracts, brand assets and training, served from one place and kept current, so partners stop asking for the latest version.
The common thread is that every one of these is a read from or a write to your CRM. That is why the integration work is not an afterthought; it is the product.
Where this connects to your RevOps stack
A partner portal is only as good as the data feeding it, and that data rarely lives in one tidy place. Deals sit in the CRM, but commission rules might live in a finance system, product and pricing data in an ERP or PIM, and enablement content in a document store. A portal that pretends the CRM holds everything will show partners stale or partial information.
This is where the integration layer matters. The portal reads from and writes to the CRM, and the CRM in turn stays in sync with the surrounding systems. If your data foundation is shaky, that needs sorting first, because a portal will expose every gap in your CRM to the people you least want to show it to. Our work on managed RevOps keeps that engine clean and the process behind it sound, and our integrations practice is how the CRM stays connected to the rest of the stack. If you are mapping out what would need to connect, the guide to connecting systems with HubSpot is a useful starting point.
If the CRM data itself is the problem, that is a separate, prior piece of work: data engineering to model it correctly, or data migration if you are moving off a legacy system. Build the foundation, then put the portal on top of it.
How to scope a partner portal without it sprawling
The reason channel-portal projects fail is rarely the technology. It is scope. Someone wants tiered partner levels, then co-marketing budgets, then a lead-distribution engine, then a mobile app, and the project that was meant to ship in weeks turns into a multi-year programme that never quite launches.
The way to avoid that is to treat the portal as a productised build, not an open-ended product. SpotDev builds customer and partner portals as a fixed-price engagement from £15,000, launched in 30 days from contract signing, with working software typically within about two weeks and real users on it by day 30. That timeline is possible because the foundations and journey patterns already exist and an in-house engineering team adapts proven journeys to your brand, systems, data, fields, permissions, notifications and integrations. You usually pick three journeys to start, for example deal registration, status visibility and resources, and add more later. Extra journeys are £2,000 each and add about two days.
The 30-day commitment is backed in writing: if the agreed launch date is missed, SpotDev refunds the first payment in full and you keep everything built, with no clauses. That works only when scope is fixed, you give fast access to systems, and feedback comes back promptly. Some things sit outside this model on purpose: open-ended product development, complex legacy rebuilds, bespoke mobile-app functionality, data cleansing and unlimited integrations. Knowing what is out of scope is what keeps the in-scope build fast.
This approach suits a B2B services or product business in the £3m to £50m revenue range where partners chase your team for updates. It is not the right fit if you need a portal serving thousands of partner users with enterprise complexity on day one. SpotDev has built portals for clients including Superior, Wolsey Hall Oxford, Icon Solutions and L&DI.
Getting started
If your channel team is spending its week answering deal-status questions and rebuilding commission spreadsheets, a custom partner portal on your CRM is the systemic fix. The fastest way to know whether it is worth doing is to count how many of those questions land in your team's inbox in a normal week, then decide whether software should be handling them instead.
When you are ready to scope one, the commercial detail, fixed price and written guarantee live on our customer portals service page. If you would rather pressure-test the idea against your specific channel setup first, our diagnostics session is the place to start.
Frequently asked questions
Why build a partner portal on our CRM instead of buying a PRM tool?
A standalone PRM tool keeps partner data in its own system and syncs it to your CRM on a schedule, which means two copies of every deal that drift apart and need reconciling. A custom portal built on your CRM keeps the CRM as the single source of truth and treats the portal as a controlled window onto it. Deal registration writes straight into the CRM, partners read live records filtered to what they are allowed to see, and commissions calculate from the same data your finance team already trusts.
What journeys should a partner or dealer portal include?
The journeys that earn their place are deal registration, status and pipeline visibility, commissions and rebates, submitting structured information, and a resource or enablement library. You do not need all of them on day one. Most channel portals start with three, typically deal registration, status visibility and resources, and add more over time. Every one of these is a read from or write to your CRM, which is why the integration work is central rather than an afterthought.
How long does it take to build a custom partner portal?
SpotDev launches customer and partner portals in 30 days from contract signing, with working software typically within about two weeks and real users on it by day 30. That is possible because established foundations, reusable journey patterns and an in-house engineering team mean proven journeys are adapted to your brand, systems, data, fields, permissions and integrations rather than built from scratch. It depends on fixed scope, fast access to your systems and prompt feedback.
How much does a custom partner portal cost?
A SpotDev portal is fixed-price from £15,000, with £5,000 due on signing and the balance before launch. Hosting is billed by direct debit or recurring card. Additional journeys beyond the initial set are £2,000 each and add about two days. The 30-day launch is backed by a written guarantee: miss the agreed date and SpotDev refunds the first payment in full, with no clauses, and you keep everything built.
What is not included in a fixed-price portal build?
The fixed-price, 30-day model deliberately excludes open-ended product development, complex legacy rebuilds, bespoke mobile-app functionality, data cleansing and unlimited integrations. Keeping these out of scope is what keeps the in-scope build fast and predictable. If your underlying CRM data needs cleaning or remodelling first, that is handled as a separate piece of data engineering or migration work before the portal is built on top of it.
Stay Updated with Our Latest Insights
Get expert HubSpot tips and integration strategies delivered to your inbox.