AWS Replaced an 18-Tab Pricing Model With an AI Chatbot. The Interesting Part Isn’t the Chatbot.

Eighteen Excel tabs.

That’s the number that caught my attention.

Not 180. Not 1,800. Eighteen.

In Finance, an 18-tab model is practically a studio apartment. I’ve seen enough sprawling workbooks to know that somewhere, someone is reading this story and thinking, “That’s adorable. Where do they keep the actual model?”

Yet Amazon Web Services made news for turning an 18-tab pricing model into an AI chatbot. According to an October 8, 2026 Fortune interview, AWS CFO John Felton described a pricing team that transformed how employees explore customer-deal economics. Instead of navigating the workbook, people can ask questions about discounts, payment terms and break-even points. They can still export to Excel.

I like that last detail. The spreadsheet wasn’t marched out of the building under security escort. It simply stopped being the only front door.

But I don’t think the most interesting part is the chatbot.

The interesting part is what happens when the person asking the question no longer needs to know which tab contains the answer. That’s a bigger change for FP&A than a prettier interface. It changes who can interrogate the economics, how quickly they can do it, and—if we’re not careful—how confidently they can misunderstand them.

Eighteen Tabs Isn’t a Crime. Being the Only Person Who Understands Them Might Be.

Finance has a complicated relationship with spreadsheets. We complain about them, defend them, build elaborate controls around them and then send each other another one.

Excel itself isn’t the villain. A well-built model can be transparent, flexible and powerful. The real problem is the invisible instruction manual in the model owner’s head.

Which tab controls discount assumptions? Does the payment schedule update automatically? Is break-even calculated on gross profit, contribution margin or some mysterious hybrid invented in a steering committee? What happens if a customer changes volume halfway through a contract?

Someone usually knows the answers. That someone is often on vacation.

I’ve always been less worried about the number of tabs than about the number of undocumented decisions hiding behind them. A 60-tab model with clear inputs, consistent logic and controls can be safer than a six-tab model with a heroic assortment of hardcoded exceptions.

Conversely, a beautifully organized model is not especially helpful if every pricing question requires a finance analyst to stop what they’re doing, translate the request, find the correct scenario and send a screenshot.

That’s the friction AWS appears to be addressing: not simply calculation time, but the distance between a business question and a defensible financial answer.

What AWS Actually Said—and What It Didn’t

Felton told Fortune that the pricing team had used a complex 18-tab Excel model to evaluate customer deals. The new conversational interface allows users to explore questions such as what happens if prices fall 20%, how payment terms change the economics, and where a deal breaks even.

That is a concrete use case, not another AI announcement in which an executive says “productivity” seven times and nobody can locate the actual work.

Felton also described a separate team using an AI agent to compare payment terms in customer contracts against information in the payment system. Instead of reviewing a sample, the team can check the full set of contracts. Those are distinct examples: one changes access to scenario analysis; the other expands the scope of a control activity.

Important distinction: the interview does not disclose the chatbot’s full architecture, validation methodology, cost, measured accuracy or financial return. It doesn’t prove that every employee now makes better pricing decisions. It tells us the interface changed and describes the questions it supports.

I wouldn’t invent a 70% productivity improvement or claim that AWS eliminated spreadsheet risk. That’s not in the reporting.

What I would do is take the example seriously and ask what it means for a finance team considering a similar approach.

The Real Upgrade Is From “Send Me the Model” to “Show Me the Trade-Off”

Imagine a sales leader negotiating a complex deal. The customer wants a deeper discount in exchange for a longer commitment. They also want more generous payment terms, because apparently customers have learned that Finance enjoys surprises.

In the traditional process, Sales sends a message to Finance. Finance asks for missing assumptions. Sales responds with half the assumptions and a deadline. Finance runs three scenarios, adds caveats and sends the output. By then, the negotiation has moved on.

A conversational layer could shorten that loop. The salesperson asks, “What happens to contribution margin if the price falls 15% but the commitment increases 25%?” The system runs the approved logic and explains the trade-off.

That’s useful, provided the approved logic is actually being used.

The point isn’t that the salesperson has become a financial modeler overnight. It’s that Finance has made the model’s questions more accessible without giving up the economics behind them.

I would still want the tool to say what assumptions it used, which version of the model it consulted and what it could not determine. If the system simply produces a confident answer with no visible drivers, we’ve traded a complicated spreadsheet for a very charming black box.

Finance should not confuse ease of use with evidence.

Let’s Price a Deal Before the Chatbot Starts Feeling Too Confident

Here’s a hypothetical example, not an AWS transaction.

A customer is considering a three-year contract with annual revenue of $2 million and annual variable delivery costs of $1.2 million. Ignoring fixed costs and other contract-specific items for the moment, annual contribution is $800,000, or 40% of revenue.

