@muhammadabdullahAI that catches broken sales promises, from a Flutter dev in Faisalabad
Hi everyone, I'm Muhammad Abdullah, an independent app developer in Faisalabad, Pakistan. I work mainly with Flutter and am comfortable on both the interface and the backend. My background is in data science, and my public projects include a POS app for tracking store sales from a phone, a Horeca app, journal app, and a front end for a coding learning app for students.
I'm now building an AI tool that flags broken sales promises before they turn into disputes. It's built on Gemini. I'm still early, so I'm working out which kinds of promises are worth flagging first and how the tool should present them. I'd rather say that plainly than overstate where things are.
What I'd love from this community is feedback from anyone who has handled sales disputes, whether in support, operations, or account management. Which promises cause the most trouble for your team?
Comments2
Welcome to Lounge, Muhammad. Flagging promises early seems to depend on where the promise lives, whether that's call transcripts, email threads or CRM notes, and on what the product actually does. Which source are you starting with, and what are you comparing the promises against?
From running an SEO service, the disputes we see almost never come from price. They come from three kinds of promises: timing ("you'll see results in two weeks"), outcomes the seller doesn't fully control (rankings, indexing, "guaranteed" anything), and vague quantities ("a bunch of links" vs exactly what was delivered). The fix on our side was boring: never promise positions, and give every customer a report with the live URL of each deliverable, so "did I get what I paid for" is answerable in one click. So I'd start by flagging outcome and timing language in sales emails and chats, and pairing each flagged promise with what proof will exist later to show it was kept. That second half is probably what makes ops teams actually adopt it.
2 comments
Welcome to Lounge, Muhammad. Flagging promises early seems to depend on where the promise lives, whether that's call transcripts, email threads or CRM notes, and on what the product actually does. Which source are you starting with, and what are you comparing the promises against?
From running an SEO service, the disputes we see almost never come from price. They come from three kinds of promises: timing ("you'll see results in two weeks"), outcomes the seller doesn't fully control (rankings, indexing, "guaranteed" anything), and vague quantities ("a bunch of links" vs exactly what was delivered). The fix on our side was boring: never promise positions, and give every customer a report with the live URL of each deliverable, so "did I get what I paid for" is answerable in one click. So I'd start by flagging outcome and timing language in sales emails and chats, and pairing each flagged promise with what proof will exist later to show it was kept. That second half is probably what makes ops teams actually adopt it.