TL;DR: Independent consultants and small firms lose hours a week to research grunt work: searching for sources, summarizing reports, reformatting notes into client-ready language. The big firms already automate this: McKinsey built an internal tool called Lilli that 70% of its 45,000 employees use roughly 17 times a week. You do not need McKinsey's budget to get the same edge in your own practice. You need a weekend, your existing files, and a five-step build sequence I call the FOCUS framework.

Key Takeaways

  • McKinsey's internal AI tool Lilli is used by 70% of staff roughly 17 times a week, and BCG's Deckster is used weekly by 40% of associates.
  • Knowledge workers spend about 20% of their week searching for information and another 28% on email, according to McKinsey Global Institute research.
  • The FOCUS framework (Find, Organize, Configure, Un-blackbox, Ship) turns a weekend into a working research assistant trained on your own case files and frameworks.
  • The point is not speed for its own sake. It's ownership: a tool you control instead of a subscription or a hire you rent forever.

The Bottleneck Nobody Bills For

Every consultant knows the math on utilization. You get paid for billable hours, and everything else is overhead you eat. Industry data puts management consulting billable utilization at around 70%, which means roughly a third of the work week produces zero revenue. Research is the biggest hidden drain inside that gap.

It doesn't show up as "wasted time" on a timesheet because it looks like work. It is work. It's just work a machine can now do faster than you.

None of this shows up neatly on an invoice. A missed deadline because you were still summarizing a 60-page industry report does show up, just not with a line item attached to the cause. That's the part most solo consultants miss: the research bottleneck doesn't cost you a visible dollar amount, it costs you the next client you didn't have time to pitch.

The scale of that drain is bigger than most solo consultants realize. McKinsey Global Institute has estimated that knowledge workers spend roughly 20% of the work week just searching for information, on top of another 28% buried in email. That's nearly half a week gone before a single insight reaches a client deck.

A Federal Reserve study on generative AI adoption found that workers using the tools saved about 5.4% of their total work hours, translating to roughly a 1.1% productivity gain across the economy. That number sounds small until you convert it into consulting hours: at $250 an hour, 5.4% of a 40-hour week is worth over $500 a week, every week, compounding.

Why the Big Firms Already Moved

This is not a hypothetical. Lilli, McKinsey's internal research assistant, delivers roughly 30% time savings on the tasks it touches, and it's now a daily habit for most of the firm. BCG's equivalent tool, Deckster, is used weekly by 40% of associates.

Lenovo built something similar for its own 3,000-person knowledge base and cut retrieval time by 30%, returning about 120 hours a year back to each employee while cutting escalations to subject matter experts by 35%. Every one of these firms reached the same conclusion from a different direction: research is a bottleneck, and bottlenecks get engineered out, not worked around.

A recent joint study from Harvard and Perplexity measured just how far the gap between "search" and "agent" has widened. AI agents performing autonomous research tasks now sustain roughly 26 minutes of independent work per session, compared to 33 seconds for a traditional search query. That's a 47x jump in the amount of unsupervised work a tool can do before you need to step back in. For a solo consultant, that gap is the difference between "I looked something up" and "I have a first draft."

None of these firms treat this as an experiment anymore. Lilli, Deckster, and Lenovo's Knowledge Super Agent are permanent infrastructure now, not pilot programs waiting on a budget review. That's the signal worth paying attention to: when three separate organizations at three different scales converge on the same fix, the fix is not optional anymore.

The FOCUS Framework: A Weekend Build Sequence

You don't need a data science team to build a research assistant. You need five deliberate steps, spread across a Friday night and a weekend. I call it FOCUS: Find, Organize, Configure, Un-blackbox, Ship. Each step maps to a block of time, and each one produces something concrete you can point to when the weekend is over.

Friday Night: Find Your Bottleneck

Before you build anything, name the exact task that eats your week. Don't say "research" in general. Say "summarizing 40-page industry reports into two-page client briefs" or "pulling comparable case studies before every proposal."

Echelon Advising's research on consulting firms found that many spend 15 to 20 hours a week on automatable tasks, costing between $3,000 and $10,000 a week in lost billable capacity. Pick the single task from your own week that looks most like that. That's your build target.

Saturday Morning: Organize Your Source Library

An AI research assistant is only as good as what you feed it. Spend Saturday morning pulling together the raw material: past client reports, your proprietary frameworks, industry data you cite often, competitor teardown notes. Drop them into a folder structure with clear naming.

This step feels administrative. It isn't. It's the difference between an assistant that gives generic answers and one that sounds like you, because it's trained on your actual work product.

Saturday Afternoon: Configure the Assistant

Now you build the thing. Use a tool that lets you upload documents and set custom instructions (a project workspace in Claude or ChatGPT works fine for a first version). Write a system prompt that tells it exactly how you want research delivered: bullet points first, sources cited, no fluff, flag anything it isn't confident about.

