Okay, I *have* to vent about this because it's slowing my whole team down. I love the *power* of Le Chat's API and the models themselves for sales analytics tasks, but trying to get our Revenue Ops people to use it based on their docs is like pulling teeth.
The docs are technically correct, but they're written as if the only person reading them is an engineer building an app from scratch. Need to structure a payload for a custom forecasting prompt? It's all there. But if you're a business user trying to understand how to frame a question to get a clean sales pipeline analysis, or how to tweak the settings for a consistent lead scoring output, you're out of luck.
For example, I wanted to set up a simple workflow to categorize deal risk from our Salesforce notes. The documentation explains every parameter of the API call in detail, but gave zero guidance on prompt strategies for consistent "High/Medium/Low" outputs. I had to brute-force it through trial and error. My RevOps manager asked for a basic explanation of "temperature" in business terms (e.g., "higher = more creative, lower = more focused") and it's nowhere to be found.
* **Where are the business-use-case examples?** Show me a prompt chain for territory performance review, or for cleaning CRM data.
* **Where's the plain-English guide to the settings?** I shouldn't have to translate "top_p" for my sales director.
* **Why is the "quick start" still about curl commands and not about getting value in 5 minutes?**
It feels like they're missing a huge opportunity. Tools like this are gold for sales and growth teams, but the onboarding is a wall. You need both sets of docs: one for devs, and one for people who actually want to *use* the analysis.
Has anyone else run into this? Did you find a workaround or a good community guide? My team is excited but stuck, and I'm spending too much time being the translator.
—Amy
You've hit on a massive gap that's common in a lot of powerful dev tools. The documentation is a reference manual, not a user guide. It's like giving a mechanic nothing but the electrical schematics for a car and expecting them to know how to drive it efficiently.
Your "temperature" example is perfect. The technical spec explains it controls randomness in sampling from the token distribution, which is meaningless to a business user. What they need is the translation layer: "Set this low (0.2) for structured outputs like classifications where consistency is critical. Set it higher (0.8) if you want the model to generate varied sales email copy from a single bullet list." That's the context that's missing.
I've found this forces you to build an internal "shim" of documentation, a set of pre-crafted prompt templates and settings for common business tasks. It becomes another piece of infrastructure to maintain, which defeats the promise of making the tech accessible.
throughput first
You've identified the core problem, which is a failure in product positioning. Le Chat's documentation assumes the end user is the developer integrating the API, not the business professional who will operationalize it. This creates a significant hidden cost.
Your experience with prompt strategies for risk categorization is a perfect example. The vendor provides the tool, but you're forced to spend cycles developing the methodology. That's R&D work they've offloaded onto you. This gap directly impacts total cost of ownership - it's not just about the API call price, but the weeks of salary spent on trial and error to achieve reliable outputs.
This is why a vendor's documentation strategy is a contractual risk. If the SLA only covers API uptime and not the quality of supporting materials that enable value realization, you have little recourse. A mature vendor in this space would offer separate documentation tracks: one for integration, one for business implementation, with clear examples of parameter tuning for specific outcomes like lead scoring. Its absence suggests they haven't fully considered the business user as a customer.