The core idea was simple: you have to respect how Excel users already think.

When Excel users reach for Python, they are not looking to become Python developers overnight. They are looking to extend an existing mental model. They want something that fits naturally into their current stack, workflows, and instincts.

Unfortunately, a lot of Python in Excel training today misses that point. Much of it is essentially Python 101 with an Excel veneer. The training never really grapples with Python in Excel’s unique role inside the analytics stack.

That’s why I was excited to come across Python in Excel: Unlocking Powerful Data Analysis and Automation Solutions by Liam Bastick and Kathryn Newitt over at SumProduct.

There are many Python in Excel resources on the market, but this one stood out to me for how clearly it centers Excel users and their existing workflows.

Python in Excel as a natural progression, not a detour

What this book does exceptionally well is treat Python in Excel as a continuation of Excel’s analytics story rather than a bolt-on. The authors frame Python in Excel as a natural evolution of familiar tools from formulas and PivotTables to Power Query to Analyze Data and beyond.

Python doesn’t exist in a vacuum here. It is presented as another layer in Excel’s BI and analytics capabilities, not a replacement for what users already know.

Crucially, the book walks through how Python in Excel fits into real-world Excel workflows such as importing data from Power Query, working explicitly with tabular data (where Excel users actually live), and using Copilot effectively alongside Python.

That grounding makes a huge difference.

Constraints explained (and why they’re helpful)

Another strength is how clearly the book explains Python’s origin as an open-source ecosystem, and what that implies for packages, dependencies, and tooling.

Just as important, it explains why Python inside Excel comes with constraints, and why those constraints can actually be a feature. By limiting scope and environment complexity, Python in Excel becomes more approachable, safer, and easier to operationalize for everyday analysts. That framing helps users understand not just how Python in Excel works, but why it works the way it does.

Practical first, powerful later

What also works so well here is the sequencing. The book starts where Excel users actually live: structured tables, practical data manipulation, and quick analytical wins. That gives readers early confidence and a clear mental model for working with data, rather than throwing advanced concepts at them too soon.

By covering summaries, visualization, and common gotchas early, it helps readers avoid frustration and build good habits. Only after that foundation is in place do ideas like UDFs and control flow make sense. At that point, they feel like natural extensions of familiar workflows, not abstract hurdles. The book gets that progression right, which keeps it approachable without watering it down.

What I especially appreciated is how closely this aligns with how I try to teach Python in Excel myself: start with tabular thinking, real Excel workflows, and fast wins, then layer in power once the mental model is in place.

Final thoughts

This is a thoughtful, well-structured, and genuinely Excel-native approach to Python in Excel. It respects Excel users. It respects their workflows. And it shows Python in Excel not as a foreign language, but as a powerful extension of tools they already trust.

Bravo to Liam and Kathryn. I’ll absolutely be recommending this book to readers who want to understand Python in Excel the right way.

The post How to learn Python in Excel the right way (book review) first appeared on Stringfest Analytics.

As I discuss in the post, much of this training moved too quickly, failed to connect new ideas to how Excel users already think, and often framed spreadsheets and programming as an either or decision rather than complementary tools.

Five years later, Python now runs directly inside Excel. The tooling has changed, but the same instructional mistakes are resurfacing, sometimes with even greater consequences.

A problem that predates Python in Excel

Excel users are not starting from scratch. They already work with data every day: they group, filter, join, reshape, and analyze information in ways that map closely to what Python does well.

What they lack is not analytical reasoning, but familiarity with a different execution model and a different vocabulary for expressing ideas they already understand.

When instruction ignores this and treats Python as a completely new way of thinking, learners are pushed toward memorization rather than transfer. That is why so much “Python for Excel users” content could just as easily be labeled a generic introduction to Python. There is often nothing in it that meaningfully reflects the spreadsheet mental model.

Conceptual bridges that should be made explicit

Good instruction makes these mappings visible rather than implicit:

When learners see these connections, Python feels less like a foreign language and more like a different way of expressing familiar ideas.

In fact, this idea of helping learners understand Python by anchoring it to what Excel users already know was a major driving force behind Advancing into Analytics, which came out that same year.

A lot has changed since then. Python is now in Excel, and I probably would not spend as much time (if any) on R today. Even so, I still think the core choice was the right one. I focused on statistical analysis of tabular data, not control flow or user-defined functions right out of the gate.

Python in Excel is neither Python nor Excel

Python in Excel is not simply Python, and it is not Excel with a new syntax layered on top. It occupies a middle ground that comes with specific constraints.

Python in Excel is:

• vectorized by default
• tabular and grid-oriented
• optimized for analysis rather than application development

These characteristics should shape how it is taught. Treating Python in Excel like a notebook environment or a general scripting language creates confusion. Treating it like advanced Excel does the same. It needs to be approached as its own analytical surface.

After all, the audience here is not pure programmers. It is data analysts, and that is a fundamentally different user base. The pandas and Anaconda communities understood this early on, which is why they made deliberate choices around defaults, APIs, and workflows that prioritize data work over software engineering concerns.

Python in Excel takes that same philosophy a step further by meeting analysts exactly where they already work. It removes environment setup, lowers the cognitive overhead, and keeps the focus on manipulating, analyzing, and visualizing tabular data rather than learning programming for its own sake.

Why starting with abstraction often backfires

A common temptation is to introduce compact or idiomatic Python constructs early, often in the name of efficiency or best practice.

List comprehensions are a good example. They are powerful once a learner understands how data flows through a transformation. For many Excel users encountering Python for the first time, they remove visibility into intermediate steps and make debugging harder than it needs to be.

In practice, this leads to predictable questions:

• When would I actually use this?
• How do I inspect what happened at each step?
• How do I explain this to someone else on my team?

These are not signs of resistance. They are signs that abstraction has arrived before understanding.

What actually creates early traction for Excel users

Python in Excel tends to click when it delivers immediate value on problems Excel users already recognize.

Some examples of early wins that consistently resonate include:

• running a missing value analysis across an entire table to surface patterns that would take many formulas to uncover
• generating pair plots to explore relationships between variables in ways that are cumbersome or brittle to build with Excel charts
• reshaping messy, multi-header data into clean analytical tables with readable transformations
• performing exploratory analysis that complements PivotTables instead of replacing them

These use cases matter because they answer the most important early question: why would I use this instead of staying entirely in Excel?

If you want a quick, approachable, and affordable introduction to more than a dozen of these quick-win use cases, check out the course I put together with that exact focus:

Once that question is answered, learners are far more open to learning deeper ideas later.

Sequencing matters more than completeness

Many courses try to be comprehensive too early. They aim for coverage rather than durability. In my experience, Python in Excel instruction works best when it follows a deliberate sequence:

