Keeping Your Consulting Methodology in an AI Platform

Yes, an advisory firm can keep its own methodology, storyline conventions and templates when it adopts an AI strategy platform, and the output does not have to look like everyone else's. The outcome depends on one discipline: separating your method into distinct layers, because frameworks, storyline rules, visual templates, house language, quality gates and source hierarchies transfer to software in different ways. Configure the layers that are genuinely structural, and keep the layers that are judgement firmly with your people.

An AI strategy platform doesn't have to produce generic deliverables. By deconstructing your firm's methodology into configurable layers like storyline conventions and slide grammar, you can automate structure while keeping analytical judgement strictly in human hands.

The concern is well founded. In a field experiment with 758 consultants at Boston Consulting Group, Dell'Acqua et al. found that while AI-assisted participants produced higher-quality ideas, there was "a marked reduction in the variability" of those ideas compared to those not using AI, which the authors read as a tendency towards "more homogenized outputs".^[1] For a firm whose product is its point of view, that finding deserves attention. If every competitor points the same models at the same briefs, undifferentiated AI use erodes exactly what clients pay a premium for.

The remedy is not to avoid the tools but to treat your methodology as something to be specified, configured and tested rather than left to the model's defaults. The rest of this article sets out how to do that, and gives you a checkable protocol you can run before committing to any platform.

A firm's methodology feels like one indivisible thing, but it is really several layers stacked together, and they do not transfer to software in the same way. Writing them down separately is the first step, because it converts a vague anxiety about losing "our way of working" into a concrete list of rules you can configure, test and sign off. Six layers cover most advisory practices:

• (a) Frameworks and analytical approach: the proprietary models, diagnostic sequences and hypotheses that structure how you attack a problem, and that clients are often specifically buying.
• (b) Storyline conventions: the rules that govern how an argument is built and told, such as the pyramid principle, answer-first communication, action titles and one idea per slide.
• (c) Visual templates and slide grammar: master layouts, colour and typography, chart conventions, page furniture and the placement of sources and footnotes.
• (d) Terminology and house language: the words you use and avoid, how you name phases and roles, and the tone that makes a document recognisably yours.
• (e) Quality gates and sign-off steps: who reviews what, against which criteria, before anything reaches a client, and who is accountable at each gate.
• (f) Source hierarchy: which evidence the firm trusts, in what order of preference, and what may never be cited as a basis for a recommendation.

The layers differ in how far they can be delegated. Storyline conventions, templates, terminology and source hierarchy are largely explicit rules, which is what software is good at following. Frameworks and quality gates contain tacit judgement, which is where the human contribution stays. Keeping that distinction in view prevents both failure modes: handing everything to the tool and losing your distinctiveness, or refusing the tool and losing the efficiency your competitors are gaining.

Most of what makes a deliverable recognisably yours sits in layers (b), (c), (d) and (f), and these are exactly the layers a well-designed platform can be configured to follow. Storyline conventions are the clearest case. Barbara Minto's pyramid principle, developed during her time at McKinsey, holds that clear writing has a pyramidal structure: a governing thought at the top, supported by ideas grouped in a logical order, each level summarising the one below.^[2] Rules of this kind are explicit and checkable, which makes them suitable for encoding in a platform: every slide title a full-sentence conclusion, one idea per slide, the answer stated before the evidence.

• Storyline rules: pyramid structure, answer-first flow, action titles and the one-idea-per-slide constraint can be set as generation rules rather than left to the model's taste.
• Visual templates: your master layouts, colour palette, typography and chart conventions can be applied to the generated deck, so the output opens in your house style rather than a generic one.
• Terminology: house vocabulary, preferred phrasings and banned words can be specified, so the document reads in your voice.
• Source hierarchy: you can define which sources the platform may rely on and in what order of authority, so the evidence base reflects your standards rather than the open web's defaults.

Configuration of this kind is not cosmetic. When the structural rules are set by you, the platform's baseline output starts from your conventions instead of drifting towards a house style that belongs to nobody. The practical implication for procurement is simple: ask each vendor to demonstrate, on your own template and your own storyline rules, how their configuration works, and treat any answer that amounts to "the model knows how consulting decks look" as a warning sign.

Some layers should not be handed over, however well the platform performs. Your proprietary frameworks and analytical approach are the core of what clients buy, and they embed judgement that only your senior people can exercise: which hypothesis matters, which tension in the data is the real story, when the framework needs to be set aside. A platform can execute a framework you specify; it cannot originate the judgement about whether the framework fits this client's situation.

