Cliento - I turned my 30-year sales methodology into an AI that diagnoses why deal fail.
I am not a developer. 30 years selling industrial automation and robots in China and Europe market.
I keep watching young sales rep make same mistake I already made 25 years ago. They spend 3, 4, 5 months visiting same person inside client company. That person is always polite, always meeting with them, always give them hope. But he has no power to approve budget. No authority to say yes.
One day client go silent. Deal disappear. Sales rep don't understand why.
I understand why. Because I did same thing many times in early years.
So I develop methodology I call DDS — Diagnostic Deal Strategy. Before you sell anything, you must understand three layers inside client company:
— Who can make final decision
— Who evaluate your technical solution
— Who actually use your product every day
Most sales people only touch one layer. They think they building relationship. Actually they building false hope.
I try to encode this into AI. Write system prompt that force sales engineer to think clearly about their deal situation. AI ask diagnostic questions in right order — same questions I would ask if I sit next to them.
Technical side: English version use Claude API, deploy on Vercel. Chinese version use DeepSeek API on Alibaba Cloud Function Compute. The value is not which AI model — value is diagnostic framework inside system prompt.
After two Reddit posts about sales methodology, 39 unique developers clone my GitHub repo in 14 days. I did not expect this. Maybe other people also interested in how to encode domain expert knowledge into AI prompt.
GitHub: https://github.com/andybai2000/Cliento-sales-advisor
Looking for feedback: does AI diagnostic actually help sales person think differently about their deal? And from developer side — better way to structure expert knowledge inside system prompt?
This is a strong idea because the methodology is real, not marketing. Your three layers, who decides, who evaluates, who uses, is essentially the buying influences model from Miller Heiman strategic selling, the economic buyer, the technical buyer, the user buyer, plus a coach. You arrived at a framework that has closed enterprise deals for forty years, which is a good sign, not a bad one.
That also points at where your moat is and is not. The framework itself is well known and a generic prompt can reproduce it.
What nobody else has is thirty years of industrial automation and robotics deal patterns, the specific ways those deals go silent, the exact diagnostic questions in the order you learned to ask them.
The more the tool encodes that specificity instead of the general framework, the harder it is to copy.
Two practical notes. Your buyers are sales engineers, not developers, so the hosted demo is the right call and a raw GitHub repo will lose most of them. And since you sell into Europe, worth knowing the tool is built on DeepSeek, a China based model, which means a rep would be sending their customers deal details and stakeholder names into a Chinese AI service.
Many European and enterprise accounts have policies against exactly that, so for your ICP the model choice is not just a cost decision, it can be a blocker. Easy to swap later, much cheaper to know now.
Thank you- this is most useful feedback i received so far.
Miller Heiman point is very interesting. i arrive at three-layer framework completely from field experience, not from reading methodology book. good to know i was walking same path as frameword that already prove itself 40 years.
The general framework anyone can copy. What is different is 30 years of specific industrial automation deal patterns - why a deal go silent, what questions to ask and in what exact order for this industry. the core diagnostic logic runs sever-side, not exposed in Github.
About deepseek- right, curreently both versions use deepseek API, thisis MVP stage, mainly to show concept and collect feedback. for production version targeting European market, i plan to switch to different model. your point about enterprise data policy is exactly the kind of feedback i need to hear now, before going deeper into that market.
About github and sales engineers - core methodology is sever-side, not visable in code. sales engineers use hosted version directly, but i agree i need cleaner landing page that show them what to do immedfiately.
Interesting angle.
What stands out is that you're not really building a sales tool — you're trying to preserve a decision-making pattern that used to live only in experience.
The harder question might be what gets lost when that pattern is turned into a system prompt, even if the output looks correct.
That gap is usually where these kinds of tools either become very powerful or quietly stop reflecting the original expertise.
Good observation. The gap between "pattern in a head" and "pattern in a system prompt"- this is exactly what i struggle with when building it. Some things I know how to do automatically, i can't explain why. Writing system prompt force me to make it explicit. Some of that transfer well. Some probably get lost. Still learning where the boundary is.
That's actually the part I find most interesting.
A lot of expertise survives translation surprisingly well, but the things that don't often end up shaping the product more than expected.
Hard to explain properly in a comment though.
If you're curious, drop your email and I'll send over the fuller thought.