The first stage, Foundation, is about establishing trust in the tool. Excel users need to see quickly that Python in Excel helps them do things they already care about, only faster or more cleanly.

Tasks like scanning an entire dataset for missing values, summarizing distributions across many columns at once, or generating pair plots to explore relationships give learners immediate feedback that Python is worth the effort. These wins are visible, concrete, and easy to reason about. At this stage, the goal is not sophistication but confidence and relevance.

Once learners are comfortable producing useful results, the focus naturally shifts to Integration. Here, the emphasis is on understanding how results are produced, not just that they appear. Excel users are used to seeing intermediate states. They expect to be able to inspect, trace, and explain their work.

This stage reinforces those instincts by slowing things down and making data flow explicit. Learners see how transformations build on one another, how intermediate results can be examined, and how small changes affect outcomes. The payoff is work that is debuggable and explainable, which matters far more in a business setting than compact code.

Only after those foundations are in place does it make sense to move into Expansion. This is where control flow, abstraction, and reuse enter the picture. At this point, learners have enough context to understand why loops, conditional logic, or reusable functions exist and when they are actually helpful. These ideas stop feeling abstract because they are clearly tied to real analytical problems the learner has already solved. Generalization becomes a natural next step rather than a confusing leap.

When taught in this order, Python in Excel feels like a natural extension of existing skills instead of a foreign language that has to be memorized all at once.

Why this matters for organizations

When training is poorly sequenced, the symptoms show up quickly. Adoption slows because analysts are unsure when to use the new tool. Early solutions look impressive but are fragile, difficult to explain, and hard for others to maintain. As a result, teams find themselves retraining the same concepts repeatedly without ever reaching a point where the capability compounds.

Well-designed instruction produces a very different outcome. Teams reach useful results sooner because early wins are tied to real business problems. Analysts are able to explain not just what they built, but why it works, which reduces risk and improves trust in the output. Over time, Python in Excel becomes part of a durable analytical workflow rather than a short-lived experiment that quietly fades after the initial rollout..

How I work

This perspective comes from years of teaching Excel users inside real organizations. My focus is on judgment, sequencing, and practical wins that make new tools usable rather than intimidating.

If you are responsible for upskilling analysts and want Python, AI, and Excel to work together in a way that actually sticks, you can learn more about my approach here:

Python in Excel is extraordinarily powerful, but only when it is taught as the distinct analytical tool it actually is.

The post How to teach Python in Excel so it sticks first appeared on Stringfest Analytics.

Some people leave a session with ideas they immediately apply. Others leave with notes, recordings, and good intentions that never quite turn into usable skill. The difference is rarely intelligence, motivation, or even experience level. It almost always comes down to how people show up to the session itself.

This post is about what actually makes live Excel training work, particularly in an online format, and what responsibilities quietly sit with the learner whether or not they are explicitly stated.

Live Excel training is not content consumption

Live Excel training is often treated like content. Something to watch, skim, or half-follow while doing something else. That framing is understandable, especially when so much professional learning now looks like videos, courses, and recorded demos.

But Excel skills are procedural and judgment-based. They develop through hands-on work: trying things, noticing what breaks, correcting mistakes, and revising your thinking. Watching someone else use Excel can build familiarity, but familiarity is not the same as competence. You don’t learn when to reach for a PivotTable, Power Query, or Copilot by seeing it once. You learn by using it yourself and discovering where your assumptions fail.

That is why live Excel training functions much more like a workshop than a lecture. The value comes from participation, not exposure.

Setup is part of the work, not an inconvenience

When a live session focuses on a specific Excel capability—Copilot in Excel, Power Query, Power Pivot, Python in Excel—there is an assumption that you have at least opened the tool before the session starts.

You do not need to know how to use it well. You do not need to understand what it is doing under the hood. What matters is basic orientation: whether the feature exists in your environment, where it lives in your version of Excel, and what you see when you try to open it.

This matters because Excel is not one thing. Desktop and web behave differently. Windows and Mac differ. Features are tied to licenses, update channels, and tenant settings. In a live session, especially online, an instructor cannot see your setup and cannot easily tell whether you are blocked by access or by understanding.

If a session does not explicitly say that setup and access will be handled together, then setup is assumed. Live time works best when it is spent on how to use a feature and why it matters, rather than on figuring out whether the feature is available at all.

Practical prep you can do ahead of a session

You do not have to do everything here. Even a little preparation helps.

• Check your Excel version: Open Excel and go to File > Account. Note whether you are on Excel Desktop or Excel for the web, and what subscription or update channel is listed.
• Look up where the feature exists: Check whether the capability is available on desktop, web, Windows-only, or subject to tenant controls.
• Open the tool once: Try opening Power Query, Power Pivot, Copilot, or Python in Excel so you know what happens when you click it.
• Notice what you see: Is the button missing, disabled, or throwing an access message?
• Bring specifics with you: “I’m on Excel Desktop for Windows and Power Pivot isn’t showing up” gives an instructor something concrete to work with.

Preparation here is simply about keeping live time focused on learning, rather than burning it on environment and access issues that could have been surfaced earlier.

Trying and failing is not optional

Most of the learning in live Excel training happens when something does not work.

You try an exercise, the result looks wrong, and you are forced to reconcile what you expected Excel to do with what it actually did. That mismatch is where understanding forms. If you only watch, you skip that step. You may follow the instructor’s logic, but you never test your own, which often leads to confidence without competence and trouble the moment you are on your own.

Live Excel training is designed around this kind of friction.

Productive failure still needs a safety net. Sessions should feel safe to experiment in, but learners also need to bring some of that safety with them. That is why practice files and solution files matter. They let you recover if you fall behind, check your thinking, and rejoin the session without stalling.

If materials are provided, use them. Open the practice file. Keep the solution file handy. Comparing your work to a working example is usually faster and more instructive than waiting for answers in chat.

Questions need structure to be answerable

In online training, instructors cannot see your screen. They do not know your data, workbook layout, Excel version, or the steps you took unless you share them. That is why a vague “that didn’t work” dropped into chat rarely leads to a useful answer.

Questions that actually move things forward usually include three things: what you tried, what you expected to happen, and what happened instead. That level of detail is enough to give an instructor something to reason about.

If you want a deeper breakdown of how to ask a good Excel question, check out this post. It walks through examples and patterns in more detail than a live session ever can.

That said, asking good questions in real time is hard. Live online training moves quickly, and it is not always realistic to craft a perfectly formed question on the spot. This is a skill that improves with practice, especially in slower, time-independent environments like working through exercises, reviewing solution files, or posting questions asynchronously. The more you practice articulating your thinking there, the easier it becomes to do it live.

