Every once in a while, we run into a data problem that stops us in our tracks. The data is all right there on the screen, but it has been organized in a way that only one person fully understands, and that person is not available to explain it.

We recently hit one of those problems with a client of ours. They had a full customer database, years of service history, billing info, segment assignments. All of it lived in Excel. That part wasn’t unusual. What was unusual was how it was structured.

The Spreadsheet That Only One Person Could Read

The file had four separate sheets, one for each customer segment, with hundreds of customers across all of them. Each customer record wasn’t a row. It was a block, four rows tall, with merged cells threaded through it. Row one held segment flags and a grid of service visit dates spread across 17 columns. Row two was the customer name. Row three was notes. Row four was pricing and billing. The segment assignment itself was buried in column A as a semicolon-delimited string: something like “; South 12; PREPAY; Open Invoices.”

Above: A recreation of what the spreadsheet looks like.

This worked fine for the person who built it. They knew exactly how to read it. For any tool trying to import it, it was completely illegible. Standard tools assume one row equals one record. This spreadsheet needed its own map!

That alone was a hard enough problem. But there was another layer.

The Color Problem

Payment status wasn’t stored in a column. It was stored as cell background color. A solid background color on a date cell meant that invoice had been paid. White fill meant it was still open. That meant finding unpaid invoices required scanning 17 columns of service dates, across hundreds of customers, across four sheets, every time someone needed to know.

This is where standard tools fully give up. Cell background color isn’t data. It’s just formatting. It lives in the XML layer underneath what Excel renders on screen. No formula in Excel can reference it. No pivot table can group by it. Export the file to CSV and it evaporates entirely. Even most Python scripts, written by developers who know exactly what they’re doing, would miss it unless they happened to know about the right library and the right attribute.

Describing the Problem Is Most of the Solution

We described the spreadsheet to Claude in plain English, not as a technical specification. We described the four-row blocks, the merged cells, and the semicolons in column A. We described the fact that payment status was background color, with solid background color meaning paid and white meaning unpaid.

Claude recognized the structure immediately and wrote a Python script using the openpyxl library. openpyxl reads .xlsx files by parsing the underlying XML directly, bypassing the Excel interface entirely. That’s what makes cell fill color accessible. The attribute cell.fill.fgColor.rgb reads the fill color’s hex value straight from the XML, bypassing what you see on screen. Without knowing that attribute existed, a developer would have no clear path to the color data.

The script walked each worksheet in four-row steps, assembled each block into a single customer record, parsed the semicolon strings with regex to pull the segment name, and checked the RGB value of every date cell. White fill was flagged as unpaid. It also handled the fact that the four sheets had different header sizes (some had three header rows, one had five) without needing separate logic for each.

The output was a flat table: One row per customer, with segment, name, address, price and a clean list of unpaid service dates, formatted with a frozen header row and sized columns and ready to import into any standard CRM.

What Was Actually Unlocked

Why am I telling you this? Why does it matter?

The technical output was a migration file. What actually got unlocked, though, was something more significant.

The entire system (the four-row blocks, the color codes, the semicolons) had existed entirely in one person’s mental model. It wasn’t documented anywhere. It worked as long as they were available to interpret it. It was one departure away from being permanently irretrievable.

Describing this system in plain English to Claude produced code that made that implicit system explicit. The encoding was now documented in the script itself. Even better, after we had the data formatting, we were able to import it into a real CRM. Someone besides the person who had built the original spreadsheet could now access and manage customer data.

Most people, when they hit a spreadsheet like this, either accept it as permanent or spend days reformatting it by hand. Those are the two standard options. The third option, describing what you’re looking at and letting Claude write the translation layer, tends to get overlooked because it feels too simple. The domain expert knows what the data means. Claude knows how to write code that reads it. The gap between “this only works in one person’s head” and “this is now in a CRM” turned out to be one conversation.

That is the part worth sitting with. The biggest wins we have seen with AI are rarely the obvious ones. They show up when someone describes a problem that seems unsolvable and asks whether AI could help, not because they expect it to work, but because they have run out of other options. Nobody walks into a project thinking “I should ask AI to read the RGB value of a cell’s fill color.” But once you describe the problem in plain English, Claude just figures it out. The ceiling on what AI can help with is much higher than most people assume. You just have to be willing to describe the problem before you decide it cannot be solved.