
In Short: What Does a Fabric Consultant Actually Do?
Three things: work out what the business needs from its data, build the platform that delivers it, and leave your team able to run it. In practice that means facilitating the awkward definitional conversations, designing and building pipelines, lakehouse, governance and reporting, and transferring enough knowledge that you are not permanently dependent. A consultant who only does the middle part has sold you a dependency.

The Work Before Any Technology
The most valuable part of a good engagement usually happens before anything is built, and it does not look like consulting.
It is getting finance, sales and operations into a room to agree what "revenue" means. It is establishing which of three systems is authoritative for a customer record. It is asking which decisions the business actually wants to make differently, and working backwards from those rather than forwards from a platform.
This is uncomfortable precisely because it has never been done, and it is where most of the value is created. A platform built on undefined metrics reproduces the conflicting-numbers problem faster and more expensively than spreadsheets did.
If a prospective partner wants to talk about architecture before they have asked what decisions you are trying to make, that tells you something.
The Build
Once the questions are agreed, the engineering is reasonably well understood:
- Integration - connecting source systems and landing data reliably, with pipelines designed to absorb schema changes rather than break on them.
- Architecture - a medallion lakehouse where raw data is cleaned, conformed and made business-ready in defined layers.
- Semantic modelling - the layer where agreed definitions are enforced, and the difference between a model that performs and one that collapses under real volumes.
- Governance and security - row-level security, role-based access, classification and lineage, designed in rather than retrofitted.
- Reporting - the part the business sees, and the only part most stakeholders will judge.
The unglamorous middle items are where experience shows. Anyone can build a report; the difference between a platform that lasts three years and one that needs rebuilding in eighteen months is in the modelling and pipeline design.
Engagement Shapes
Assessment or readiness review - weeks, fixed price. Establishes what you have, what is achievable and what it would cost. Appropriate when the decision itself is unclear.
Fixed-scope build - the most common shape. A defined outcome, a defined price, typically six weeks to a few months. Suits organisations with a clear first problem.
Phased programme - a platform delivered in stages over quarters, each phase shipping something usable. Suits larger estates where a single scope would be guesswork.
Retained or managed service - ongoing capacity for maintenance and incremental work. Suits organisations with a working platform and no permanent BI hire - see our managed service comparison.
Training and enablement - sometimes instead of the above rather than alongside it. If you have capable people and no urgent deadline, this is frequently the better spend.
What Good Looks Like in the First 90 Days
A reasonable first ninety days ends with something in production. Specifically:
- Agreed priority use cases, in business language, written down.
- A working data foundation for the first of them - real sources, landing reliably, conformed.
- At least one report people actually use, not a demo.
- A roadmap for what follows, informed by what the first delivery revealed rather than written before it.
A discovery phase that produces only a document is the clearest warning sign in this industry. It is also the easiest thing to sell, which is why it happens.
What It Costs
Day rates vary substantially by market and seniority, and comparing rate cards is a poor way to choose. A fixed price against a defined scope is a far better basis, because it forces the supplier to think about the work rather than the days.
Our regional guides set out realistic budgets: the UK, the US and South Africa. Platform cost sits on top and is a separate question - see Fabric pricing.
One rule worth holding: be wary of any firm quotation given before someone has looked at your source systems. A price offered without seeing the data is a price that will change.
When you are ready to build a shortlist, our consultant guides for the UK, the US and South Africa compare the firms worth evaluating in each market.
Do You Even Need a Consultant?
Sometimes not, and a good partner will say so.
Training your own team is often better when you have capable analysts or engineers, no urgent deadline, and the work ahead is mostly building reports rather than architecting a platform. Ongoing report development is almost always better done in-house.
A consultant earns their fee when the architecture decisions are consequential and hard to reverse, when nobody internally has built one of these before, when the timeline genuinely matters, or when an external voice is needed to settle definitional arguments that have been running for years.
We have told prospective clients to train their team instead of hiring us. It is a better outcome than a platform nobody internally understands.
Questions Worth Asking Any Partner
These separate delivery firms from sales firms faster than a capability deck:
- Who will actually do the work, and will we meet them before signing? Pitch teams and delivery teams are not always the same people.
- What happens if the project overruns? The answer reveals how they price risk.
- Can you describe a time you advised a client not to buy your services? A firm that has never done this either has not been asked, or does not.
- How does this engagement end? A partner without an answer is describing a dependency.
- What will our team be able to do afterwards that they cannot do now?
Where Solv Systems Comes In
We are a Microsoft Partner specialising in Fabric, Power BI and AI, and we work the way described above: definitions before architecture, something in production inside the first phase, and skills transfer as a deliverable rather than a courtesy.
If you want to know what your specific situation needs - including whether it needs us - a free 30-minute consultation will get you a straight answer. Worst case, you get a second opinion at no cost before you shortlist anyone.
Sources and Further Reading
- Microsoft Fabric documentation
- Fabric lakehouse and medallion architecture tutorial
- Row-level security in Power BI
Frequently asked
Three things, in roughly this order: work out what the business actually needs from its data, design and build the platform to deliver it - pipelines, lakehouse, governance and reporting - and leave the internal team able to run and extend it. A consultant who only does the middle part has built you a dependency.
Day rates vary widely by market and seniority, and a fixed-price scope is usually a better basis for comparison than a rate card. Our regional guides set out realistic project budgets for the UK, US and South Africa. Be wary of any quote given before someone has looked at your source systems.
Often training, if you have capable people and no urgent deadline. Consultants earn their fee when the architecture decisions are consequential and hard to reverse, when the timeline matters, or when nobody internally has built one of these before. Ongoing report-building is usually better done in-house.
Something in production. A discovery phase that produces only a document is a warning sign. A reasonable first 90 days: agreed priority use cases, a working data foundation for the first of them, and at least one report the business actually uses - with the rest of the roadmap informed by what that revealed.
Ask who will actually do the work, and whether you will meet them. Ask what happens if the project overruns. Ask for a case where their recommendation was not to buy their services. Ask how the engagement ends and what your team can do afterwards. The answers separate delivery firms from sales firms quickly.
Define it before you start, in business terms rather than technical ones: a report that used to take four days now takes minutes, a question nobody could answer is now on a dashboard, a team that avoided the data now uses it weekly. Platform milestones are not outcomes.


