Scaling a Partner Channel

I defined and led the product work for a platform that enabled external partners to onboard and manage more than 200 paying customer accounts. I focused the first release on three workflows that made repeated setup scalable: reusable widget templates, configurable commercial plans, and shared account visibility.

200+Paying customer accounts onboarded and managed by partners

~20 minObserved manual widget setup before reusable templates

My contribution was the product infrastructure that made the channel operable — built with one backend and one frontend developer — while Sales and the partners drove customer acquisition.

Context and responsibility

Raffle AI had secured agreements with two external partners, but the product did not yet give them a repeatable way to onboard and manage their customers. Existing setups were fragmented and individually configured.

I worked directly with the partners to turn their known operational needs into the smallest scalable product scope. I owned requirements, prioritisation, workflow decisions, scope, and delivery planning. The partners supplied needs and feedback, customer success supported the relationship, and engineering owned implementation.

This was needs-led discovery: the commercial opportunity already existed. The product question was how little we could build while still giving partners a reliable path from agreement to an operating customer account.

Problem and evidence

Three repeated problems made the existing approach unsuitable for a growing partner channel:

Account setup repeated the same configuration. Creating and configuring a website widget took about 20 minutes across multiple observed cases. Each partner typically reused a consistent group of settings.
Commercial agreements required technical intervention. Partner-specific features and consumption allowances could have been encoded in the backend, but every variation would then require more engineering work.
Account health was difficult to see. Partners needed to monitor customer activity, while Raffle AI needed comparable visibility for support and invoicing. Internal users still relied on direct database queries.

Before reusable templates~20 minCreating and configuring a website widget took about 20 minutes across multiple observed cases, repeating a consistent group of settings each time.

After reusable templatesA partner configures a widget once, then selects it as the template for later customer sub-accounts.

Repeated configuration became a one-time setup.Post-template setup duration was not measured, so no “after” figure is claimed.

The evidence established the bottlenecks, but it did not justify a broad partner portal. We had no defensible measure for future setup time, engineering time saved, or dashboard usage, so I kept those out of the success claims.

Options and decision

Option	What it optimised for	Decision
Keep extending one-off setups	Minimum upfront product work	Rejected. It preserved the operational bottleneck and made every new variation depend on the Raffle AI team.
A broad self-service partner platform	Anticipating every future partner model	Rejected. It would have delayed the workflows the two partners already needed and increased implementation risk.
A smaller reusable systemChosen	The shortest reliable path from agreement to an operating customer account	Reusable widget templates, configurable commercial plans, and one shared account-and-usage view.

That system rested on three decisions:

Reusable widget templates. A partner configures a widget once, then selects it as the template for later customer sub-accounts. This removed most repeated configuration while preserving partner-specific setups.
Configurable commercial plans. Sales can represent agreed features and consumption allowances inside the application, lock each plan, and expose only the relevant options during partner onboarding.
One shared account-and-usage view. The same information model serves partners and Raffle AI rather than creating separate external and internal monitoring products.

Product boundary: configuration + entitlement + visibility200+ partner-managed paying accounts enabled. Sales and the partners acquired them.

How the three workflows fit together: reusable templates and configurable plans feed partner onboarding, and one shared account-and-usage view covers the accounts that result.Recreated system diagram based on the verified workflow. It is not a screenshot of Raffle AI’s interface and contains no customer or partner data.

Trade-offs

Reusable systems require more upfront definition than one-off fixes. Configurable plans moved entitlement logic into the product, and the shared dashboard had to satisfy both external and internal needs without becoming two separate experiences.

The main scope trade-off was deliberate: prioritise a reliable happy path and cut features that were not required for partners to operate at scale. This reduced time to the first useful release, but it also meant the platform would evolve from real operating needs rather than attempting to anticipate every future partner model.

Execution

I translated partner and commercial inputs into workflows, negotiated the boundary between flexibility and implementation effort with engineering, and sequenced the work around the critical onboarding path.

The core platform shipped in January 2026. It provided the repeatable onboarding foundation: reusable configurations and selectable commercial plans. The account-and-usage dashboard followed in Q2, adding visibility across the accounts partners were now operating.

The staged release mattered. Partners did not have to wait for the complete monitoring experience before they could start onboarding customers, while the later dashboard used the account model already established by the core platform.

Result and limits

The platform enabled partners to onboard and manage more than 200 paying customer accounts. Across Raffle AI, total customer accounts grew from approximately 100 to more than 300, with most of that growth occurring from January through June 2026.

That is an enablement result, not an acquisition claim. Sales and the partners acquired the customers; leadership initiated the channel; engineering built the platform. I led the product definition and delivery decisions that made this category and volume of accounts operationally supportable.

The number I stand behind is 200+ partner-managed accounts. Setup time, plan configuration, and dashboard usage improved in practice, but none of that was measured, so I treat those as observed effects, not quantified gains — and the exact January/June account boundary hasn’t been reconstructed.

Learning

My main lesson was that “platform” does not have to mean broad scope. In this case, scale came from finding the few repeated decisions that should become reusable product capabilities: configuration, entitlement, and visibility.

Separating channel acquisition from platform enablement also makes the result more useful. The commercial team proved demand; the product work made serving that demand repeatable.

Evidence note

This case study uses verified interview evidence covering the partner-platform problem, the pre-change setup observation, the product decisions, release sequence, account definition, and contribution boundaries. Partner names and internal product material are omitted. The diagram is an anonymised recreation of the system logic, not a product screenshot.

Read Owning Product at Raffle AI for the company context, my formal authority, and the wider product scope behind this focused story.