Chat questions also may not be answered immediately. That delay is not dismissal. Instructors are balancing demonstrations, pacing, and dozens of learners at once, and well-structured questions still matter even if the response comes later.

Materials are part of the learning design

Starter files, demo notes, and solution workbooks are part of the course design, not extras.

They exist to help you orient yourself, catch up, and understand what a working result looks like. Checking a solution file often teaches you more than collecting answers one at a time.

The goal of live training is not to memorize what the instructor typed. It is to develop a sense of what “normal” looks like in an Excel workflow, so you can recognize when things are going right or wrong.

Online feedback is your responsibility

In a physical room, instructors can read faces, body language, and energy. Online, they cannot.

If you finish an exercise, say so. If you are stuck, say so. If you are completely lost, say so. These signals matter more than people realize. Without them, pacing becomes guesswork, and guesswork usually underserves everyone.

In an online environment, learners are the instructor’s eyes and ears. If you want the session to adapt to where people actually are, that information has to come from somewhere.

Recordings are a safety net, not the experience

Recordings are useful. They are essential when someone arrives late, leaves early, or needs to revisit a specific concept. But they are not a substitute for participation.

Most people do not rewatch full sessions. Even fewer pause recordings to redo exercises carefully. And when they do, the experience is rarely as effective as being live, where decisions have to be made in real time.

Excel skills stick when you struggle a bit in the moment, ask questions, and resolve confusion while the context is still fresh. If that happens, the recording becomes reference material rather than a promise you make to yourself and never keep.

A practical checklist for live Excel training

Here’s a checklist you can actually use in live Excel training to get more out of it, at any skill level:

Conclusion & next steps

Live Excel training works when it is treated as practice, not content consumption. When expectations are clear and learners are encouraged to engage, try things, and give feedback, live sessions reliably translate into real capability. When those conditions are missing, even strong content struggles to land.

The checklist above is meant to be used, not admired. Share it with participants before a session. Use it to set expectations. Refer back to it afterward when deciding what actually stuck. Small shifts in how people show up tend to produce outsized changes in outcomes.

If you are responsible for training analysts or Excel users inside an organization and want live training that leads to changed behavior rather than temporary familiarity, this structure matters. I work with teams to design and deliver Excel training that emphasizes judgment, participation, and real workflow application, not passive feature walkthroughs. That includes shaping the session format itself, not just the material inside it.

If this is the kind of training experience you are trying to build, you can get in touch here to discuss training or advisory options:

The post How to get real value out of live Excel training first appeared on Stringfest Analytics.

The question is almost always framed along these lines:

• “How can we use Copilot for this?”
• “Can AI replace this workflow?”
• “Should we be using AI here?”

What is striking is that these questions usually come after a tool has already been chosen, not before. AI shows up as a solution looking for a problem. And that is where teams start getting into trouble.

The real issue is not whether AI is powerful. It clearly is. The issue is whether AI is appropriate for a given task. Excel already has a mature ecosystem of deterministic tools like Power Query, formulas, PivotTables, Power Pivot and even Python in Excel. Those tools exist for a reason. They are stable, repeatable, auditable, and boring in exactly the way production work should be.

AI changes the nature of work by introducing variability. Sometimes that variability is a feature. Sometimes it is a liability. The difference matters.

This post introduces a simple way to think about that difference. It starts with a diagnostic lens I call the SAFE framework, and then moves into a practical decision matrix for choosing the right tool in Excel.

AI is not a replacement for judgment

One of the biggest mistakes teams make is treating AI as a drop-in replacement for existing Excel workflows. Monthly reporting, reconciliations, KPI calculations, and regulatory metrics are often held up as candidates for automation through prompting.

That instinct is understandable, but misguided.

These workflows exist precisely because they demand consistency. The same inputs should produce the same outputs every time. Changes should be deliberate, documented, and reviewable. AI, by design, does not guarantee that. Even when outputs look stable, the underlying process is probabilistic.

Before deciding whether AI belongs in a workflow, we need a way to evaluate the task itself. That is where SAFE comes in.

The SAFE framework

SAFE is not a checklist or a process. It is a lens. It asks four questions that determine how much freedom a task can tolerate.

• Stability asks how consistent the output must be. If the result needs to be repeatable and auditable, the tolerance for AI-driven variability is low.
• Ambiguity asks how well defined the task is. Exploratory questions benefit from flexible reasoning. Well-specified procedures usually do not.
• Frequency asks whether the task is a one-off or recurring. Prompting is not automation. If something runs every week or every month, it should eventually be encoded in a deterministic workflow.
• Exposure asks who depends on the output. The more visible the result, the higher the cost of inconsistency or error.

These four dimensions do not give you a yes or no answer on their own. What they do is surface risk. They tell you whether AI usage increases or decreases confidence in the outcome.

In general, AI fits best when ambiguity is high, stability requirements are low, frequency is limited, and exposure is contained. As those conditions reverse, deterministic tools should take over.

SAFE helps you decide whether AI should even be considered. It does not yet tell you which tool to use. For that, we need one more step.

From diagnosis to decision

Once a task passes the SAFE lens, the next question becomes practical. If AI is acceptable here, where exactly does it belong in the Excel workflow?

This is where a simple two by two matrix becomes useful. The matrix is based on two dimensions.

The horizontal axis is ambiguity, ranging from well defined to exploratory. The vertical axis is stability required, ranging from low to high.

High stability, low ambiguity: Rules must hold

This is the domain of classic Excel work. Power Query, formulas, PivotTables, and data models live here for a reason. These workflows support recurring reporting, data cleanup, joins and merges, and KPI calculations. They are designed to refresh reliably. When inputs change, outputs change predictably. That is a feature, not a limitation.

Using AI here adds risk without adding much value. If a workflow refreshes, it should not require prompting. If leadership depends on the numbers, rules must hold.

High stability, high ambiguity: The judgment zone

This quadrant is subtle and often misunderstood. The outputs matter, but the rules are not fully settled.

Defining metrics, choosing KPIs, setting business rules, and interpreting edge cases all fall here. These decisions require human judgment. Excel formulas are still useful, but they serve the thinking rather than replace it.

AI can play a supporting role, but only lightly. It can help explore alternatives or sanity check reasoning. It should not be the authority. This is a human-in-the-loop zone by design.

Low stability, high ambiguity: The AI sweet spot

This is where AI genuinely works best. Exploratory analysis, early-stage investigation, draft charts, executive summaries, and sense-making all benefit from flexible reasoning. In this zone, variability is acceptable because the goal is understanding, not finality.

Copilot and Python in Excel work well here because they accelerate thinking. They help you ask better questions, see patterns faster, and communicate insights more clearly. The outputs are drafts, not deliverables.

