Our Approach

First movement: find the question

Second movement: answer it

The work itself hasn't changed

Build, buy, or configure

A finished product

Your data on their platform

Because nothing else can

Why this is a difficult thing to buy

Tells you what is wrong

Builds what you asked for

What finished means

What we decline

Three ways to buy this work

Three ways to buy this work

Who does the work

Where it starts

What you hold at the end

How the recommendation is shaped

Best fit

We have no platform of our own to sell you

Mid-market work is not a smaller version of enterprise work

Build us a report finance and operations can both work from.

Two departments, two defensible methods, one figure that has never matched. No report settles that.

What stops reconciling the day we switch the old system off?

The platform move was well understood. The forty things quietly reading from it weren't.

Twelve views existed and four were opened. The rest reported categories rather than the work somebody picks up.

Not a requirements workshop. We attend the meetings where the argument already happens and record who says what. Most organisations have diagnosed themselves already, in fragments held by people who don't speak to one another.

One order, one claim, one deal, one close. End to end, without shortcuts. The gap between the documented process and the real one is where the problem almost always lives, and it doesn't appear in any extract.

One sentence, no conjunctions. If it can't be written that way it hasn't been understood yet. This is the deliverable clients remember, and it's regularly uncomfortable to read.

Step by step, with what each one is for. Often less than was requested. Sometimes no build at all, because the question can be answered without one. Occasionally nothing, because the answer is a decision that has been avoided and no system substitutes for making it.

Built small and tied to decisions somebody makes on a schedule, then maintained rather than handed over and abandoned.

Several systems reconciled into one place that returns the same answer to everybody who asks the same question.

Dependency mapped first, rehearsed at real volume, with reporting repointed on the day rather than discovered missing after it.

The contested terms written down, applied once, with a clear trail back to the source in a form somebody outside can read.

Configured around how a team actually sells, with reporting live from the first day and training in their language.

Analysis and modern capability inside boundaries where nothing is permitted to leave, with governance written alongside the build.

Answers grounded in your own documents with a citation somebody can check, and a written rule for what the system refuses to answer and who it escalates to instead.

Repetitive processing, extraction and multi-step handoffs, designed around the exception queue rather than the happy path, with an audit trail per item.

Whether the data can support the idea at all, established on your own records in weeks rather than discovered six months into a build. Frequently ends in a recommendation not to proceed.

If you already know it's a dashboard, the outcome has been decided and we would only be renting you hands. Plenty of firms will do that well and for less.

Being engaged to produce the conclusion the sponsor arrived with is a real request, politely made, and not one we take.

An answer without an owner changes nothing, and we would rather not be paid to show that again.

There's no pyramid here to feed, which is the point, and it means some engagements are simply too large for us.

An assistant over four definitions of revenue answers the same question four ways, faster, and with the provenance stripped off. We'll do the definitions first or we won't do it.

If the invoices arrive in nineteen formats because nobody has ever asked the suppliers to change, automating that makes the fault permanent and harder to see. The finding is unwelcome and worth more than the build.

Content goes stale, upstream systems change, accuracy decays quietly. Without an owner and a budget line for year two, we would be building something with a timer on it.

Every Thinklytics engagement has one written question. The first movement finds it and is priced separately. The second answers it, and usually that means building something.

One written question, found before anything is scoped, then answered. Two movements, priced separately.

The first movement finds that question and is priced separately. The second answers it, and usually that means building something, because that's what this practice has always done. What is new is that nothing is scoped before anyone knows what is being asked.

The question decides the deliverables, rather than the other way round.

Each of these was a real request, and each would have been delivered on time exactly as written.

The roadmap is assembled for the question rather than taken off a shelf, so no two have matched yet. Length is set by what the question turns out to need, which is why these show the shape of the work and not a schedule.

The build is chosen by the question rather than assumed before it, and it's usually where most of the work sits.

Both roadmaps end in something real. One produces an automated reconciliation, the other a figure you can reproduce and a clear trail back to where it came from. Neither ends in a document nobody acts on.

Everything below is work this practice has done for seven years and still does.

Which of these an engagement produces is decided by the question, and most produce more than one.

Nearly every capability arriving now can be bought finished, assembled on somebody else's platform, or built. The question is asked as build versus buy, which omits the option most organisations belong in.

Which one an engagement lands on is decided in the first movement, in writing, with the reason recorded.

Right when the process really is standard, which is more often than people like to admit. Fast and cheapest to start, and you accept someone else's definitions and workflow. The cost shows up later, when your exception turns out not to be an exception the product has.

Your definitions, your workflow, infrastructure somebody else maintains. Most sensible work sits here and it's underrepresented in vendor material, because it's less profitable to sell than either of the alternatives.

Justified when the capability is the differentiator, when the process is the advantage and no product fits it, or when the data can't leave your boundary at all. Building because a platform didn't quite fit is how organisations acquire software they have to staff forever.

The failure isn't choosing wrong. It's choosing without writing down which one was chosen and why, so that in eighteen months nobody can say whether the thing being maintained was ever meant to be.