Now the customer asks for a 20% price cut. Annual revenue falls to $1.6 million. If the same services cost $1.2 million to deliver, contribution falls to $400,000, or 25%.

The price fell 20%. Contribution dollars fell 50%. That’s the kind of sentence I’d like every deal team to be able to produce before anyone signs anything.

Then Sales says the customer will increase volume by 30%. Wonderful. Does variable cost rise with volume? Does the company have unused capacity? Are there minimum commitments or tiered rates? If both revenue and variable cost scale proportionally from the discounted unit economics, annual revenue becomes $2.08 million and delivery cost becomes $1.56 million. Contribution becomes $520,000.

That’s better than $400,000, but still below the original $800,000. More volume did not magically undo the discount.

A good model can explain that. A good conversational interface can make the explanation available during the decision rather than in the postmortem.

And a bad interface can produce a very polished answer that leaves out the cost increase. That would be efficient in exactly the wrong direction.

Payment Terms Are Not a Footnote Wearing a Tie

Price gets the attention because everyone understands discounts. Payment terms often get a polite nod before disappearing into the appendix.

But a deal that collects cash in 30 days is economically different from one that collects in 120 days, especially when the business is funding delivery costs in the meantime.

Suppose a customer owes $3 million and payment shifts from 30 to 120 days. That’s roughly 90 additional days of receivables exposure. At a hypothetical annual financing rate of 10%, a simplified carrying-cost estimate is $3 million times 10% times 90 divided by 365, or about $74,000.

That’s an illustration, not a full present-value model. Actual economics depend on billing schedules, collections timing, cost of capital, credit risk and the shape of the contract.

Still, it’s enough to make the point. If the deal team can ask about price but not cash timing, the model is only telling part of the story.

I’d want a conversational tool to connect discounts, payment terms, usage commitments, cost to serve and cash. Not as separate trivia questions, but as related choices.

Otherwise we may approve a deal with excellent reported margin and then spend the next quarter explaining why the cash forecast looks like it needs a nap.

Natural Language Is a Great Interface. It Is Not a Control Framework.

This is where I become the person asking awkward questions at the AI celebration.

What happens when someone types “show me the best deal”?

Best for whom? Highest revenue? Highest margin percentage? Most contribution dollars? Fastest cash collection? Greatest strategic value? The answer changes depending on the objective.

Who decides which assumptions can be changed? Can a salesperson override the cost-to-serve estimate? Can a pricing manager approve a discount outside policy? Does the system distinguish an illustrative scenario from an authorized commercial offer?

And what happens when the model doesn’t know?

I’d much rather have a tool say “I can’t calculate that without the implementation-cost assumption” than invent a plausible answer and send it into a customer negotiation.

A safe design needs approved calculation logic, defined input boundaries, version control, role-based permissions, audit trails and clear escalation rules. The conversational model can interpret the question, but critical financial calculations should be traceable to deterministic logic or independently validated methods.

If the AI is allowed to generate new formulas or choose assumptions dynamically, that needs stronger testing and monitoring.

An 18-tab spreadsheet may be irritating. An ungoverned chatbot that can approve a million-dollar concession is considerably more irritating.

I’d Test the Awkward Questions, Not Just the Pretty Ones

Before releasing a finance chatbot, I’d give it the questions that usually expose the model’s weak spots.

What if the customer gets a 25% discount and uses twice the expected capacity? What if the contract starts mid-quarter? What if a renewal includes a free transition period? What if one product has a different margin structure? What if the user asks for a metric that isn’t defined?

Then I’d compare the answers with independently calculated reference cases.

Accuracy is not just whether the final number matches. I want the right version, correct units, correct sign, complete assumptions and an explanation of why the answer changed.

I’d also test permissions. A regional sales manager should not automatically gain access to confidential deal economics simply because the interface is conversational. And the model should not treat instructions buried in a contract or uploaded document as permission to ignore policy.

Then there are the less glamorous controls: logging, exception monitoring, human review for high-value deals, rollback capability and a way to correct errors without silently rewriting history.

Nobody will make a dramatic keynote video about the rollback procedure.

That’s usually how I know it deserves attention.

The Second AWS Example May Be Even More Important

Felton’s contract-checking example deserves more attention than it might get beside the shiny pricing chatbot.

According to Fortune, a team built an agent to compare payment terms in customer contracts with the terms stored in AWS’s payment system. Previously, the process involved sampling. The new approach can check all contracts.

Think about the shift. A sample-based review asks whether a subset of records suggests a problem. A full-population comparison can identify exceptions across the complete dataset, assuming the inputs are complete and the extraction and matching are reliable.