AI belongs upstream in the analytical process. This is what that actually looks like.

Low stability, low ambiguity: The convenience zone

Not everything needs to be engineered. One-off transformations, ad hoc checks, and throwaway analysis live here. Either AI or traditional tools can work. The primary goal is speed. Overengineering is just as wasteful as overprompting.

This quadrant exists to prevent perfectionism. It gives teams permission to move on.

Why this framing matters

When AI is pushed into high-stability, high-exposure workflows, teams experience subtle failures. Results become harder to reproduce. Explanations become weaker. Trust erodes slowly.

When AI is used upstream, where questions are still forming, it has the opposite effect. It accelerates insight, improves communication, and frees analysts to focus on judgment rather than mechanics.

SAFE evaluates the task, and the matrix chooses the tool. This separation is what keeps AI useful instead of dangerous.

A final rule of thumb

If leadership depends on the output, AI stays upstream.

That does not mean AI has no role. It means its role is to support thinking, not replace production systems that already work. The teams that benefit most from AI are the ones who understand where not to use it.

If this framework resonates, the next step is seeing how it applies to your Excel workflows, reporting cycles, and decision context. I offer an initial discovery call where we walk through how my frameworks and services are typically used to help teams:

• clarify which Excel workflows should remain fully deterministic
• identify where AI can responsibly support exploration and analysis
• reduce hidden risk in reporting, metrics, and leadership-facing outputs

The goal of the conversation is to understand your context and determine whether my training, advisory, or implementation services are the right fit for your organization.

You can book a time here:

fsdfdsfasd

The post When to use AI in Excel (and when you absolutely shouldn’t) first appeared on Stringfest Analytics.

LinkedIn Learning: still a stellar partnership

One of the best constants this year has been my partnership with LinkedIn Learning. I can’t say enough about how much I appreciate that collaboration. The team is professional, kind, and incredibly creative, and the courses keep finding their way to more learners every month. Last I checked, I was past 350,000 learners!

This was a standout year for my Copilot for Excel titles. Watching thousands of learners finally “get” what Copilot can do, and where it still needs a human touch, has been a highlight of my career. Those messages from people saying they finally feel confident working with data make it all worthwhile.

LinkedIn Learning gives me both reach and freedom. The passive income keeps Stringfest Analytics running smoothly, and the creative support lets me build content that actually means something.

Teaching finance, the Excel way

I also continued working with financial services training companies like Alpha Development and Neueda. These collaborations keep me close to the people shaping the next generation of finance professionals, and I love seeing Excel used as more than a calculator. It has become the language of analysis, automation, and decision-making.

There is something deeply rewarding about helping analysts and associates see how Power Query, AI, and automation can level up their work. These sessions are technical but personal too, because they help people find confidence in their craft.

Global Excel Summit

This year’s Global Excel Summit was another highlight. Every time I attend, I am reminded how vibrant and generous this community is. You see familiar faces, new ideas, and a level of excitement for where Excel and AI are headed that never seems to fade.

Between Copilot, Python in Excel, and the next wave of intelligent tools, this field continues to evolve fast. It is a privilege to stand at that crossroads as a teacher, creator, and experimenter.

Fewer business flights, better housesitting journeys

Travel for client work slowed down this year, and that turned out to be a gift. I’ve been spending more time traveling for housesits instead! It’s an odd rhythm that has become part of my story, a way to work remotely while exploring new places and helping out pet owners.

Each housesit brings a new workspace and a new cast of feline coworkers. It has become my own version of a creative residency. I get to teach, write, and consult from different corners of the world, and those quiet stretches between sessions help me reset and reflect.

If Stringfest Analytics had a mascot, it would probably be a cat sitting on a laptop while a spreadsheet runs in the background.

The Big Island reset

One of my housesits took me to the Big Island of Hawaii, and it ended up being one of the defining experiences of my year. Living off-grid gave me room to breathe in a way I didn’t even realize I needed. The silence there was different. No notifications. No rushing. Just quiet and time to think.

Most mornings I woke up to rain on the roof and felt how simple life could be. That stretch made it obvious how much of my business stress comes from unnecessary complexity. I came home wanting things to feel leaner and more honest.

If I’m creating value, I’ll say so. If someone wants to work with me, great. I don’t have to contort myself or chase validation. I just want to keep doing meaningful, high-quality work and trust that’s enough.

Letting go of the wrong clients

In the spirit of being healthier and happier, one of the biggest shifts this year was learning to walk away from clients who don’t respect boundaries or independent professionals. I had a few who expected instant replies, constant availability, and full-time commitment for tiny part-time contracts with no benefits.

That’s not the kind of work I want. Stepping away from those relationships opened up time and energy for better projects and better people. My work got stronger the moment I stopped letting exhaustion set the pace. When I focus on doing good work with integrity, the right opportunities have a way of showing up on their own.

Health, clarity, and a calmer pace

This year I made a point to take better care of myself. More sleep. More walks. Less caffeine. Fewer late nights staring at screens. When I treat myself like a human being and not a machine, I think more clearly and create better work. There is space again for creativity and reflection. Ideas have time to unfold instead of being forced.

That balance between structure and stillness feels like what Stringfest Analytics has always stood for: helping people find clarity in data while keeping a sense of calm and focus.

Looking ahead to 2026

The plan for next year is simple. Keep building on what works. Keep trusting that the right pace and the right people are already in motion.

I’ll continue teaching, writing, and creating courses that help professionals use Excel, Copilot, and AI to make better decisions. I’ll keep collaborating with teams that value learning and craftsmanship. I’ll keep saying yes to projects that inspire me and no to the ones that do not.

And yes, I’ll ask directly: If your team needs Excel or AI training in 2026, get in touch. Let’s build something that helps your people feel confident, creative, and fluent with data.

Thank you for being part of this journey. Whether we have met online or in a classroom, I’m grateful for your support. Wishing you peace, health, and purpose in the year ahead.

The post The 2025 Stringfest year in review: less grind, more grounding first appeared on Stringfest Analytics.

Prompt patterns are simple ways of framing your request so Copilot has the right context and direction. Sometimes you want a quick no-context answer, sometimes you show an example, sometimes you build the request step by step, and sometimes you tell Copilot what not to do. Each pattern nudges Copilot in a different way, and knowing when to use which one gives you much cleaner, more predictable results.

In this post we’ll walk through six essential patterns, from zero-shot to one-shot, chaining, refinement, and even negative prompting, and why they matter for Excel users.

If you want to follow along, download the fictitious equities dataset below and open Copilot in Excel:

Zero-shot prompting

