14 September 2026

What we learned building a 500-partner portal

Lessons from BB99 — a franchise platform onboarding home-based partners across India. Qualification flows, per-partner sites, and the operational realities nobody scopes for.

  • Case study
  • B2B

BB99 is the franchise arm of the Saffron Decor group, and the proposition is unusual: run a blinds business from home. No showroom, no inventory, no royalty. The platform’s job was to sell that to a very large pool of prospects, filter it down to serious applicants, and then support the ones who became active partners.

We designed and built it. Here is what the work actually taught us — most of which applies to any dealer, distributor or franchise platform.

Lesson 1: the funnel is the product

The instinct on a B2B platform is to build the portal first and the marketing site second. That is backwards when the business runs on recruiting partners.

The bulk of the value sat in the public pages: an objection-answering scroll on the home page, segment-specific landing pages for interior designers, carpenters, students and service providers, and honest numbers placed above the fold rather than buried.

Each audience arrives with a different reservation. A carpenter already has customers and wants product. A student has time and needs credibility. Writing one page for all of them produces a page that convinces nobody.

Transferable rule: if your platform recruits, treat the recruitment pages as the primary build and the portal as the second phase.

Lesson 2: qualify before a human is involved

Volume is only useful if it is filtered. The application flow asks the questions a sales conversation would ask — location, existing network, time availability, capital position — and sorts applicants before anyone picks up the phone.

This single mechanism is what makes a large top-of-funnel manageable for a small operations team. Without it, the team spends its day on people who were never going to convert, which is how good platforms quietly fail.

Transferable rule: every field in the application should either qualify the applicant or be required to serve them. Everything else is friction with no return.

Lesson 3: partners need proof more than features

Early feedback made this obvious. Prospective partners were not evaluating the portal’s capability. They were evaluating whether the opportunity was real.

Testimonials from named partners, concrete earning ranges, the specifics of what is provided and what is not — these moved applications far more than any additional feature. The most valuable thing we shipped in one iteration was a clearer explanation of what the partner does not have to pay for.

Transferable rule: in a partner platform, credibility work outperforms feature work until trust is established.

Lesson 4: per-partner sites earn their complexity, if you provision them

Each active partner gets their own site, targeted at their city’s search intent. A page about blinds in a specific city outranks a national page for that city, reliably, and the partner gets leads they can service.

The engineering is straightforward. The operational reality is not: partners do not write content. A blank site with a partner’s name on it is worse than nothing, because it ranks for a moment and then rots.

What worked was provisioning each site with complete content already in place, keeping editing limited to the handful of fields a partner genuinely needs to change, and centralising anything that should stay consistent. The equation is the same one in our SEO playbook — local intent is winnable, but only with a real page behind it.

Transferable rule: never ship a per-tenant page that depends on the tenant to become useful.

Lesson 5: the admin side is not an afterthought

Every hour the operations team cannot act without a developer is an hour of dependency you have sold them. Approving an applicant, updating a resource, changing pricing, checking status — all of it belongs in an interface.

This is where partner platforms usually run over budget, because the admin side is invisible in a design review and enormous in scope. We price it explicitly for exactly that reason, and the reasoning behind those bands is in what we charge.

Transferable rule: count your user roles before you estimate. Partner, prospect, operations and admin is four products sharing a database.

Lesson 6: support load is the real metric

A portal succeeds when the phone stops ringing about things the portal covers. So the useful measurement is not logins or sessions. It is the volume and topic of support contacts.

Pull the top five questions partners ask, and design each one out of existence — with a status view, a clearer resource, or a notification sent before the question is asked. That is a far better roadmap than a feature list assembled in a meeting.

Lesson 7: scope the process, not the screens

The longest part of this build was not engineering. It was establishing what actually happens between an order being placed and a partner being paid — and discovering that the description differed depending on who we asked.

Every operational platform has this gap. The way through it is to write the process down, walk it with the people who run it, and only then design screens. It is the same argument as the one-page spec, applied to operations rather than features.

What we would do differently

Instrument earlier. We added detailed funnel tracking after launch. Having it from day one would have answered “which segment converts” weeks sooner.

Build the operations view first. We built partner-facing before operations-facing. Reversing that would have shortened the first month after launch considerably, because the team could have run the process before the volume arrived.

Write the runbook during the build. We wrote it at handover. Writing it as we went would have caught two gaps in the process that only surfaced when somebody tried to follow the steps — a habit we now apply to every project, as described in what happens after we ship.

The short version

Partner platforms are operations projects wearing a software costume. The interface is the easy part. The value is in filtering the funnel, removing support load, and giving the operations team controls they can use without asking for help.

See the full build in the BB99 case study, or tell us about your dealer network and we will tell you what the first phase should be.

? COMMON QUESTIONS

Questions people actually ask.

What does a partner or dealer portal actually need?

Four things at minimum: a qualification flow that filters applicants before a human is involved, a resource library the partner can self-serve from, a status view so partners know where their orders and requests stand, and an admin side where your operations team can act without calling a developer. Everything else is refinement.

How long does a partner portal take to build?

A focused first version is six to ten weeks. The interface is rarely the long pole — mapping the real operational process is, because most businesses discover during scoping that the process differs between the person who described it and the people who run it.

Should each partner get their own website?

It works well when partners sell locally and search intent is city-specific, because a page targeted at one city outranks a national page for that city. It works badly when partners cannot maintain content, so provision the site with real content already in place and keep editing simple.

What breaks first in a partner platform?

Support load. A portal that answers questions reduces calls, and a portal that half-answers them increases calls, because partners now have two places to be confused. Design the top five questions out of existence before adding features.

3 RELATED READING

Next to this one.

NEXT STEP

Have a product to ship?

Start a project ↗ hello@napdesigns.com