Load your source library from the morning session. This is the step that turns a general chatbot into a specific tool built for your practice.

Saturday Evening: Un-Blackbox It With Test Cases

Never trust a tool you haven't tested against work you already know the answer to. Take three past research tasks you completed manually and re-run them through the assistant. Compare the output line by line.

Where does it hallucinate a source? Where does it miss context only you would know? Fix the instructions, not the output. This is a casualty drill: you're finding the failure points before a client ever sees them.

Sunday: Ship It Into Your Workflow

A tool that lives outside your workflow gets abandoned by Wednesday. Build the assistant into whatever you already do: a bookmark, a shortcut, a step in your proposal template. Use it on a live, low-stakes task Sunday afternoon before Monday's real work hits.

The goal isn't a perfect system. It's a working one you'll actually open again.

What Good Looks Like After Week One

By the following Monday, you should notice the shift immediately. A proposal that used to take you two hours of background research now takes twenty minutes, because the assistant already knows your frameworks and your past case work. You're not reading faster. You're reading less, because the assistant already filtered out what didn't matter.

The real test comes a month in. If you're still opening the assistant every week, the build worked. If it's gathering dust by week three, go back to the Find step and pick a narrower, more painful bottleneck. The tool has to solve something that actually hurts, or it won't survive contact with a busy calendar.

What I Learned Scouting for a 55,000-Person Company

When I was an Innovation Scout at Hartford Steam Boiler under Munich Re, I was one of 15 scouts inside a company of 55,000 people. My entire job was researching emerging technology and reporting back on what mattered. I spent roughly 60% of my time on research and 40% presenting findings to people who made decisions. That ratio was backward, and I didn't have the tools to fix it then.

If I had an AI research assistant during those years, I would have flipped that split. The research itself would have been better, not just faster, because I could have tested more angles before committing to a conclusion. And I would have spent far more time in the room where decisions actually got made, which is the only place a scout's work turns into something real. That's the trade every consultant is making right now, whether they realize it or not: hours spent searching versus hours spent in front of the client who pays you.

Doctrine Connection: Ownership Beats Wages

Doctrine Connection: Ownership Beats Wages. Renting research capacity, whether from a junior analyst, a database subscription, or an outside firm, is a wage you pay forever. Building your own research assistant this weekend is a one-time cost that compounds. You own the asset.

You control the inputs. You keep the margin that used to go to someone else's payroll or platform fee. That's the whole difference between working for money and building something that works for you.

The Compounding Case for Building Your Own

Think of this the way you'd think about any capital investment. A weekend of setup time is the cost. The return is every future hour you don't spend searching, formatting, or re-explaining context to a new hire. ProductQuant's research on small SaaS teams found that founders typically hit a decision-load ceiling long before they can justify a full-time hire to handle it, and the same logic applies to a solo consulting practice: you don't need to hire a researcher to fix a research bottleneck, you need a system.

The firms cited throughout this piece, McKinsey, BCG, Lenovo, all reached for the same lever at a different scale. They didn't hire more researchers. They built tools that made their existing people faster and let the humans spend more time where judgment actually matters: in front of the client, in the room, making the call.

That's the asymmetry available to a one-person shop this weekend. You're not competing with McKinsey's budget. You're copying their engineering logic at a scale that fits your desk.

Frequently Asked Questions

Do I need to know how to code to build an AI research assistant?

No. The build described here uses existing tools like a Claude or ChatGPT project workspace, where you upload documents and write instructions in plain English. No coding is required for a first working version. Coding skills help later if you want to connect the assistant to live data feeds, but they're not a prerequisite for the weekend build.

How much does it cost to set this up?

Most consultants can build a working version using a paid tier of an existing AI tool, typically $20 to $30 a month. That's a fraction of the $3,000 to $10,000 a week that research-heavy firms report losing to manual, automatable tasks. The real cost is the weekend of setup time, not ongoing spend.

What if the assistant gives me wrong information?

It will, occasionally, which is exactly why the Un-blackbox step in the FOCUS framework exists. Test it against work you already know the answer to before trusting it on anything client-facing. Treat every output as a draft that needs a source check, not a finished deliverable.

Will this replace the need to hire a research analyst?

For a solo consultant or a firm under a few million in revenue, usually yes for the day-to-day research load. For firms scaling past that point, the assistant becomes a force multiplier for the analyst you do hire rather than a full replacement. Either way, the ratio of research time to client-facing time improves.

Jeff Barnes is the founder of Digital Evolution Marketing Group and Angel Investors Network. DEMG provides marketing systems and AI operations consulting for owner-operators. This article reflects operational experience and publicly available data. It is not financial, legal, or investment advice. Tools and platforms mentioned are not sponsored endorsements. Verify all claims, run your own numbers, and consult qualified professionals before acting.