Let’s start with the simplest pattern: zero-shot prompting. This is where you ask Copilot a direct question with little to no setup, almost like you’re talking to a human analyst who already knows your data. It’s fast, it’s lightweight, and it’s great when you just need a first draft or a quick read on a pattern. The downside is that Copilot doesn’t have much to anchor on, so the output can drift, stay generic, or miss the nuance you actually care about.

For example, you might try something like: “Using the EquitySnapshot 3table, give me a brief sector-level valuation overview focusing on differences in P/E and EPS. Keep it to one short paragraph.”

Copilot will give you something serviceable, but it probably won’t be tailored to your model, your definitions, or the exact story you’re trying to tell. Zero-shot is useful for breaking the ice with your data. Just don’t expect precision.

One-shot prompting

One-shot prompting gives Copilot a little more direction by offering a single example of the tone or structure you want. You’re basically saying, “Talk like this.” It’s a simple way to nudge Copilot toward a certain voice without overexplaining or writing out a full template. You still won’t get perfect control over depth or structure, but the output usually feels closer to what you had in mind than a pure zero-shot prompt.

For instance, you might say: “Here’s the style I want: ‘Technology names saw higher multiples supported by strong earnings trends.’ Using the EquitySnapshot table, write a similar short summary of how valuations vary across the major sectors.”

That one example tells Copilot the tone, rhythm, and level of detail you’re aiming for. It won’t lock things down completely, but it does give you a clearer, more consistent starting point.

Multi-shot prompting

Multishot prompting builds on the same idea as one-shot, but with more examples to anchor Copilot’s style, tone, and structure. By giving it two or more samples, you’re tightening the guardrails and showing exactly how you want the summary to read. It takes a little more setup, but the payoff is more consistency. Copilot has a clearer blueprint to follow, and you get output that feels closer to your own writing.

For example:
“Example A: ‘Healthcare displayed resilient earnings with mid-range valuations.’
Example B: ‘Consumer names clustered at the lower end of the valuation range.’
Using the EquitySnapshot table, write a sector-level valuation summary in a similar voice.”

With multiple samples, Copilot can triangulate the tone and pacing you’re after instead of guessing. You give it the vibe and the structure, and it fills in the analysis.

Reasoning prompts

Reasoning prompts ask Copilot to walk through its thinking before it gives you the final answer. Instead of jumping straight to a summary, you tell it to spell out how it’s comparing values, what it’s filtering on, or how it’s ranking things. This is especially useful when you care about accuracy and transparency, or when you want to cut down on hallucinations and vague “handwavey” summaries. The tradeoff is that responses tend to be longer and more detailed, so you may need to skim.

For example: “Using the EquitySnapshot table, walk through how you compare sectors based on P/E and EPS before giving the final summary. Then give me a clean, 3-bullet takeaway.”

Here you’re telling Copilot: first, show your work; second, compress it into something tight and useful. That makes it easier to trust the output and reuse the logic later.

Chained prompts

Chained prompts break a task into a sequence of small, deliberate steps. Instead of asking Copilot for one big deliverable, you guide it through the process: explore the data, choose an angle, then produce the final output. This works really well for complex analysis where you want control at each stage and don’t want Copilot to jump straight to a conclusion you didn’t ask for. It takes a little more time, but the end result is usually cleaner and more aligned with your intent.

For example, you might start with: “Scan the EquitySnapshot table and identify standout valuation patterns.”

Then follow with: “Now suggest 2–3 angles to highlight.”

And finish with: “Now write the summary as three crisp bullets.”

By chaining your prompts, you’re basically project-managing Copilot. Each step narrows the direction until the final answer is exactly what you want.

Negative prompting

Negative prompting is all about setting boundaries. Instead of just telling Copilot what you do want, you also spell out what you don’t want in the answer. This is useful when you need the output to stay descriptive, neutral, or compliant, especially in finance or regulated environments. Copilot tends to drift into advice, predictions, or extra color unless you tell it not to, so negative prompting reins that in.

For example: “Summarize sector-level valuation patterns in the EquitySnapshot table, but keep it strictly descriptive and avoid recommendations or forward-looking statements.”

By defining the “no-go zones,” you help Copilot stay focused on the facts in front of it. It’s a simple pattern, but it makes a big difference when precision and tone really matter.

Conclusion

These patterns aren’t some official taxonomy or set of rigid “prompting laws.” They’re just things you start to notice once you’ve used Copilot enough times to see how it behaves. You’re like won’t sit at your desk with Copilot and think, “Let me craft a multishot prompt today.” You’ll just reach for whatever gets the job done, the same way you do algebra or arithmetic without saying the names of the rules out loud.

Most real prompts end up being blends anyway. Maybe you start zero-shot, then follow up with a chained step, then tack on a quick “don’t give me recommendations” at the end. That’s normal. The point is to build a feel for how Copilot responds to structure, examples, boundaries, and sequencing. Once you get that intuition, prompting stops feeling like “prompt engineering” and more like just…using the tool.

To wrap things up, here’s a quick at-a-glance table summarizing the strengths, drawbacks, and best uses for each pattern:

Use this as a reference, but don’t get hung up on labels. Copilot works best when you treat prompting like any other Excel skill: something that gets smoother the more you practice, test, and tweak.

The post How to understand prompt patterns for Copilot in Excel first appeared on Stringfest Analytics.

If that feels familiar, the Think Deeper mode in Copilot for Excel is a great middle ground. It sits on top of Python in Excel, but you don’t have to write or tweak code yourself. Instead, it uses a reasoning-focused LLM to build a structured plan, generate the Python steps, and walk you through deeper insights with more context.

What makes this different from a quick Copilot answer is its reasoning model. Think Deeper breaks your question into steps, chooses appropriate techniques, tests options, and explains why it’s taking a particular approach. It behaves more like an analyst thinking through a problem than a tool spitting out a single-shot response.

For this example we’ll use the well-known vehicle mileage dataset. Say you’re an insurance data analyst studying how vehicle characteristics like weight, cylinders, and horsepower relate to fuel efficiency as a proxy for driving patterns and risk. The dataset gives you a clean historical baseline for building and validating models that predict claim likelihood for older vehicles.

Think Deeper is a great place to start because it walks through the relationships for you, tests different angles, and explains why certain features matter. You get a structured reasoning path instead of a quick one-off answer, which is exactly what you want when you’re scoping a risk model from scratch.

To follow along, download the exercise file below:

If you’ve used Advanced Analysis with Python before, this workflow will feel pretty familiar. (If not, check out my earlier post for a quick primer.)

You’ll still want to save your raw data as a table, make sure the workbook is in OneDrive, launch Copilot, and say the magic words: “Analyze this data with Python.” The only real difference is what you do next: instead of the default option, you’ll click the second button to run the analysis with Think Deeper.

