Sales
A CRM salespeople actually log into
The company already had a subscription CRM. The problem was not a missing tool, it was that nobody filled it in — because it gave nothing back to the person entering the data.
A B2B sales team with a long sales cycle
Where we started
The part missing from most case studies, and the only one that tells you whether it resembles your own situation.
The subscription had been paid for two years. In practice, the real pipeline lived in each salesperson's head and in a file of their own, and the CRM was filled in before the Monday meeting, retroactively, just enough to look right. The reports coming out of it described a company that did not exist.
The reason was not laziness. The system asked for fields the salesperson did not have at that moment, had stages that did not resemble how that company sold, and the quote was produced in another program anyway. Entering the data was extra work that gave nothing back to the person doing it.
What was breaking, concretely
- The stages in the system did not resemble the company's real sales stages.
- The quote was built in a separate file and lost its link to the customer.
- The history of a relationship was scattered between email, phone and memory.
- The reports were formally complete and practically useless for decisions.
Goals
What the application had to solve
The stages should be the real ones, with the names used inside the company.
The quote should be generated from the customer record, so entering data brings an immediate gain.
The whole history of a relationship should sit in one place, documents included.
The reports should show the reasons for losing deals, not only the number of opportunities.
What we built
The application, module by module
Not a feature list, but what each piece does and why it was needed.
-
01
A pipeline on the company's stages
The stages carry the names used inside the company and follow the company's rules: what has to be filled in for an opportunity to move on, and what happens automatically at each transition. We did not adapt the company to a model, we built the model out of the way it already sold.
What it covers
- Stages named and ordered as in the real process
- Transition conditions, defined per stage
- A column view, filterable by person and by period
-
02
The customer record and quote generation
The record gathers everything: conversations, quotes sent, orders, documents, contacts. From it, the quote and the contract are generated on the company's templates, with the details filled in. This is where the balance shifted: the salesperson fills in the record because otherwise the quote does not come out, and the quote is what they need anyway.
What it covers
- The full history of the relationship, with documents attached
- Quote and contract generated from a template, with data from the record
- Quote versions, showing what changed between them
-
03
Permissions and reports
Each role sees what it needs: the salesperson their own portfolio, the manager the whole team, the quoting team only the requests in progress. The reports also track the reason for losing a deal, chosen from a short list that is mandatory when closing a lost opportunity.
What it covers
- Role-based permissions, down to field level
- Reporting by source, by person and by reason for losing
- A management view, by quarter and by team
Decisions
What we chose and why
The choices that changed the project: where we took the simpler option, where we insisted on the more expensive one, and what would have happened otherwise.
Quote generation went into the first version, not the second
In the original plan, quote generation was a later module. We moved it into version one after the analysis, for a reason that had nothing to do with technology: without it, the application would again have been a place where data is entered with no immediate gain — precisely why the previous system had failed. It was the only feature that changed the ratio between effort and benefit for the user.
The reason for losing, mandatory and from a short list
A free text field would have filled up with "did not reply" and produced no information. A long list would have been ignored. We settled on six reasons, agreed with the team, plus an optional detail field. After the first few months, the distribution across those six was the first time management saw why deals were actually being lost.
We migrated the customer base, not the whole history
From the old system we brought across customers, contacts and open opportunities. The history of closed activities, largely filled in retroactively, we left there with read access for a period. There was no point carrying into the new system data everyone knew did not describe reality.
How the work looks now
No percentages and no hours saved — only what you can see by opening the application.
The pipeline in the application is the real one, because people keep it current in order to produce their quotes. The reports started being used in decisions rather than merely presented.
- The quote comes out of the customer record, on the company template.
- The history of a relationship is in one place, documents sent included.
- The reason for losing is recorded systematically, not described from memory.
- Each role sees what it needs, without asking someone else for a report.
What we learned
Including what we got wrong
A CRM does not fail for lack of features, it fails on the ratio between what it demands and what it gives back to the person filling it in. The first question about any internal system should be: what does the person entering the data gain today?
Not everything that can be migrated is worth migrating. Data everyone knows was filled in for form's sake does not become correct by being moved to another system.
Interactive demo
Open the application, not only its story
Six working screens, with navigation and search, available in English and Romanian. The names, companies and figures are demonstrative.
Frequently asked questions
What people ask us about this project
If your question is not here, write to us — we answer just as directly.
Ask us a questionWhy build a CRM when there are so many subscriptions available?
Most of the time you should not. A subscription product is the right choice for most companies, and we say so plainly if that is your case. Custom development is justified when your process genuinely differs, when quotes are generated by rules of your own, or when the data is not allowed to leave the company.
Can the data be moved from our current CRM?
Yes, if the current system allows an export. Our recommendation is not to move everything: customers, contacts and open opportunities, yes. History filled in for form's sake, no — it becomes noise in the new system.
How long before it is actually used?
Here, nine weeks to the complete move. Adoption did not come from training, it came from the fact that quotes are generated in the application — from the second week nobody had a reason to work anywhere else.
What we used from what we do
The project above happened once. These pages say what we deliver in general, who it suits and how long it takes.
Other projects
See all case studies →Leave taken out of the spreadsheet and out of the inbox
The record of leave lived in a file kept by one person, and approvals travelled by email. It worked, until two managers approved the same day in parallel.
Read →A payment notice the owner understands unaided
The manager spent more time explaining the calculation than doing it. The application did not shorten the calculation — it removed the need for the explanation.
Read →The receipt photographed on the spot, the claim closed without the pile
Receipts collected in a wallet and reached accounting once a month, creased and without context. Half the time spent on claims went into reconstructing who spent what, where and why.
Read →Do you recognise anything in the situation above?
Tell us how you work today and where it gets stuck. The first conversation is about you, not about what we did for someone else.