Your Data, Your Interface: Using AI to build a personal SaaS.
- 23 hours ago
- 7 min read
For the last twenty years, SaaS companies have been building the best user interface they can into your data. HubSpot, Salesforce, Dynamics, whatever you use, they give you a front end, and it is pretty much standardised for everybody. It has to be. They are building one interface for millions of users, so it is as good as they can make it for the general case. Your CRM holds your data, but the way you see it and interact with it is the same way everybody else does.
What has changed is that you can now use that CRM as a back-end database and build your own interface on top of it, one that maps to your actual processes, works with and for your people, and surfaces the data you need and care about.
That is what we did at ChangeSchool, and it has fundamentally changed how our sales team works.
We manage enterprise relationships across Armenia, Georgia, Kazakhstan, and the UK, selling executive education programmes and Executive MBAs. HubSpot holds all of it: deals, contacts, company records, notes. But the interface HubSpot gives us is the same one it gives a SaaS startup in San Francisco or a recruitment firm in Manchester. It does not know that our sales cycle in the Caucasus is relationship-first and runs on different rhythms to the UK. It does not know which of our active deals genuinely need attention this week and which are ticking along fine.
So we built a system that does know those things. It reads emails, transcripts, and sales notes, qualifies every deal against two frameworks, produces a ranked dashboard with specific next actions for each sales executive, and drafts follow-up emails in the executive's own voice, pushed straight to Gmail as drafts ready for review.
The qualification is where the first piece of value sits. Every deal is scored on two levels. The first, FAINT, asks the foundational questions: does this prospect have funds, authority, genuine interest, a real need, and a timeline? The second, MEDDPICC, goes deeper into deal mechanics: how will they measure success, who writes the cheque, what is the decision process, who inside their organisation is championing this, and who else are they talking to? Each dimension is scored, backed by direct evidence from meeting transcripts, not guesswork [1]. This not only takes pressure off the precious time of the sales executive, it also gives them an outside view, balances their natural biases, and helps them think more clearly about what’s happening with that account.
Those scores feed into a Focus Score from 0 to 100, weighted by region. In Armenia, where internal champions carry enormous weight in hierarchical organisations, that dimension is weighted more heavily. In the UK, timing and decision process matter more. A sales manager can look at the pipeline and see immediately: we have this number of deals where the prospect knows what they are measuring, but only this number where both the champion and the economic buyer are actively engaged. That is where to focus this week.
The email drafting is the part the team notices most. The system reads the executive’s prior correspondence and matches their style: formal or warm, bullet points or flowing prose, using cultural norms. It writes in British English and knows not to use American sales idioms with a Yerevan procurement committee. But the real value is not any single feature; it is the shift in where the executive spends their time. Instead of hours reviewing transcripts, checking deal histories, and composing emails from scratch, they have a dashboard with contextualised priorities, suggested next actions, and draft emails ready for each account. The executive decides everything: who to contact, what to say, when to send. The preparation happens in the background. The result is that each person can manage more accounts, respond more quickly, and spend their time on the work that actually wins business: talking to clients and being in the room.
The honest bit
Now, here’s one of the honest bits. Getting AI not to write in an American, over-explicit, hard sale tone is quite the challenge. The US is a unique culture. Most of the world is varying degrees of mono-ethnic and mono-cultural. That’s a massive generalisation, but compared to the USA it’s true. What the US has therefore had to do to get everybody working together is become very, very explicit in its language and very clear because people from different cultures don’t share the same assumptions.
Most cultures have a very implicit way of communicating. You say something and people pick up not just the words you say but how you say them, the context you say them in; everything is contextual and understanding is much more subtle. That means the words you use, the language structures you use, and the meaning underlying them is different to the American form of expression. Yet AI has mainly been trained on corporate speak and writes as such. We had to put a lot of effort into this. Not just prompting on purpose, audience, and culture, but showing examples and correcting. It took some time.
Data protection and security
Data protection is a serious consideration when client data passes through an AI model. Our approach is clear: the human is the decision-maker for anything involving personal data, as per GDPR. Email addresses are hashed and anonymised before processing, and the data is processed in the EU (yes you can, through cloud partners like AWS Bedrock Frankfurt, Google Vertex AI Frankfurt, or Azure Sweden Central). The system analyses emails, transcripts, and CRM records to produce deal scores, suggested actions, and email drafts, but nothing is sent or shared without the executive reviewing it first. Email drafts appear in Gmail as drafts, never sent automatically; the system does not have permission to send emails, and that permission is held outside of its API scope. Staging data sits on a permissions-controlled server on our premises. The AI provider’s commercial terms require that inputs are deleted within seven days and are not used for model training. Prospect data lives in the CRM. The AI generates insights from it, but does not retain it [2].
On security, the system defaults to dry-run mode for any operation that writes to the CRM, so nothing changes in your data until you explicitly allow it. API credentials are stored outside the codebase, and a daily spend cap prevents runaway costs. The question that technical readers will ask is about prompt injection: what happens if unstructured text in a transcript or a CRM note misleads the AI into producing wrong outputs? The risk is real in any system that processes free text, and the defence is layered. Outputs are validated against the structured data already in the CRM, anomalous results are flagged, and the human reviews every recommendation before acting on it. No output goes anywhere without a person in the loop.
None of this replaced HubSpot. HubSpot is still the system of record. What changed is how the team interacts with that data. Instead of clicking through individual deal records and trying to remember what happened in a meeting three weeks ago, they open a dashboard that has already done the analysis and is ready for their decisions.
The five-step discipline from the first post in this series applies directly. The business need was clear: we were losing track of deal health across four markets and three time zones. The outcome we defined was a weekly dashboard with ranked priorities and executable actions. We reviewed the plan, built it iteratively, and continue to review the outcomes every week. When something does not work, we change it.
If you have a CRM with data in it, you already have the back end. The question is whether the interface you are using is really working for your people, or whether it is just the best that a company selling to millions of customers could give you.
Sources
[1] FAINT (Funds, Authority, Interest, Need, Timing): developed by Mike Schultz at RAIN Group as an evolution of IBM’s BANT framework. MEDDPICC (Metrics, Economic Buyer, Decision Criteria, Decision Process, Paper Process, Implicate the Pain, Champion, Competition): originated at Parametric Technology Corporation (PTC) in the 1990s, credited to Dick Dunkel, Jack Napoli, and John McMahon.
[2] Anthropic commercial API terms: inputs deleted within 7 days, not used for model training.
About The Series
This article is part of a series on practical AI applications at ChangeSchool. For the strategic view of leading AI in organisations, see Viren Lall’s companion series.
Article 1 : Getting Real with AI
ChangeSchool is an SME without a dedicated coding resource. Every application described in this series was built using AI coding tools. They are all vibe coding projects, and all within the reach of a startup or a micro business willing to spend some hours and have a go. If you’ve got any questions about what this was or how we did it, or any suggestions for better ways forward, please pop them in the comments below and I’ll do my best to answer them.
Technical: Our process is the same for every project. Once the business need and objective are defined, we research the approach using Google Gemini Deep Research and Perplexity Deep Research, then give that research to Claude Code to build it. None of the technical terms below were things we knew beforehand; they came out of that research process. It takes minutes to get up to speed. This project was built in Python using Claude Code. The system uses the HubSpot API (developers.hubspot.com) for CRM data, the Gmail API (developers.google.com/workspace/gmail/api) for email draft creation, and the Anthropic Claude API for qualification analysis and email drafting. No open-source models are required; the intelligence is provided by the Claude API.
Follow the AI for Boards Series here :-
Article 1: The 70⁄14 Paradox (structures vs readiness)
