For Fabric and Power BI consultancies, MSPs and data advisers
You do the build. We supply the operating model.
Every Fabric or Power BI engagement ends the same way: the platform works, and the customer asks who owns this number now. You answer it in a Word document nobody opens again. Lake On Rails is the repeatable answer — populated, left behind, and still being logged into after you have gone — with the product engineering you don't keep in-house for whatever it turns up.
Halesowen Components
Northfield Care Group
Tyseley Logistics
Support and quarterly reviews become a list rather than a set of logins.
Who we are looking for first
Five partners in the first year
The programme is new and the first partners will shape it. We would rather do it properly with a few than badly with many.
First
Fabric and Power BI consultancies without an app-development team
Your customers are exactly the businesses this was built for, and the engineering gap is one we can fill.
Next
MSPs with an active data or AI practice
An ongoing improvement service to sell alongside the platform you already manage.
Selectively
Independent data advisers and fractional CIOs
A tangible thing to leave behind, and an engineering team on call.
Later
Infrastructure-only MSPs
When a live customer problem creates a clear fit.
What the programme gives you
A conversation-starter for every past client
The ten-signs scorecard on our home page, offered under your name: ten questions, two minutes, and a reason to talk again about the operating model you both knew they needed.
A populated instance in minutes
A new customer workspace comes with the register structure, tier criteria, responsibility matrix, seven procedures, workflows and courses already in place. Day one is spent on their data, not on setup.
Scoping built in
The capability map shows, per platform, what the cloud covers and what needs a human decision. It scopes your engagement as much as it scopes the product.
A discovery you can productise
A fixed-scope discovery, with a register, a named owner per line and defined tiers as the deliverable. You deliver it; the customer keeps the output whether or not they buy the platform.
Cross-customer visibility
A partner view across the instances you deliver, so support and quarterly reviews are a list rather than a set of logins.
An AI story you can actually stand behind
An MCP server and a REST API, on Professional and above, so your customer's Copilot, ChatGPT, Claude or your own agents can read the model and draft the documentation nobody has a fortnight to type. Off by default, narrow named scopes, and every proposal lands in a review queue with its reasoning attached. What it does and what bounds it.
Engineering when the model finds something
A depot manager sending operational data in inconsistent spreadsheets. An API to replace duplicate entry. A supplier portal. You qualify it; Scorchsoft estimates and builds it, with you leading the proposal.
The bit worth being blunt about
Where we stop
You have probably been introduced to a "partner" before and watched them turn up on your account six months later selling managed services. We would rather set the boundary out here, in public, where you can hold us to it — and where you can send it to whoever at your firm is going to be suspicious of this, because they are right to be.
Whose customer it stays is your decision, not ours
Both of these are supported, per account, and whichever you pick goes into the partner terms before the first introduction rather than being implied.
If you stay in front Default
Your customer stays your customer
You remain the commercial lead. We register the account to you, we do not contact your customer without you, and we do not pitch development work to them unsolicited. When the operating model surfaces something that needs building, you qualify it and lead or join the proposal.
If you would rather hand it over
We take the relationship, you take a referral fee
Some firms want the introduction to be the end of their involvement, and would rather not carry a service they do not deliver. Say so and we contract with the customer directly, on a referral fee for what follows. It is a way of working, not a failed partnership.
Or anywhere between the two: you keep first line and the quarterly review while we hold the product relationship. What we will not do is leave it unsaid until the first time it matters.
Your centre of gravity
Operating the estate and the platform
- Tenancy, identity, Entra, licensing
- Network, cyber, endpoint, compliance assurance
- Fabric capacity, workspaces, Purview guardrails
- Service desk, monitoring, incidents, 24/7 where you sell it
- The customer relationship and the commercial lead
Ours
The operating model, and product engineering
- Lake On Rails: the product, its updates and its support
- Bespoke applications, APIs and the ingestion a product owns
- AI inside a product: agents, MCP servers, business logic
- Working inside a workspace you own, to your standards
Genuinely shared
Scope it together, name one owner
Identity and permissions, data classification, the security boundary around a workspace, audit, and the handover from platform to product. Pretending there is no overlap here would be the dishonest version. Azure, Fabric, data engineering and AI can each sit either side depending on the outcome being owned.
Every piece of work gets one boundary, one price basis, one documented handover and one accountable owner — even when both firms are in it.
The decision rule, when it is not obvious
Place the work by operational ownership and risk, not by the name of the technology. If it is tenant-wide control, formal assurance or something that has to be watched at three in the morning, it is yours. If it is bespoke logic, a user interface, an API or ingestion that a product owns end to end, it is ours. If it spans both, scope it jointly and still appoint one of us as the accountable delivery owner. We treat the map above as a hypothesis to check with you, not a statement about where your boundaries are — you know your practice better than we do.
The questions partners actually ask — support, tenant access, direct enquiries, white-labelling — are answered further down this page.
How the money works
Referral or subcontract to start. Resale when you want to sell it.
We would rather begin simply and let the terms follow the work. The share is set by what each party carries, and we do not stack a referral commission on top of a reseller discount for the same sale. White-labelling and annual partner fees are deferred until repeated use justifies them.
| Income | Your role | Scorchsoft's role |
|---|---|---|
| Product subscription | Referral or resale; hosting and first-line support where agreed | Product ownership, updates and defined support; hosting depends on the deployment model |
| Adoption and reviews | Lead the workshops and own the customer relationship | Set-up support and specialist work to an agreed scope |
| Bespoke development | Qualify the need; lead or join the proposal | Estimate and deliver integrations, applications and automation |
Where the customer needs Lake On Rails in their own Azure subscription, you can operate the deployment. We agree in writing who patches, backs up, monitors and responds. The three hosting models.
Before you ask us
What partners ask first
The four that decide it, answered here. The rest — how this sits with governance consulting you already sell, whether it undercuts your Purview work, and the commercial detail — are on the questions page.
Who supports the customer, and who do they call?
Agreed per partnership, in writing, before the first customer goes live. Most partners want first line and to keep the relationship; we take product defects and anything that needs a change to the software. What we will not do is leave it ambiguous — one boundary, one price basis, one documented handover per service, so the customer never has two suppliers each assuming the other has it.
Do you need admin access to our customer's tenant?
No. The standard service is hosted by us and reads technical metadata only — dataset names, schemas, owners, refresh times — through a connection your customer authorises and you can scope. Where it runs in the customer's own Azure subscription, you can operate it: we agree in writing who patches, backs up, monitors and responds, and it can be entirely you. Our own people's logins are flagged as ours, do not consume the customer's seats, and appear in the same audit trail as everyone else.
What if our customer wants to buy directly from you?
They can ask, and we will tell you. If you introduced them, the account stays registered to you and the referral or reseller position stands whichever way the paperwork goes; we do not treat a direct enquiry as a way out of that. We would rather lose one sale than have a partner conclude we are a risk to their accounts.
Can we white-label it?
Not today. White-labelling and annual partner fees are deferred until repeated use justifies them, and we would rather say that than sell you a roadmap. What exists now is a cross-customer partner view, a populated instance per customer, and the ten-signs scorecard offered under your name as a conversation-starter with past clients.
Start the conversation
Tell us about your practice, and one live account
What you deliver, for whom, and on which platforms. If there is one customer right now where unclear ownership, unreliable reporting or an upcoming platform change is causing difficulty, say so; that is where the first conversation is most useful. A person replies by email.