Mine says, “With Think Deeper, I take longer to respond with more in-depth answers for complex tasks.” You’ll also see a basic analysis plan appear in the side panel, and then Copilot starts generating and running the code. It can take a little while, and there’s a lot happening under the hood, so don’t get overwhelmed by the code flying by.

The nice part is you can use Copilot itself to review, understand, and even troubleshoot the analysis it just created.

Eventually, Think Deeper will push all the way into predictive analytics, which might be farther than you planned to go with simple EDA. Results will vary from run to run, of course, but the overall structure is consistent. You can even run it a couple of times on copies of the same data to see different angles and deepen your understanding of the dataset.

Think Deeper can be a really helpful middle step between “I don’t want to code” and “I want deeper analysis than a quick summary.” It’s great when you need structure, when your data has multiple angles worth exploring, or when you want to see how a reasoning model approaches the problem before you commit to your own Python or Excel work.

But it’s not always the right choice. Think Deeper takes longer to run, it generates a lot of code, and it can easily wander deeper into predictive analytics than you planned. If you already know exactly what question you want answered, or you just need a quick chart or summary, the standard Advanced Analysis workflow is faster, simpler, and a lot less overwhelming.

Here’s a quick side-by-side comparison you can skim before choosing which mode to use:

Both tools are useful. They’re just useful in different moments. And you can always query, question, or refine anything Think Deeper generates. Copilot can even help you understand, troubleshoot, or simplify its own work, which is honestly one of the best parts of using it.

The post Copilot in Excel: How to understand Think Deeper with Python first appeared on Stringfest Analytics.

The funny thing is: not having Copilot isn’t really the barrier people think it is. Most teams have bigger, older problems that no AI tool is going to magically solve. And honestly, getting those things sorted out now will make life a lot easier once you do turn these tools on.

Start by improving the data you already have

As an Excel trainer and MVP, I see the same patterns across scores of organizations: the data people rely on every day is held together by luck and muscle memory. Columns shift around, naming is all over the place, refreshes break, and everyone has a slightly different version of the same file.

People want Copilot to fix that. It won’t. It can’t. But you can fix quite a bit of these broken workflows right now, no Copilot required:

• Turn your ranges into proper Excel Tables.
• Move the weekly cleanup steps into Power Query.
• Stop hard-coding your data sources (pasting CSVs on top of last week’s data, pointing to someone’s Downloads folder, etc.).
• Keep your raw data intact instead of overwriting it every cycle.
• If the data comes from an external system, pull it the same way every time. Don’t manually export one week and copy/paste the next.

These small, boring steps are what make a dataset reliable enough for anything downstream: formulas, PivotTables, automation, or Copilot.

If you need a place to start with this, begin with my book Modern Data Analytics in Excel:

It walks through everything from tables to Power Query to building data models the right way. Once the foundations are in place, the rest of the “AI stuff” starts behaving a lot more predictably.

And even before Copilot arrives, remember that if you’re on Microsoft 365, you already have the Analyze Data button in Excel. It’s free, built-in, and a great way to practice asking AI questions about your dataset, without exposing anything sensitive to an external model:

While you’re waiting, build the skills Copilot works best alongside

Additionally, if you have access to Python in Excel, this is a great time to start getting comfortable with it. I don’t mean jumping into machine learning or trying to become a data scientist overnight. I just mean learning the basics: generating clean sample data, reshaping messy tables, doing simple transformations, or sanity-checking calculations.

You don’t need Copilot for any of that. And once Copilot is turned on, having even a tiny amount of Python literacy goes a long way. You understand more of what it’s suggesting. You can verify its logic. You can use Python for the heavy lifting and Copilot for the explanation layer. The two complement each other really well.

And there’s a larger reason Python matters so much here: Python in large part is the language of modern AI. Almost every major AI model you’ve heard of was trained with Python. The entire machine learning ecosystem—TensorFlow, PyTorch, scikit-learn—lives in Python. Copilot’s Advanced Analysis feature uses Python behind the scenes:

That means when Copilot generates Python for you, you’re speaking the same language the model understands natively. A little Python knowledge lets you sanity-check the code, extend it, and know when something looks off. It’s one of the highest-ROI skills you can build while waiting for Copilot to arrive.

The same goes for Office Scripts and Power Automate if your organization already has them. I’m not suggesting you run out and try to replace Copilot with these tools (you won’t, because again, it’s not meant to replace them). But knowing the basics now means you’ll eventually have a much cleaner handoff between what you do manually, what Copilot helps you with, and what you automate later. Even something as simple as learning how to record an Office Script and look under the hood will make Copilot’s script-generation features feel far less mysterious when they land.

I explain this a lot in my courses: Copilot isn’t a standalone solution. It’s part of a larger ecosystem. A little familiarity with Python, Power Query, and Office Scripts makes your prompts clearer and your results better.

And a quick note on using free AI tools responsibly

If you’re leaning on the free versions of Copilot or ChatGPT while you wait for the paid version at work, If you’re leaning on the free versions of Copilot or ChatGPT while you wait for the paid version at work, that’s completely fine and not a bad idea. But a quick reminder I tell all my corporate clients: don’t paste anything sensitive into them.

Keep it to synthetic data, scrubbed examples, structure and logic, formulas, and generic versions of your workflow. Save the real business data for the paid, enterprise-secured tools when they arrive.

Conclusion

Ultimately, getting “AI-ready” takes far more than purchasing a Copilot license. It requires getting your data into shape, building a few adjacent skills, and creating an environment where Copilot can actually help you once it arrives. Most of the heavy lifting happens long before the AI shows up. Teams that take the time to clean up their inputs now are the ones that see the fastest payoff later.

If you want help getting your team ready for all of this—data foundations, Python, Copilot, Power Query, Office Scripts, or anything in between—I teach this every week for organizations of all sizes. Reach out if you want to talk through what a practical, non-disruptive path to AI-powered Excel looks like for your team:

The post How to get AI-ready even if you don’t have paid Copilot first appeared on Stringfest Analytics.

Python in Excel and Copilot’s Advanced Analysis mode change that entirely. Instead of struggling with the tool, we can focus on the actual analytical work. We can explore patterns, test ideas, understand why outcomes occur, and build models that are transparent and easy to explain.

To see this in action, we are using a simple but realistic dataset from a social network advertising scenario. Each row represents a user who was shown an ad, along with information such as gender, age, and estimated salary, and a binary indicator showing whether they purchased the product. The structure makes it ideal for a first logistic regression example.

You can download the exercise file below to follow along in Excel, run the model with Python, and explore the results with Copilot.

