<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Enterprise on Murat Eksi</title><link>https://murateksi.com/tags/enterprise/</link><description>Recent content in Enterprise on Murat Eksi</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 09 May 2026 20:00:00 +0200</lastBuildDate><atom:link href="https://murateksi.com/tags/enterprise/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Run a Program Reset Without Losing the Customer</title><link>https://murateksi.com/posts/program-reset/</link><pubDate>Sat, 09 May 2026 20:00:00 +0200</pubDate><guid>https://murateksi.com/posts/program-reset/</guid><description>Every enterprise delivery that runs long enough will have a moment where the program is not going as planned. The timeline has slipped, the scope has expanded beyond what the original budget can absorb, a key technical assumption turned out to be wrong, or an organizational change on the customer side has made the original delivery plan unworkable. When this happens, the account team faces a choice that determines whether the customer relationship survives the delivery.</description></item><item><title>Write the Account Plan for the Account, Not the Forecast Call</title><link>https://murateksi.com/posts/account-plan-for-the-account/</link><pubDate>Sat, 09 May 2026 18:00:00 +0200</pubDate><guid>https://murateksi.com/posts/account-plan-for-the-account/</guid><description>The account plan as most organizations practice it is a document that exists to demonstrate to management that the account team has a plan. It is reviewed at the beginning of the year, updated at mid-year, and referenced again during QBR season. It contains the right sections: whitespace analysis, organizational map, strategic objectives, opportunity list, competitive positioning. It is usually accurate at the point it is written and increasingly fictional by the time it is reviewed.</description></item><item><title>The Discovery Call Is a Diagnostic, Not an Interview</title><link>https://murateksi.com/posts/discovery-call-diagnostic/</link><pubDate>Sat, 09 May 2026 16:00:00 +0200</pubDate><guid>https://murateksi.com/posts/discovery-call-diagnostic/</guid><description>The discovery call template most enterprise AEs use is a list of questions. Budget, authority, need, timeline. Current state, desired state, gap analysis. Pain points, priorities, decision criteria. The questions are reasonable and the answers are useful. The problem is that the customer can see what you are doing and it does not build the kind of trust that moves a complex deal forward.
An interview extracts information from a subject.</description></item><item><title>The Deal You Have to Sell Twice</title><link>https://murateksi.com/posts/internal-selling/</link><pubDate>Sat, 09 May 2026 14:00:00 +0200</pubDate><guid>https://murateksi.com/posts/internal-selling/</guid><description>Every enterprise deal that closes requires two sales. The first is visible: the commercial conversation with the customer, the architecture reviews, the business case, the contracting. The second is nearly invisible to anyone outside the account team: the internal sale that gets the deal the resources, the attention, and the organizational commitment it needs to actually deliver.
Most account planning frameworks cover the first sale in detail. Discovery, qualification, stakeholder mapping, champion development, closing.</description></item><item><title>Why the Biggest Q1 Deals Rarely Close in Q2</title><link>https://murateksi.com/posts/q1-pipeline-illusion/</link><pubDate>Sat, 09 May 2026 11:00:00 +0200</pubDate><guid>https://murateksi.com/posts/q1-pipeline-illusion/</guid><description>By the second week of January, the enterprise sales pipeline looks like it always does: full of enormous deals that are finally moving after the Q4 freeze, newly prioritized initiatives with executive sponsors who are energized after the year-end planning cycle, and customer conversations that have shifted from &amp;ldquo;let&amp;rsquo;s revisit this in the new year&amp;rdquo; to &amp;ldquo;yes, now is the right time.&amp;rdquo;
By the second week of March, the Q2 forecast is already revealing itself.</description></item><item><title>The Customer Who Will Expand and the One Who Will Not</title><link>https://murateksi.com/posts/customers-who-expand/</link><pubDate>Sat, 09 May 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/customers-who-expand/</guid><description>Account expansion is supposed to be simple. Deliver well, earn trust, grow the relationship. The formula is repeated in every sales methodology and every QBR template. It is also incomplete in a way that causes most account teams to misread their book and misallocate their time.
The customer who expands and the customer who does not are usually indistinguishable at the point of initial close. Both are genuinely excited about the platform.</description></item><item><title>How to Run a Proof-of-Concept That Moves a Deal Forward</title><link>https://murateksi.com/posts/poc-engagement-that-moves-deals/</link><pubDate>Sun, 03 May 2026 16:00:00 +0200</pubDate><guid>https://murateksi.com/posts/poc-engagement-that-moves-deals/</guid><description>The PoC graveyard is full of technically successful projects. The architecture was sound. The performance metrics exceeded the benchmarks. The delivery team did excellent work. The customer&amp;rsquo;s engineering lead sent a glowing summary to the account team. And then nothing happened for eight weeks, and then a request to extend the evaluation, and then a change in internal priorities, and then the deal died.
A technically successful PoC that does not close a deal is not a failure of execution.</description></item><item><title>The Organizational Pattern Behind Every Platform Deal That Dies in Contracting</title><link>https://murateksi.com/posts/platform-deals-die-in-contracting/</link><pubDate>Sun, 03 May 2026 14:00:00 +0200</pubDate><guid>https://murateksi.com/posts/platform-deals-die-in-contracting/</guid><description>The pattern is consistent enough that I can describe it before the AE does. The deal ran for four months. The technical evaluation was rigorous and went well. The customer&amp;rsquo;s architecture team recommended the platform. The champion sent a message saying the hard part was done and it was now just a matter of getting the paperwork sorted. That was eight weeks ago. Since then: silence, then a brief message about internal process, then a request to pause, then nothing.</description></item><item><title>What the Executives Who Build Durable Partnerships Do Differently</title><link>https://murateksi.com/posts/executives-who-build-durable-partnerships/</link><pubDate>Sun, 03 May 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/executives-who-build-durable-partnerships/</guid><description>In six years of enterprise cloud sales across EMEA, I have worked with two kinds of senior technology executives. The first kind builds technology partnerships that define their organization&amp;rsquo;s capabilities for the next decade. The second kind reviews vendor contracts every three years, runs competitive procurement cycles, and is perpetually disappointed by the results.
Both kinds of executive are intelligent, well-resourced, and trying to make good decisions. The difference is not competence.</description></item><item><title>Read the Annual Report Before the First Meeting</title><link>https://murateksi.com/posts/annual-report-primary-source/</link><pubDate>Mon, 27 Apr 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/annual-report-primary-source/</guid><description>The annual report is the primary source document for enterprise selling. I read three of my largest customers&amp;rsquo; annual reports every year, in full, before their next planning cycle starts. I have never met another AE who does this systematically.
That gap is not an accident. Annual reports are long, dense, and require you to hold more than a single sentence in mind at once. Most enterprise sales training focuses on the sales process, not on what to understand before the process begins.</description></item><item><title>The Deals That Stall on Security Were Already Lost</title><link>https://murateksi.com/posts/security-posture-as-sales-accelerant/</link><pubDate>Wed, 22 Apr 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/security-posture-as-sales-accelerant/</guid><description>Every enterprise AE has a version of this story. The deal has been running for three months. Commercial terms are agreed. The implementation team has done a discovery session. You are writing the statement of work. Then the customer&amp;rsquo;s CISO asks to do a security review.
Four weeks later, the deal is dead. The review found issues with data residency, or encryption at rest, or the customer&amp;rsquo;s interpretation of their own regulatory obligations around where compute runs.</description></item><item><title>Nine Languages, One Practice: Notes on Operating Multilingually</title><link>https://murateksi.com/posts/nine-languages-one-practice/</link><pubDate>Mon, 20 Apr 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/nine-languages-one-practice/</guid><description>When I tell people I work in nine languages, the first reaction is usually either skepticism or the assumption that this means I switch fluently between them in every meeting. Neither is right.
The operational reality of a nine-language practice across EMEA is different from what the phrase suggests, and what it has taught me about organizational design is probably the most transferable thing I have learned in the last four years.</description></item><item><title>The Meeting That Actually Closes Enterprise Cloud Deals</title><link>https://murateksi.com/posts/architecture-review-closes-deals/</link><pubDate>Tue, 14 Apr 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/architecture-review-closes-deals/</guid><description>Somewhere in every serious enterprise cloud deal is a meeting that looks like a technical checkpoint. Someone from the customer&amp;rsquo;s architecture team asks how the proposed platform handles multi-region failover, or what the data residency story is, or why the migration path doesn&amp;rsquo;t start with a pilot. The salesperson checks their watch and waits for it to end.
That meeting is where the deal is won or lost.
What happens in an architecture review The technical reviewers in that room are rarely trying to block the deal.</description></item><item><title>Predictive Maintenance at Fleet Scale with Sparse Failure Data</title><link>https://murateksi.com/case-studies/industrial-predictive-maintenance/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://murateksi.com/case-studies/industrial-predictive-maintenance/</guid><description>The customer had a simple idea: if their platform could tell operators which machines were likely to fail before they failed, the customers would pay a premium for that signal. The idea was right. The path to production was not the one anyone planned.
The problem with the obvious approach Predictive maintenance models learn from failure events. To predict a bearing failure, you need historical data showing what the sensor readings looked like in the hours and days before the bearing actually failed.</description></item><item><title>Enterprise AI Adoption: The Gap Between Demo and Production</title><link>https://murateksi.com/posts/enterprise-ai-adoption-reality/</link><pubDate>Thu, 18 Dec 2025 09:00:00 +0100</pubDate><guid>https://murateksi.com/posts/enterprise-ai-adoption-reality/</guid><description>I have watched dozens of enterprise AI initiatives launch with real executive buy-in and stall within six months. The pattern is consistent enough that I can usually predict which ones will make it by the end of the first architecture review, before a line of model code has been written.
The model works on clean data. Production data is not clean.
The question nobody wants to ask first Every AI conversation in an enterprise starts with &amp;ldquo;what model should we use?</description></item></channel></rss>