That changes what Finance can look for. Instead of spending hours collecting evidence for a sample, analysts can investigate mismatches, patterns and causes.

But “check everything” is not the same as “everything is correct.” If the contract terms are extracted incorrectly or the matching logic fails, a full-population process can confidently misclassify thousands of records.

I’d want accuracy testing, reconciliation of the population, exception review and evidence retention. The opportunity is real precisely because the control work matters.

And if AI frees people from manually comparing payment dates so they can investigate why the systems disagree, I will happily applaud. Possibly even without asking for a spreadsheet first.

Don’t Measure Success by the Number of Questions Asked

One temptation with conversational finance tools is to celebrate usage. Thousands of prompts! Hundreds of active users! Look how engaged everyone is!

Lovely. Are the deals better?

I’d want to measure the time from a commercial question to an approved decision, the frequency of pricing-policy exceptions, the quality of margin forecasts, the number of avoidable rework cycles and the accuracy of contract terms in downstream systems.

I’d also look at user behavior. Do people understand the outputs? Do they make fewer unsupported assumptions? Are they escalating the genuinely difficult deals rather than pushing everything through automatically?

Adoption matters, but it is an input. Decision quality is the result.

And there is an uncomfortable possibility worth testing: making scenario analysis easier may generate more scenarios, more negotiation rounds and more management requests. We could save ten minutes per analysis and then triple the number of analyses.

That might be good if the additional questions improve decisions. It might be terrible if we’ve invented a faster way to debate the same discount for six weeks.

I’d measure the outcome, not the chatbot’s social life.

What This Means for Junior Finance Analysts

There’s another part of this story I don’t want to skip.

I’ve raised a similar question about the financial economics behind AI tools: the automation has to create real value, not just an impressive demonstration. If business users can ask a chatbot for pricing scenarios, what happens to the analyst who used to run those scenarios?

Some repetitive work should disappear. I’m not sentimental about making a talented person spend an afternoon changing one assumption and emailing a PDF. We have better things to do with human brains.

But the repetitive work often teaches analysts how the business works. They learn which costs move with volume, why payment terms matter, where margin assumptions break and how a seemingly harmless discount changes the economics.

If the interface makes the work invisible, we need to be intentional about teaching the underlying logic.

I’d want junior analysts reviewing exception cases, testing scenarios, investigating variances and sitting in on commercial decisions. Let them see why the answer changes, not merely that the chatbot produced one.

The goal is to remove unnecessary keystrokes, not the apprenticeship.

Otherwise we may create a generation of finance professionals who can ask excellent questions of a model but have never had to recognize when the answer is nonsense. That is not the leadership pipeline I’d choose.

A 90-Day Pilot I’d Actually Approve

I wouldn’t start by turning every spreadsheet in Finance into a chatbot. That sounds expensive, and it also sounds like the opening scene of a very specific horror movie.

I’d pick one repeatable, high-value decision with established calculation logic. Pricing approvals, renewal economics or contract-term comparisons are plausible candidates.

In the first month, I’d document the current process: the questions people ask, the data they need, the assumptions they change and the errors they make. I’d identify the approved source of truth and the people responsible for it.

In the second month, I’d build a narrow conversational interface and test it against a library of known scenarios. I’d include deliberately confusing questions, missing inputs, conflicting instructions and edge cases. I want the system to fail safely before someone tries it on a live negotiation.

In the third month, I’d pilot it with a controlled group, require human approval for consequential decisions and compare results with the existing workflow.

I’d measure decision turnaround, error rates, user comprehension, rework and the economics of the deals being evaluated. Then I’d decide whether to expand, revise or stop.

No fireworks required. If the pilot makes one important process measurably better without weakening controls, that’s a perfectly respectable result.

The Spreadsheet Can Stay. The Bottleneck Doesn’t Have To.

What I like about the AWS story is that the spreadsheet can still be exported. That suggests a useful distinction between the financial engine and the way people interact with it.

Finance has spent years making models more sophisticated. Sometimes we’ve also made them harder for the business to use. Not deliberately. We just know where the assumptions live, what the acronyms mean and why one tab should never be touched after 4 p.m. on a Friday.

An interface that makes sound analysis accessible is progress. But the progress comes from better decisions, not from hiding the tabs.

I want the math to remain inspectable. I want assumptions owned. I want the system to admit uncertainty. I want people trained to challenge the output. And I want someone accountable when a proposed discount changes the economics.

Felton’s example points toward a finance function that can spend less time translating business questions into spreadsheet operations and more time helping management understand trade-offs.

That’s a future worth exploring.

Just don’t tell me we’ve solved pricing because the model now says “Hello! How can I help you today?”

I have eighteen follow-up questions.