If you haven’t set up a dataset to use with Advanced Analysis in Copilot yet, this post will walk you through exactly how to get started:

Before we start prompting, it helps to get clear on what logistic regression actually does. Logistic regression predicts the probability of a binary outcome. These are situations with two possible results such as yes or no, purchased or not purchased, or clicked or not clicked. Linear regression estimates continuous values like income or price, while logistic regression tells you how likely an event is to occur.

In this dataset, each row represents a user who saw a social network ad. We know basic attributes like age, gender, and estimated salary, along with a simple outcome that indicates whether they purchased the advertised product. Logistic regression helps us understand how those characteristics influence the chance that someone converts. Instead of guessing that, for example, higher income users might be more willing to buy, the model quantifies how much each factor matters.

Exploring the data for logistic regression

First things first: your data needs attention before modeling. Logistic regression comes with certain assumptions about the data, and it’s crucial to meet them for meaningful results. Let’s prompt Copilot to guide us through the necessary preprocessing steps:

“Check the dataset for missing values, outliers, and imbalanced target classes. Recommend data preprocessing steps needed before running logistic regression.”

Copilot reported no missing values and no outliers, but it did flag a class imbalance in the Purchased column. We have 257 zeros and 143 ones. This is a mild imbalance, not a crisis. Logistic regression can handle a split like this, so you can continue without immediately fixing anything. The imbalance only affects how the model treats its default prediction and how you interpret accuracy, false positives, and false negatives.

If you want to experiment with balancing the classes, Copilot can walk you through it with a simple prompt like “Use Python in Excel to apply oversampling or undersampling to the Purchased column and explain the tradeoffs.” It keeps the focus on understanding the workflow rather than jumping into advanced techniques.

Next, I asked Copilot to take a look at the numeric features more closely. Distributions matter in logistic regression because extreme skew or scale differences can quietly pull the model off course. So I prompted it with:

“Show the distribution of numeric features and recommend any transformations that would help logistic regression perform better.“

Copilot returned histograms for Age and EstimatedSalary. Age looks fairly even across the range, but EstimatedSalary tilts to the right with a long tail. Copilot suggested scaling both features and possibly applying a log transform to EstimatedSalary if that skew becomes an issue. This is a helpful reminder that logistic regression works best when numeric predictors are on comparable scales and do not contain large distortions. By checking these distributions early, you avoid surprises later when interpreting coefficients or diagnosing model performance.

Building the logistic regression

With the distributions checked, we have a few mild issues to be aware of, but nothing that stops us from moving forward. Age looks fine, EstimatedSalary is a bit skewed, and the class balance leans toward zeros, but none of these are severe enough to pause the workflow. This is exactly the kind of dataset where you can keep going and let the model show you whether any of these concerns actually matter.

Rather than hand-picking variables or writing your own encoding steps, it is easier to let Copilot build the first version of the model. I asked it to fit a baseline logistic regression and walk through which predictors matter:

“Fit a logistic regression model predicting customer purchase using the other available features. Explain the importance of each predictorc and identify which predictors are statistically significant.”

Copilot returned a clean summary table showing the coefficients, standard errors, z-scores, p-values, and confidence intervals. From this first pass, Age and EstimatedSalary clearly stand out with very small p-values, which means they contribute meaningfully to the likelihood of purchase in this dataset. Gender, on the other hand, has a much higher p-value and does not appear to be statistically significant. That is perfectly normal. Baseline models like this often reveal which features actually matter and which ones quietly fall away once the math weighs them properly.

Diagnosing and interpreting model performance

Once the model is built, the next step is to understand how well it actually performs. Copilot can take care of the heavy lifting, so I asked it to explain the results in plain language:

“Visualize the confusion matrix for this logistic regression model and explain, in plain language, what each metric (accuracy, precision, recall, F1, false positives, false negatives) reveals about the model’s predictive strength and weaknesses.”

Copilot returned a confusion matrix along with a clear explanation of each metric. This model gets about eighty five percent of predictions right, which tells us it is generally reliable for this dataset. Precision shows that when the model predicts a buyer, it is correct most of the time. Recall shows how many actual buyers the model manages to catch.

The F1 score summarizes both perspectives and gives a sense of overall balance. The false positives and false negatives are especially useful because they show exactly how the model is getting things wrong. In this case the model tends to miss some actual buyers, and it occasionally predicts purchases that never happen, but overall the pattern is solid for a simple first pass.

This is the point in the workflow where you start making decisions about whether the model is good enough or whether you need to refine it further with scaling, transformations, threshold adjustments, or feature engineering.

Checking the model’s assumptions

Up to this point, we have focused on the data itself. At the beginning of this walkthrough, we checked for missing values, outliers, skewed predictors, and class imbalance. Those steps help us understand the raw material before building anything. Now that we have a fitted model, the focus shifts. We are no longer asking “Is the data clean enough to start modeling?”

We are now asking a different question: “Does the model we built actually satisfy the assumptions that logistic regression relies on?” To dig into this, I asked Copilot to evaluate the assumptions directly:

“Explain the assumptions underlying logistic regression. Check these assumptions using our dataset and discuss any potential issues identified.”

Copilot checked the correlation matrix, confirmed that multicollinearity was not a problem, and then ran the Box-Tidwell test to assess the linearity of each predictor with the logit. This is an important distinction from earlier. Before, we looked at histograms simply to understand the shape of the variables. Here, the test is far more targeted. It examines whether the relationship between each predictor and the log odds of purchase behaves in the way logistic regression expects.

In this case, the linearity assumption appears to be violated for EstimatedSalary. The interaction term is statistically significant, which suggests the logit may curve rather than follow a straight pattern. That does not break the model, but it does tell us that the EstimatedSalary relationship might not be fully captured without a transformation or a nonlinear term. Age, on the other hand, looks fine, and the lack of strong correlations means multicollinearity is not a concern.

These checks help us understand not just what the model predicts, but how trustworthy those predictions are. From here, we can decide whether to refine the model, transform variables, or move on to interpreting and communicating the results

Business interpretation and application

At this stage, we have explored the data, fit the model, checked performance, and verified the key assumptions. The final step is the one that actually matters to stakeholders. A model is only useful if someone can act on it. Copilot helps bridge that gap by turning statistical output into business guidance. I asked it to interpret the model in practical terms:

“Provide a clear, actionable interpretation of the most influential features from the logistic regression. Explain what these results mean for business decisions related to customer retention and marketing strategy.”

