Partner enquiry
Start a partner conversation
The first conversation is a discovery session, not a pitch. We want to understand the archetype, the users and the constraints before anyone talks about scope. If it looks like a fit, the next step is a scoped pilot on one segment and one workflow.
What to bring to discovery
- The archetype you operate in and the users you serve.
- The surface the layer would sit behind, and whether you want white label, components or API.
- The workflows in scope for a first pilot.
- Residency, isolation and governance constraints that apply to your clients.
- Any existing system of record that should stay authoritative.
What happens next
- 01
Discovery
A working session on the archetype, the users, the surface the layer would sit behind, and the residency and governance constraints that apply.
- 02
Scoped pilot
One segment, one workflow, one tenant. Enough to prove the capability with real records rather than a demonstration environment.
- 03
Integration
The chosen deployment model is implemented: white label, embedded components, API, MCP or data exchange, with SSO and residency configured.
- 04
Launch and expand
Rollout to the wider user base, then extension into the remaining capability areas as the partner chooses.
Why discovery comes before scope
Every partner arrives with a surface that already works and users who already trust it. What is usually missing is the layer underneath: the mandate-aware assessment, the evidence that carries its sources, and the workflow that runs on the same record rather than in a second system. Which of those matters first depends entirely on where the current process breaks, and that is not something a proposal can guess at.
So the first session is diagnostic. We look at the journey a user takes today, the point at which work leaves the platform and reappears as a spreadsheet or an email thread, and what the partner is currently staffing to close that gap. The deployment model follows from that picture. A partner with a mature interface usually wants components or the API. A partner whose brand is the reason users trust the platform usually wants the white-label surface on its own domain.
What we will ask you
Four questions decide most of the design. Who your users are and what they are actually trying to decide. Where the record of truth lives today, and whether it should stay authoritative. What eligibility, residency and retention obligations you carry on behalf of your own clients. And what would have to change in user behaviour for the arrangement to be worth extending past a pilot. The last one is the most useful, because it converts a partnership into something measurable rather than something reviewed on sentiment.
The boundary, before you ask
Reuben AI does not hold client money, does not settle transactions, and is not a licensed administrator, trustee, custodian or registry. Where a step belongs to you or to a licensed third party, the layer records and coordinates it rather than performing it. It is not SOC 2 certified and will not be presented as certified in your procurement process. Tenant isolation, per-tenant residency selection, role-based access and configurable retention are described on the security and residency page so your risk team can read them before the call rather than after it.
Commercial structure works the same way. We do not publish partner economics, because deployment model, scope, support model and data direction move the terms materially. The reasoning is set out on the commercials page, and direct platform pricing for funds is published in full on the main site as a reference point.
Questions before you enquire
Is the first conversation a sales call?
No. It is a discovery session covering the archetype, the users, the surface the layer would sit behind and the constraints that apply. Scope and commercial structure come afterwards, because both depend on what that session establishes.
Who should be in the room?
Someone who owns the user relationship and someone who owns the platform roadmap. Where residency or client contracts are a constraint, bring whoever holds that obligation as well, because it shapes the deployment rather than being configured later.
Do we need engineering capacity to start?
Not for a referral or co-sell motion, which is a reasonable way to test demand first. White label, embedded components and API deployments each carry a different engineering commitment, which is one of the things discovery is for.
What does a pilot look like?
One user segment, one workflow, real records rather than a demo dataset, and a fixed review date. A pilot scoped wider than that usually produces an opinion rather than a decision.