• Framework selection and adaptation: choosing the analytical approach for this engagement, and adapting it where the client's reality does not fit the model.
• Interpretation of findings: deciding what the evidence means for this client, and which trade-offs the recommendation should weigh.
• Quality gates and sign-off: the review steps in layer (e) exist precisely because someone senior is accountable for what leaves the building, and that accountability cannot be delegated to software.
• The client relationship: the conversations, trust and context that shape what advice will actually be heard, none of which a platform participates in.

A useful way to frame the division of labour: the software structures the argument and assembles the evidence, while the advisory team owns the judgement, the relationship and the final sign-off. If a vendor's pitch implies that the platform replaces partner review, that tells you they have not understood what a quality gate is for; it is worth settling explicitly how much human review an AI strategy deck needs before anything reaches a client. The test in the next section gives you a way to verify where a platform's capabilities genuinely end, before you commit.

Claims about configurability should be tested, not believed. The protocol below slots into a broader pilot approach: if you are evaluating a platform in full, it complements the back-test method described there, which scores platform output against the deck the board actually saw. The methodology transfer test narrows the focus to one question: does the output still read as your firm's work? It runs in six steps.

1. Write the inventory. List your method across the six layers from the section above, and give each layer at least one concrete, checkable rule. "Use clear language" is not checkable; "every slide title is a full-sentence conclusion stating the takeaway" is.
2. Pick one completed past engagement whose outcome you know. Choose one where the deliverable was well received, so you have a genuine benchmark, and where confidentiality allows internal reuse of the documents.
3. Configure the platform with the inventory and run the original brief and documents through it. Set up the storyline rules, templates, terminology and source hierarchy exactly as you wrote them, then let the platform produce its output from the same starting point your team had.
4. Score every rule. For each rule in the inventory, record whether it was carried, partially carried or lost. Be strict: a rule that appears in most slides but not all is partially carried, not carried.
5. Run a blind partner review. A partner who did not run the test reads the platform output next to the original deliverable and answers one question: would a client recognise this as our work? Record the answer and the reasons, in the partner's own words.
6. Decide. Lost rules in layer (a), frameworks, or layer (e), quality gates, are blockers: they touch judgement and accountability, and a platform that cannot honour them is not ready. Lost rules in layer (c), templates, or layer (d), terminology, are configuration work: they are explicit rules, and failure is a setup problem to fix and retest.

The decision rule matters more than the scores. It separates the failures that should stop a purchase from the failures that should stop a rollout meeting, and it gives you a documented basis for either decision. If you want a deeper protocol for scrutinising the output itself once the platform is configured, the approach in fact-checking an AI-generated strategy deck pairs well with step four.

The following example is an illustrative hypothetical, not a record of a real engagement, and the figures in it describe a scenario rather than reported results. Imagine a 12-person boutique known for a proprietary pricing-diagnostic framework: a four-stage sequence from margin mapping through to negotiation levers, with its own storyline conventions and a strict source hierarchy that privileges transaction data over survey estimates. The partners run the methodology transfer test on a completed engagement before committing to a platform.

Note what the exercise changed. The lost terminology rule was a configuration gap, not a platform limitation, and the fix took one re-test. The partially carried template rule revealed that "use our palette" had been too vague to configure, which is itself a finding about the firm's own documentation. The quality gate was never offered to the platform in the first place, because the partners had already decided that layer (e) is not negotiable. The blind reviewer's answer, in this hypothetical, was that the output would pass as the firm's work once the terminology fix landed.

Decisity is an AI-native strategy consulting platform built for exactly the configuration challenge this article describes. It is configurable to a firm's storyline conventions and formatting, so the output reads as the firm's work rather than the platform's, and it applies the pyramid principle, action titles and one idea per slide as method defaults. Every claim, number and recommendation in a Decisity deck is traceable to its source, with a full audit trail from conclusion back to evidence, and that source-tracing persists so a decision can be re-examined later against the evidence it rested on. Client documents are not used to train shared models, which matters for any firm configuring proprietary frameworks in the platform.

For advisory firms, the practical sequence is the one set out above: write the inventory, run the methodology transfer test on a completed engagement, and let the scores rather than the sales conversation decide. Configured and tested this way, a platform should leave your methodology more explicit than it found it, and the deliverables unmistakably yours.

Related reading:

• Disclosing AI to Clients: Engagement Letters for Consultants
• How to Pilot an AI Strategy Platform: The Back-Test

• Dell'Acqua et al.: Navigating the Jagged Technological Frontier (Harvard Business School Working Paper 24-013, 2023)
• Think Insights: The Pyramid Principle (Barbara Minto)