Copilot highlighted Age and EstimatedSalary as the two most influential predictors. Both are statistically significant, which means they have a dependable relationship with purchase likelihood. As either variable increases, the probability of purchase shifts in a meaningful way. For a business audience, this translates into simple guidance. Customer behavior varies across age ranges and income levels, so marketing efforts are more effective when they are tailored to those segments. High-income customers may respond differently to promotions than lower-income customers, and certain age groups may be more receptive to specific products or messaging.

By identifying which groups are more likely to convert, a company can allocate its marketing budget more efficiently and strengthen retention among high-value customers. This is where logistic regression becomes more than a math exercise. It becomes a decision tool. And with Copilot handling the technical translation, analysts can focus on crafting recommendations that are actually useful to the business.

Model refinement and improvement

Once you have a basic interpretation of the model, the natural next question is whether it can be improved. Copilot can help you explore those possibilities just as easily as it handled the diagnostics and interpretation. I asked it:

“Suggest ways to improve model performance further. Should we add interaction terms, polynomial features, or apply feature selection techniques? Guide me through these options.”

Copilot suggested several paths forward. Interaction terms like Age × EstimatedSalary can capture effects that a simple additive model might miss. Polynomial features can help address the nonlinear behavior we saw with EstimatedSalary in the Box Tidwell test. Feature selection methods can refine the model by focusing on the strongest predictors while reducing noise. These are the kinds of steps analysts consider once the baseline model is understood and the assumptions have been checked. None of them guarantee better performance, but they offer structured ways to experiment and push the model further.

Conclusion

Logistic regression becomes much more approachable when Python and Copilot are available directly inside Excel. You can explore patterns, check assumptions, and interpret results without switching tools or fighting with add-ins. Copilot handles the mechanics and keeps the explanations clear, so you can focus on what the model is actually telling you.

At the same time, this workflow shows that even a clean dataset has limits. Logistic regression depends on certain assumptions, and real data does not always line up perfectly. EstimatedSalary’s nonlinear behavior is a good example. The model still works, but it hints at opportunities to improve things through transformations, interactions, or more flexible approaches. Copilot helps you explore those options, but your judgment guides the final call.

The big takeaway is that building and understanding models in Excel is no longer a chore. With Python and Copilot, you can create an interpretable model, evaluate it, and translate the results into real business insight. From here, you can refine the model, test new features, try different thresholds, or compare logistic regression with tree-based methods. Whatever direction you take, this workflow gives you a solid foundation to keep going.

The post Python in Excel: How to do logistic regression with Copilot first appeared on Stringfest Analytics.

But here’s the catch: Advanced Analysis expects neatly structured datasets with clear rows and columns. Optimization problems, however, usually involve exploring relationships between variables, calculations, and constraints, making them quite different from typical data analysis tasks.

That means we’ll need a creative workaround, but it’s also a great chance to rethink optimization and discover what’s possible with Excel and Python together. Ready? Open a blank workbook and type “Advanced Analysis with Python” into Copilot to launch Advanced Analysis and get started.

Example 1: Product optimization

Product optimization is a classic analytics problem, and Python in Excel gives us a surprisingly clean way to model it without Solver. In this example we’re working with a simple two-product scenario. I frame it almost like a word problem: lay out the parameters, constraints, and objective in plain language, then hand the entire setup to Copilot.

Copilot interprets the problem and returns the optimal solution:

The entire optimization model is translated into and then executed in Python. It’s helpful to look at the code Copilot generates behind the scenes:

If you know Python, you’ll notice it uses plain lists, tuples, and NumPy arrays rather than DataFrames, even though Python in Excel normally wraps most inputs and outputs as DataFrames. That difference introduces a little friction when you’re doing optimization inside Excel. You’ll may notice in the following examples that important final values like total profit or total cost don’t always appear in the results, because they don’t fit cleanly into the output DataFrame Copilot creates. When that happens, you may need to ask Copilot for those numbers directly or print them from the code yourself.

Still, the workflow is straightforward: describe the optimization problem clearly, pass it to Copilot, and let Python build and solve the model directly inside Excel.

Three-product optimization with added constraints

Here’s a slightly more realistic scenario. Instead of choosing between two products, we now have three: A, B, and C. Each one has different profit margins and different demands on labor and material, and now we add real-world constraints like minimum production and maximum capacity. Again, I describe the entire optimization problem in plain language, just as you’d see it in a textbook or case study, and hand that straight to Copilot.

Copilot interprets the structure, builds a Python optimization model underneath, and returns the production plan.

Python decides that the best mix is roughly 13 units of A, 49 units of B, and zero units of C. That result fully respects the labor and material limits, meets the minimum production requirement for A, and stays under the cap for C.

As with the previous example, you don’t automatically see the total profit or resource utilization in the output table. Those values exist in the Python environment (or could be easily produced), but they’re not displayed unless you explicitly ask for them.

Minimizing shipping costs across locations

This last example shifts from production planning to a classic transportation problem. We have two warehouses and three retail stores, each with its own shipping cost, capacity, and demand. Again, I describe the entire problem as a word-problem: the costs, the capacities, the store requirements, and the objective of minimizing total shipping cost.

Copilot takes that plain-language description, builds the underlying optimization model in Python, and returns the shipment plan.

Warehouse 1 fully supplies Store 1 and part of Store 3, while Warehouse 2 picks up the remaining demand for Stores 2 and 3. Some routes end up with zero shipments because the optimizer naturally avoids expensive or unnecessary paths. And just like before, the output appears as a small DataFrame because that’s the default format for Python in Excel. If you want additional information like the total minimized cost you’d need to ask Copilot for it or extract it directly from the Python code.

Want to check your results against mine? Download the solution workbook below:

In summary, while Excel users traditionally turn to Solver for optimization, Python in Excel’s Advanced Analysis offers an attractive alternative. This approach simplifies model building by allowing users to frame optimization scenarios clearly in everyday language, bypassing Solver’s often complex interface. Leveraging Python’s powerful analytical capabilities directly within Excel makes this method intuitive and accessible.

However, it’s important to recognize some limitations. The optimization packages available within Python in Excel—primarily SciPy, NumPy, and pandas—can effectively handle many scenarios similar to Solver’s linear and nonlinear optimization tasks. Yet, advanced capabilities such as integer programming (available via Solver’s GRG or Evolutionary engines) or convex optimization tasks typically handled by specialized libraries like PuLP or CVXOPT aren’t supported within the current Python environment in Excel.

Additionally, users may encounter issues where essential outputs, like total profits or minimized costs, aren’t immediately visible and require manual extraction from the Python environment or additional prompts to Copilot.

By clearly defining optimization problems in plain language and using Python libraries available in Excel, you can streamline complex modeling tasks and gain practical insights without leaving the familiar Excel interface.

The post Python in Excel: How to build optimization models with Copilot first appeared on Stringfest Analytics.