What data should you put in a CRM first?
Start with open deals, not the contact list. What the first import should contain, the minimum a record needs to be useful, and why importing everything is a common way a rollout stalls.
Syncek Team · CRM reference library
/ 4 min read / Art. #73
Put in the deals you are working right now, the people attached to them, and the next step on each. That is the whole first import. Everything else, the old contacts, the closed business, the years of email, can wait or never arrive, and a rollout that starts with them usually does not finish.
Why start with the deals in play rather than the contact list?
The instinct is to import the contact list, because it exists and it is large. That is the wrong first move. A contact list with no deals attached gives you a searchable address book. Nobody opens a CRM daily to look at an address book. What gets a team into the tool every morning is the pipeline: what is open, what moved, what needs a call today.
So the first import is the 20 or 50 deals currently in play. The people come with them, because a deal without a person attached is not a deal.
What is the minimum a record needs?
For each open deal, five fields do almost all the work:
- Name, in a form somebody else could recognise a week later.
- Value, in one currency, and a real number rather than a placeholder.
- Stage, with a written exit test so it means the same thing to everyone.
- Expected close date, which somebody is willing to revisit.
- Next step, with a date. This is the field that makes the tool worth opening.
Anything beyond those five is optional at import. Add fields when a question you actually ask cannot be answered without one, not in advance because a field might be useful.
What should you not import?
Closed business older than a year. It looks like history and behaves like clutter. If you need it later, it is still in the spreadsheet.
Contacts with no relationship. A scraped list or an old export adds volume and no signal, and it makes every later count wrong. Anything you would not email this quarter can stay out.
Every column you have. A spreadsheet accumulates columns that made sense once. Importing them all creates fields nobody fills, and a CRM full of empty fields teaches the team the fields do not matter.
In what order should a first CRM import load?
Scope and sequence answer different questions, and running them together is how a first import goes wrong. What goes in is the open deals and the people on them, which is the whole argument above. What order the files load in is whatever the links need.
A link can only reach a record that already exists. Import a deal naming a company before that company is there and the link is dropped, usually in silence: the row is created, the field is left empty, and the import counts it as a success. So load the first import as three small files, in this order: the companies those deals belong to, then the people, then the deals themselves. Skip the first file if you sell to individuals rather than organisations.
It is the same sequence a full CRM migration uses, on a fraction of the rows. Then, only if you need it, historical closed deals for the win-rate maths.
Each step should end with the tool usable. If you cannot run your Monday pipeline review once those files are in, adding more data will not fix it.
What goes in, when, and why:
| What | Import it? | Why, or when |
|---|---|---|
| The companies those deals belong to | First | A link only reaches a record that already exists, so whatever is pointed at loads first. Skip it if you sell to individuals |
| The people on those deals | Second | A deal without a person attached is not a deal |
| The open deals themselves | Third | What gets a team into the tool every morning is the pipeline |
| Historical closed deals | Later, only if you need them | For the win-rate maths |
| Closed business older than a year | No | It looks like history, behaves like clutter, and is still in the spreadsheet |
| Contacts with no relationship | No | They add volume and no signal, and make every later count wrong |
| Every column you have | No | A CRM full of empty fields teaches the team the fields do not matter |
Why does importing everything stall a rollout?
A large import surfaces every inconsistency at once: duplicate people, three date formats, values in two currencies, a stage column with eleven distinct spellings. Cleaning that is a real project, and it happens before anyone has got any value from the tool.
Teams that stall almost always stalled here. They spent two weeks on a migration, went live with a database nobody trusted, and went back to the spreadsheet.
The small import inverts it. A week of use tells you which fields you actually need, and you clean the data you kept rather than all of it.
What does the file need to look like before you import it?
Whatever you import, the shape matters more than the size: one row per thing, one meaning per column, consistent dates, and a single currency. Those rules are the same for 30 rows as for 3,000, and on 30 they take a morning, which is another argument for starting small. Preparing the CSV properly is most of the import.
Frequently asked questions
What data should you put in a CRM first?
The deals you are working right now, the people attached to them, and the next step on each. That is the whole first import, usually 20 to 50 deals. Old contacts, closed business and years of email can wait or never arrive. The test is whether the tool is usable at the end of that first step, not how much of the spreadsheet made it across.
Why start with deals rather than the whole contact list?
Because a contact list with no deals attached is a searchable address book, and nobody opens a CRM every morning to look at an address book. What brings a team back daily is the pipeline: what is open, what moved, who needs a call today. The people arrive with the deals anyway, since a deal with nobody attached is not a deal. That is a question about scope, not about load order: within the first import the files still go in link order, companies then people then deals.
Which fields does an open deal need at import?
Five do almost all the work. A name somebody else would recognise a week later. A value, in one currency and a real number. A stage, with a written exit test so it means the same to everyone. An expected close date somebody is willing to revisit. And a next step with a date, which is the field that makes the tool worth opening at all.
Should you import old contacts and closed deals?
Mostly not. Closed business older than a year looks like history and behaves like clutter, and it is still in the spreadsheet if you need it. Contacts you would not email this quarter add volume, no signal, and they make every later count wrong. Historical closed deals are worth importing only once you need the win-rate maths, and after the tool is already in daily use.
Why do large CRM imports stall a rollout?
Because a big import surfaces every inconsistency at once: duplicate people, three date formats, values in two currencies, a stage column with eleven spellings. Cleaning that is a project in its own right, and it happens before anybody has got value from the tool. Two weeks of migration, a database nobody trusts, and the team goes back to the spreadsheet.
How do you know the first import was enough?
Run your Monday pipeline review on it. If the open deals, their stages and their next steps let you hold that meeting, the import did its job and everything after it is optional. If it does not, more data will not fix it, because the problem is the shape of what went in rather than the amount.
Does a small import mean less file preparation?
No, and that is an argument for starting small rather than against it. One row per thing, one meaning per column, consistent dates and a single currency are the same rules for 30 rows as for 3,000. Doing it on 30 gets you a usable tool in a morning, and a week of real use then tells you which fields the next import needs.