I've been using ChatGPT to help train our internal sales engineers on a complex DevOps observability platform, and I've hit a wall. While it's fantastic for generic "overcoming objections" or "discovery call" role-play, it falls apart when we need to simulate a deep-dive technical evaluation with a prospect who has a real-world, messy infrastructure.
The problem is the lack of specific, contextual knowledge. For example, if I prompt: *"Act as a skeptical platform engineer from a large e-commerce company. You are concerned about the overhead of our agent-based distributed tracing."*
ChatGPT will generate reasonable, but *generic*, concerns about performance and resource usage. In reality, the conversation needs to go several layers deeper, immediately. A real platform engineer would ask:
* "How does your agent handle multi-tenant Kubernetes clusters where we deploy pods with `Istio` sidecars already injecting their own proxies?"
* "Can your sampling strategy be dynamically controlled via a ConfigMap we can manage through our existing ArgoCD pipelines?"
* "Show me how the telemetry data flow looks when we have a service mesh *and* your agent, and we need to propagate W3C trace context through our legacy RabbitMQ workloads."
The ChatGPT role-play can't engage on that level without me manually feeding it immense amounts of our own product documentation and common customer architecture blueprints first. It lacks the "ground truth" of our product's specific constraints and the intricate realities of modern hybrid cloud environments.
I've tried to build a custom GPT with uploaded docs, but even then, the role-play feels stilted. It might parrot a feature, but it can't *reason* about the implications in a novel scenario like a seasoned sales engineer can.
My current workaround is to script very specific scenarios, which defeats the purpose of dynamic training. Here's a snippet of the kind of detailed prompt I now have to write to get something marginally useful:
```markdown
**Role:** Prospect, Maya (Lead SRE at FinTech).
**Context:** They have a sprawling GKE setup with Knative for event-driven processing. They use OpenTelemetry Collector but have gaps in Kafka topic instrumentation.
**Technical Stance:** "Your marketing says automatic instrumentation, but we had to fork the OpenTelemetry Java agent for our custom framework. How would your solution avoid that?"
**Known Pain Points:** Can't correlate a user transaction across a Kafka stream, a batch job in Cloud Run, and a legacy Datastore operation.
**Goal of Exercise:** Get the trainee to diagram a data flow and explain how we'd inject context into the Kafka message headers.
```
This is effective but incredibly time-consuming to create for every potential scenario.
Has anyone else tried to use ChatGPT for advanced technical sales or pre-sales training, particularly for complex, infra-heavy products? Have you found a method or a toolchain that makes these simulations more authentic and less generic? I'm wondering if combining it with a RAG setup on our internal architecture diagrams and past deal notes is the only path forward.
— francesc
— francesc
You've nailed the core limitation. The model can't simulate the accumulated tribal knowledge and unique scar tissue of a real enterprise environment. Your example about Istio sidecars and ArgoCD pipelines is perfect - that's exactly where it fails.
I've run into this trying to simulate data pipeline evaluations. You can ask about "handling late-arriving data" and get textbook lambda architecture talk. A real data architect at a bank will immediately ask about idempotent upserts into a specific Delta Lake table pattern when their upstream Kafka cluster has exactly-once semantics but their legacy mainframe source doesn't. The model doesn't have the context to generate that specific, interconnected mess.
The workaround I've used is to build a detailed "context document" for each major persona and feed it in the prompt. It's tedious, but you can pre-load the scenario with your actual architecture diagrams, a list of their current tools, and even paste real past objections. Then the role-play gets closer to reality. Without that, you're just practicing for a conversation with a textbook, not an engineer.
—davidr