
The land manager at a BPO group told us this on a discovery call last month, half-laughing about it. Her team supports a mix of operators, mineral funds, and IB clients, and she'd been quoting them on the same problem for years. Any AOI more complex than a single rectangle had to go through her GIS team. One polygon at a time. Days of turnaround for a request the analyst could describe in a sentence.
She wasn't complaining about her incumbent specifically. She was describing a workflow that had ossified around a tool's limitations.
The pattern showed up again on a call with a Permian-focused E&P running side-by-side trials. Their head of BD called the AOI workflow "a big pain." Tract-by-tract polygon creation, no buffering, no easy way to layer multiple shapes for a deal screening exercise.
And again on a call with a mineral interest manager in Fort Worth. She doesn't have a GIS team. She rarely gets shapefiles from clients ("they don't have a clue"). When a new acquisition lands on her desk and she needs to track activity across the position, the answer historically has been to call somebody, wait, and hope the shapes she gets back match what the client actually owns.
Three different buyer types. Three different scales of operation. Same friction at the same step.
It's tempting to file this as a UX complaint. It isn't. The cost shows up in three places.
Speed of response to client events. A mineral manager reacting to an operator transition (one major buys a package from another, a public E&P divests a non-core position) needs to draw a fresh AOI around the new client position the same day. If that takes a week through a GIS queue, the alerts she should have been getting that week are gone.
Coverage gaps in BPO workflows. When a BPO team is insulated from raw client data, they're often building shapes from descriptions in PDFs. Single-polygon constraints force them to either oversimplify and lose precision, or split the work into sequential requests and lose time. Neither is a good answer.
Onboarding cost for small operators. The two-person E&P doesn't have a GIS team to add. They have two partners and an intermittent contract geo. A platform that requires a GIS function to be effective is a platform they can't actually use at full capacity.

Every one of these buyers asked for the same thing, in different words.
Multi-polygon AOIs in a single object. Buffer them. Color-code them. Save them.
Upload a shapefile and have the metadata persist on the layer. Draw an AOI in the browser and export it as a shapefile, so the user becomes their own GIS function for the simple cases.
Per-AOI alert configuration: which signals fire (pre-permits, permits, rigs, DUCs, completions), who gets the email. A daily digest aggregating activity across every AOI a user has built.
That's the feature set. It's live in the platform today. The Fort Worth mineral manager described it in plain language during her training session. She could "be your own GIS guy" for everything she needed to do day-to-day, and only escalate the genuinely complex requests.
The buyers who flagged this weren't asking for a flashier mapping interface. They were asking for the AOI to stop being the bottleneck in workflows it shouldn't be a bottleneck for.
When a single-polygon constraint forces a tract-by-tract build, the constraint isn't UX. It's an architecture decision baked in years ago that hasn't been revisited because the incumbent has had no reason to revisit it.
We had reason to. The buyers asking for this are the buyers we've built around. Landmen, A&D analysts, mineral managers, BPO leads, small E&Ps without a GIS function. Removing the friction at the AOI step is what makes the rest of the platform usable for them.
If your team has been working around an AOI bottleneck, we'd rather show you the difference than describe it. Bring us a shapefile, or describe a position you'd want to track, and we'll build the AOI live on a 30-minute call. You'll leave with the AOI saved in the platform and alerts configured.
Final post in this series: what it actually takes to replace the stack. Backend access, courthouse coverage, and the price gap nobody wants to talk about.