A recent OpenAI support interaction sparked a few key questions worth examining:
- Why is the world’s leading AI company still running on a traditional support stack?
- If AI agents are ready to replace software, why isn’t OpenAI using them internally?
- What does it reveal about the current limits of “AI automation” in real-world operations?
- Is the challenge really in the software — or in the last-mile human layer that connects systems?
- What would genuine AI-driven customer service look like if built from the ground up?
- How far can we evolve existing tools like Salesforce and Zendesk before full reinvention makes sense?
- Is the future about replacement — or augmentation and evolution of proven systems?
Introduction
The real-life support interaction with OpenAI went smoothly — very fast replies, clearly agent based, but natural (though still obviously not human). I was curious to see what their tech stack looked like. The result was unsurprising — fairly standard industry support tools.
Overthinking a support interaction.
The question it raised for me was this: If AI is going to replace traditional software, why is the most advanced AI company — the literal poster child — using a traditional stack?
Surely OpenAI could easily build something custom and eliminate the middleman. That’s the AI industry narrative (Replit, Cursor, Windsurf, Claude code) “Vibe code” everything – bypass the service contracts.
That’s what they tell us we can do. But they don’t practice what they preach – they do not do it themselves. Why?
Why would you?
The middleware is not the problem. In this case, the middleware — Salesforce, Zendesk, and SendGrid — just connects a problem to a solution, each piece of software being a link in a chain.
We are used to having a human as the last link in the chain – with varying degrees of success. But it is not the middleware that solves the problem; it is just part of the stack that serves specific purposes such as sending an email or managing case data.
It is not broken, do not fix it, but do improve it.
Developing Agency (Agency: Replacing the human solving your problem with an AI agent solving your problem) at the last mile is a better use of resources for OpenAI than reinventing the wheel.
This shifts some perceptions about what AI will actually do. I do not see the logic in replacing tried and tested secure systems, with mature development paths and constant security updates, with something new and unproven. That said, I can see the merit for a small company in avoiding crippling service contracts.
So where is the middle ground?
Agency at the end is a necessary evolution. That agent needs to be better than the best human customer service representative, not worse than the worst, which is roughly where we are now. Humans still have a role. The 80–20 rule and the law of diminishing returns, suggests automating the last 20 percent will almost certainly fail. That is the role for the best support agent.
Imagine a company where the Level 1 agent is practically perfect, like Mary Poppins, resolving 80 percent of issues at a five star level, while Tank, the operator from The Matrix, is standing by for the final 20 percent.
Combine that with a feedback loop that eliminates root causes of recurring issues, and you have a sustainable support system. It’s that option or letting AI run wild in your organisation and expecting a similar outcome.
It looks to me like OpenAI have chosen the former.
Technology evolves; it does not replace. Teslas still have wheels. They did not try to fly; they kept the car bonnet shape because that is proper evolution.
So while systems like Salesforce can feel bloated with large service contracts, the software layer itself still makes sense. Perhaps there is an opportunity to create a lighter, black box, interface free version, in the same way that a robot factory does not need the lights on.
For now anyway I’m bullish on SaaS but it must evolve, shed the bloated belly, the used car sales man sales tactics and it must integrate Agents that actually give a 5 star experience.
TLDR; Investigation Summary
Starting with support email link a corpus mind and chat GPT to answer my questions, here’s what I observed.
1. Email Tracking Link
Observation: http://url3243.email.openai.com/ls/click?upn=…
Evidence and analysis: email.openai.com is a SendGrid or Iterable style mail tracking subdomain. The ls/click?upn= path and long encoded blob are standard click tracking links containing destination, recipient, and signature data. Decoding shows only opaque Base64 segments separated by dots and underscores, consistent with an encrypted payload and authentication signature.
Conclusion: OpenAI’s outbound support emails are routed through a tracking gateway, likely SendGrid or Iterable, that records click events before redirecting to the real destination.
2. Redirect Target
Landing URL: https://csat.help.openai.com/?key=%7B!Case.Hashed_ID__c%7D&score=3
Evidence: help.openai.com loads assets from zdassets.com and contains the meta tag “Zendesk Help Center.” The URL path uses the /hc/en-us/articles/ structure unique to Zendesk. The CSAT subdomain, csat.help.openai.com, matches Zendesk’s survey form pattern.
Conclusion: help.openai.com is Zendesk hosted. It serves OpenAI’s public help center and satisfaction forms. Zendesk equals the support portal frontend.
3. Embedded Parameters
Decoded parameter: key={!Case.Hashed_ID__c}
Evidence: {!…} is Salesforce merge field syntax. Case. prefix indicates the Salesforce Case object. Hashed_ID__c, with the __c suffix, denotes a custom field created within a Salesforce organisation.
Conclusion: Outbound emails and survey links are generated from Salesforce Service Cloud, which manages case data. The field {!Case.Hashed_ID__c} is a custom hashed identifier substituted at send time to reference each case securely. Salesforce equals the backend CRM and email system.
4. Integration Logic
Chain of systems inferred:
1. Salesforce (case and email template) generates merge field link.
2. SendGrid or Iterable (email delivery and click tracking) wraps link with tracking blob.
3. Zendesk (help portal and CSAT form) receives link, renders survey, writes response back to Salesforce via hashed key.
Evidence support: Merge token syntax and hashed field equal Salesforce. Help domain infrastructure equals Zendesk. Tracking subdomain equals SendGrid or Iterable style.
5. Confidence Levels
Confidence summary: • Zendesk – High confidence based on HTML generator tag, URL pattern, DNS hosting. • Salesforce – Strong inference based on merge field syntax {!Case.Hashed_ID__c}. • SendGrid or Iterable – Probable based on tracking domain format. • Custom hashed ID field – Confirmed by naming convention (__c). • Combined workflow – Logical deduction matching industry standard CRM to tracking to portal chain.
6. Final Synthesis
OpenAI’s customer support stack almost certainly functions as follows:
Salesforce Service Cloud (case and email templates) ? sends via SendGrid or Iterable (tracking) ? redirects to Zendesk Help Center (help.openai.com) ? collects CSAT feedback mapped back to the Salesforce case through a custom hashed ID.
Disclosure. No public document states this directly, but the URLs, merge field syntax, and hosting signatures make this structure the only plausible interpretation. Of course this could be wrong and if anyone in openAI wishes to submit a correction then please do so.