Arrives, diagnoses well, produces a document, leaves. You're then holding a correct answer and no way to act on it, and the second firm you hire has to be told everything again from the beginning.

Arrives, builds it properly, invoices, leaves. Nobody in the room was ever paid to ask whether the thing being built was the right thing, so nobody did.

The person who worked out what was wrong is, in every engagement, the same person who

Nothing is lost being explained to a second firm, and nothing gets built before somebody has been accountable for asking whether it should be. We've always done the building. What is new is refusing to start there, and that combination is only available from a practice small enough that the same people stay on the work.

Finished means the question is answered and the answer will still hold next quarter.

Not that something was handed over. A dashboard can be delivered, accepted and invoiced while the question that prompted it stays exactly as open as it was, and both sides can call that a success. Under this arrangement neither of us can.

Whether the close actually gets faster depends on decisions your people make after we go, and we won't pretend to control that. What we're accountable for is that the answer is correct, that it's reproducible, and that it doesn't quietly rot the first time somebody renames a field.

Where the answer involves a model, finished additionally means it can be checked and it can be monitored.

That the output cites the source it came from, that an evaluation set exists and is held by you, that somebody is named to keep the underlying content current, and that the year-two running cost was written down before anything was built. A system nobody can audit and nobody maintains isn't finished, however well it performs the week it ships.

The question is written down early and doesn't move after that.

If it turns out to be the wrong question, that's a finding worth having, and we reopen it in front of you rather than adjusting it quietly to match what we found.

All three are the right answer to some question. More on where each one fits in

A free hour with a senior practitioner who will do the actual work,

Enough to establish whether there's work here, whether it's ours, or whether you should be speaking to somebody else entirely.

Who does the work, A global strategy firm: Senior partners scope it, and a delivery team staffed separately carries it out.

Who does the work, Staff augmentation: Contracted engineers work to a backlog somebody else defined.

Who does the work, A senior boutique, us: The person who sits in the meeting where two directors disagree writes the semantic layer that settles it.

Where it starts, A global strategy firm: With the portfolio and the operating model, which is the right place when the question is which bets to make.

Where it starts, Staff augmentation: With the ticket, which is the right place when the design is already settled.

Where it starts, A senior boutique, us: With one written question, and the data underneath it, before anything is scoped.

What you hold at the end, A global strategy firm: A recommendation and a plan, which still needs somebody to build it.

What you hold at the end, Staff augmentation: Working code, and the knowledge of why it was built that way leaves with the contractor.

What you hold at the end, A senior boutique, us: A running system, the definitions it enforces, and a named owner on your side.

How the recommendation is shaped, A global strategy firm: Vendor-neutral at the strategy layer, and usually silent on implementation detail.

How the recommendation is shaped, Staff augmentation: Shaped by the skills on the bench this quarter.

How the recommendation is shaped, A senior boutique, us: We build on the platform you already run, and we will tell you when the answer is to change nothing.

Best fit, A global strategy firm: A large organisation deciding where to place several bets at once.

Best fit, Staff augmentation: A clear backlog and a design you are confident in.

Best fit, A senior boutique, us: Systems disagreeing about the same number, or AI work blocked on the data underneath it.

We have no platform of our own to sell you. A firm that sells one platform will find a reason for that platform. The only useful version of this claim is one a reader can verify, so here is where to look rather than a sentence asking to be believed. We publish named practices on platforms that compete directly with each other, and a selection tool that scores three warehouses against one another instead of steering to one.

Two competing warehouses, two practices. Snowflake and Microsoft Fabric each have their own practice page, and the warehouse selection tool at /tools/data-warehouse-selection scores Fabric, Snowflake and Databricks against your workloads rather than recommending one of them by default.

Two competing BI tools, two practices. Tableau and Power BI both have their own practice, including the server and migration work on each side. A firm that only knew one would publish only one.

The integration practice is named for it. Vendor neutral system integration is a service, not a slogan, at /services/vendor-neutral-system-integration. Twenty routed practice pages span Snowflake, Fabric, Tableau, Power BI, Salesforce, SAP, MuleSoft and Heroku.

What this costs you if we are wrong. A recommendation that suits us and not you is the expensive kind of advice, because the platform decision sets your cost base for years. The check is the service list, and the time to run it is before you sign anything.

Mid-market work is not a smaller version of enterprise work. Through 2026 several of the largest consulting and integration firms launched packaged units aimed below the enterprise, so a mid-market team evaluating this work will now see options that were not on the table before. That is a real change and worth knowing about. What a package standardises is the method. What it cannot standardise is who turns up, and on a team of this size that is the part that decides whether the work lands.

The person who scopes it stays on it. The same senior person who sits in the meeting where two directors disagree is the one who writes what settles it. There is no second team that the work is handed to once the scope is signed.

A smaller estate is not an easier problem. Fewer systems usually means fewer people who own them, less documentation, and one person holding the history in their head. The work is narrower in scope and no shallower in diagnosis.

Scoped by deliverable, not by headcount. The engagement is priced against what you hold at the end. That is what makes a scoped piece of work buyable by a team that does not have a transformation budget.