Build it with AI
Build a CRM around the way your team actually sells.
Create a focused CRM from a plain-language description instead of forcing your process into a generic template.
Introduction
What a CRM has to hold.
Most teams end up with a CRM the same way: a CRM configured for somebody else's sales process, with the parts that do not fit kept in a spreadsheet beside it. It survives the first two reps and stops surviving the third, because the shared understanding that made the missing fields harmless was never written down anywhere the new person can read.
The fields the team actually reasons about are custom, half-populated, and reported on by exporting to a sheet every Friday. There is no definition of what a stage means, no rule stopping a deal moving to Proposal with no contact attached, and no owner on the record that outlives the person who created it.
What follows covers building a CRM: the records it holds (accounts, contacts, opportunities, stage history, and the next action against each one), the systems it reads (HubSpot and Salesforce), and what it does not fix.
The problem
A CRM that models somebody else’s sales motion.
Every general CRM ships with a stage model built from a composite of thousands of other companies, which is why the first configuration meeting is spent deciding which of your stages to merge. The custom fields added afterwards are the part of your process the vendor did not model, and they are the fields nobody reports on.
The records are accounts, contacts, opportunities, stage history, and the next action against each one, and the authoritative copy of most of them already lives in HubSpot or Salesforce. The sales team ends up trusting the spreadsheet and the leadership team ends up trusting the CRM, and the fortnightly argument about which is right is the reconciliation cost showing up as a meeting.
The cost is not the inconvenience: a forecast is presented from records that describe what was logged rather than what happened.
You're likely here because
- Two people can quote different pipeline totals for the same week and both are reading a real system
- The fields the team actually reasons about are custom, half-populated, and reported on by exporting to a sheet every Friday.
- When it is wrong, a forecast is presented from records that describe what was logged rather than what happened
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Custom CRM views
- • Deal stages and records
- • Role-specific dashboards
Operated through Grow
- • Lead capture
- • Follow-up workflows
- • Pipeline execution
Systems it reads
- • HubSpot
- • Salesforce
- • Gmail
The record model
What a CRM record has to carry.
- Account
- The company, with the legal entity kept distinct from the operating unit you sell into. Merging the two is what makes a group of subsidiaries look like one relationship, or three.
- Contact and role
- The person plus what they do in the decision — champion, economic buyer, blocker. A contact list without roles cannot tell you whether a deal has met anyone who can sign.
- Opportunity
- One sellable thing with an amount, a close date, and a stage. Multiple products to one account are multiple opportunities, not one with a bigger number.
- Stage and entry evidence
- The stage plus what was true when it was entered. Recording the evidence is what makes a stage transition auditable instead of a claim.
- Next action and its date
- What happens next and when. This single field does more for pipeline hygiene than every other reporting field combined, and it is the one most often left free-text.
- Owner
- Who is accountable now, versioned rather than overwritten, so a deal that changed hands mid-cycle can still be attributed correctly at commission time.
- Activity
- Contact observed from email and calendar rather than logged by hand. The moment it requires typing, it is complete for three weeks and misleading afterwards.
How it runs
From your stages to a system that holds them.
Step 01
Describe what a CRM has to do
Start from the stage model your team already argues about — what has to be true before a deal moves, who decides, and what happens to the ones that go backwards. That definition is the CRM; the fields follow from it.
Step 02
Connect the systems of record
Email and calendar supply activity, and the existing CRM or billing system supplies the account of record. Reading them means a rep never types an activity that the system could have observed.
Step 03
Build the operating surface
Stages, required fields per stage, role-scoped pipeline views, and the transitions that are simply not permitted — generated as a working application rather than configured through a settings panel.
Step 04
Start narrow
One pipeline view showing open opportunities with no dated next action, and the owner against each. That single view is usually enough to change behaviour in the first week.
Step 05
Route the exceptions
Deals that go stale past a threshold you set surface to the named owner with the last activity attached, instead of being discovered at the quarterly review.
Step 06
Measure the share of open opportunities carrying a specific, dated next action
Take the share of open opportunities carrying a specific dated next action before you switch, and compare it after a full sales cycle. It is the one CRM metric that cannot be gamed by logging activity.
Implementation path
Getting a CRM live without a six-month admin project.
- 01
Write down what actually has to be true for a deal to move between each pair of stages. Most teams find at this point that two stages mean the same thing and one stage means three different things depending on who is talking.
- 02
Take the baseline before touching anything: what share of open opportunities has a dated next action, and how many hours a week go into pipeline hygiene.
- 03
Decide which system owns the company record. If billing already owns account status, the CRM should read it rather than carry a second status field that drifts.
- 04
Run the new pipeline view alongside the existing CRM for one full sales cycle. Cut over only when the forecast produced from each agrees.
- 05
Build the narrowest useful version first: one pipeline view showing open opportunities with no activity in the last fortnight, and the owner against each.
- 06
One person who knows how the team actually sells, plus whoever owns the current CRM, for the stage definitions — that conversation is usually a day and it is the whole project. Connecting email, calendar, and the existing CRM read-first is straightforward. Expect the first pipeline view within a week and a full sales cycle of parallel running before anyone should trust the forecast that comes out of it.
- 07
Once the next-action view is genuinely used, add forecast categories separate from stages — a deal can be late-stage and uncommitted, and every experienced sales leader makes that distinction informally. After that, territory and quota, but only if a reorganisation has actually cost you something measurable.
Controls
Controls that matter.
Control 01
Rep-level visibility scoped so that territory or team boundaries are enforced by the system rather than by convention
Control 02
Stage transitions that require the evidence the stage definition names, so the pipeline cannot be advanced to make a number
Control 03
Contact and account records exportable in full at any time, because a CRM you cannot leave is a CRM you cannot evaluate
Examples
Three things that stop being manual.
The deal that moved because the quarter was ending
A stage with an enforced entry condition cannot be entered without the condition being met, which converts an optimistic forecast into a visible argument about whether the condition is right. That argument is the useful part.
The rep who left
Ownership, activity history, and next actions live on the record rather than in a personal inbox, so the handover is a reassignment rather than an archaeology project across somebody’s sent folder.
The fortnightly pipeline scrub
Deals with no dated next action surface continuously rather than being discovered in a meeting, which turns the scrub from a review of everything into a review of the exceptions.
How it goes wrong
Three ways a CRM build goes wrong.
Every field the old CRM had gets rebuilt, because nobody wanted to be the person who dropped one.
Rebuild the fields that appear in a report or a stage condition, and archive the rest into a read-only view of the old system. Fields exist to be reasoned about; a field nobody has queried in a year is documentation of a decision somebody made in 2019.
Stages are enforced and reported pipeline drops by a third in the first month, which is read as the system being broken.
Say it will happen before it happens, and show the previous number alongside. The drop is the enforcement working — the pipeline was always this size and the reporting was generous.
Reps keep working from their inbox and the CRM is updated on Thursday afternoon for the Friday call.
That is not a discipline problem, it is a design one. Observe activity from email and calendar so the system fills itself, and reserve manual entry for the judgement fields that genuinely need a human.
Limitations and considerations
What a CRM cannot decide for you.
- A CRM cannot tell you whether your stage model is right. It can only tell you, quickly and uncomfortably, that deals are piling up at one of them.
- Activity capture from email is only as complete as the mailboxes connected. Deals worked from a personal phone or a channel you have not connected stay invisible, and the system will look confident about an incomplete picture.
- If commission is calculated from CRM data, changing the stage model changes what people are paid on. Sequence that conversation before the migration, not after.
- If you have fewer than about two hundred open opportunities and one person can name the state of all of them, a CRM build is premature and a shared pipeline view will do. Equally, if the current CRM fits and the complaint is that nobody updates it, the problem is activity capture rather than the object model, and rebuilding will reproduce it faithfully.
- Connector coverage varies: HubSpot, Salesforce, Gmail are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a CRM with AI: common questions.
How is this different from configuring HubSpot or Salesforce?
Configuration starts from the vendor’s object model and negotiates your process toward it. Building starts from your stage definitions and generates the objects that hold them. The practical difference shows up in the fields nobody reports on — in a configured CRM they are the custom ones, and in a built one they are the reason the system exists.
Do we have to migrate our existing CRM data?
Not to start. The narrow first version can read the existing CRM through a connector and add only the stage discipline that is missing. Migration becomes a decision you make once the new model has proven itself over a full cycle, rather than a prerequisite you commit to before knowing.
What happens to reporting our board already expects?
Rebuild the two or three numbers the board actually asks about first and reconcile them against the current source before anything else. If they do not agree, the disagreement is information — usually about a stage definition that meant different things in different reports.
Can reps still work out of their inbox?
Yes, and most will. Reading email and calendar means activity is captured from where the work happens rather than requiring it to be re-entered, which is the single largest reason CRM data goes stale.
What should the first version contain?
One pipeline view showing open opportunities with no activity in the last fortnight, and the owner against each. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure the share of open opportunities carrying a specific, dated next action against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a CRM around the process you actually run.
Start from the stages your team already argues about rather than from a template that models a different company.