A customer database is one shared place where a firm keeps what it knows about each client: contact details, the people and contracts linked to them, and each email, meeting and document. You build one in five steps: list what you follow, map the links, clean the spreadsheet, move it in batches, then connect the inbound flows.
Customer database: build one from your client spreadsheet
Build a customer database from a client spreadsheet in five steps: what to store, how to map households and contracts, and how long UK GDPR lets you keep data.
The Standards team
In short
What is a customer database?
A customer database is the record your whole team shares of each client you serve: who they are, how to reach them, who they are linked to, what they hold with you and each exchange you had with them. For an advisory firm of five to fifty people, it replaces the client spreadsheet, the searches through a shared inbox and the folders on a drive, which each answer part of the question. A CRM is the software most firms use to run one, with the screens, tasks and reminders around the records. In an advisory firm the database has a shape that one spreadsheet row holds badly: a client is often a household of two people, with a family company, several contracts and the documents your regulator asks you to keep. That shape decides which columns of your spreadsheet survive the move, and which ones have to turn into links between records.
What should a customer database hold?
An advisory firm's customer database holds six families of information about each client. The table lists them with an example of what a firm records in each one, so you can check your current spreadsheet, inbox and drive against it before you move anything.
Family | What it holds | Example in an advisory firm |
|---|---|---|
Identity and contact | names, addresses, phone numbers, email addresses | both spouses' email addresses, so their messages reach the household |
Relationships | who is linked to whom, and in what role | spouse, director of the family company, beneficiary |
Holdings and contracts | what the client holds or has signed with you | a pension, a life policy, an advice mandate |
Documents | the supporting documents and their validity | proof of identity and proof of address, with an expiry date |
History | emails, meetings, calls and notes | the minutes of the last annual review |
Consent and retention | what the client agreed to, and how long you keep the data | marketing consent, the date the relationship ended |
Why one spreadsheet row per client stops working
A spreadsheet gives each client one row, and the clients of an advisory firm do not fit in one row. A couple with two policies and a family company makes three records plus the roles between them: one spouse holds the pension, the other is the insured person on the life policy, and both own shares in the company. A spreadsheet turns those roles into extra columns such as "Spouse 2 email", or into notes you cannot filter. We read five of the pages Google showed for "customer database" in the UK in October 2026: Gedys, Sparkle, Capsule and Indeed in the results, Ninox in the AI Overview. They describe fields and steps, and none records the role of each person in a contract as data. Map the links before you choose the columns: list your record types, then the role and the share each person holds in each contract. That map decides the shape of the database, and a move done column by column loses it first.
In the spreadsheet | In a customer database with linked records |
|---|---|
a "Spouse 2 email" column | a second person record, linked to the household as spouse |
a "Policy 2 beneficiary" column | a link from the contract to the person, carrying the role "beneficiary" and the share |
a company name typed in the notes | a company record, linked to each director and shareholder with their share |
a "Last contact" date typed by hand | the emails and meetings themselves, filed on the records of the people in them |
How to build a customer database in five steps
Building a customer database takes five steps, in this order: the model first, then the data, then the inbound flows. A firm that imports before it models has to restructure its records after the import, and its advisers end up checking the same clients twice.
A partner lists what the firm follows. Write down the real things your team works on, such as households, people, companies, contracts and documents, and leave the columns of the current sheet aside for now.
The same partner maps the links. For each kind of contract, note who holds it, who is insured, who benefits and with what share; that map becomes the relationships of your database.
An administrator cleans the spreadsheet. Merge the duplicate rows, split each "Name 1 / Name 2" cell into separate people, set one format for dates and phone numbers, and keep the original file untouched.
The team moves the data in batches. Start with the active clients, have each adviser check a few records they know well, and move the dormant files once the first batches hold.
The team connects the inbound flows. Connect the mailbox and the meeting tool so that new emails and minutes land on the right record, or the scattering starts again.
Worked example: a twelve-person advisory firm
This example is fictional: a twelve-person financial advice firm keeps one spreadsheet row per household, with columns such as "Client 1", "Client 2", "Policy 1" and "Policy 2", and a notes column that holds everything else. Its partner settles on four record types. A household groups the people who come to the same review meeting. A person carries a name, a date of birth and the email addresses that incoming messages will match. A company carries its registration number and a link to each director and shareholder, with their share. A contract carries its provider and its type, and links to its holder, its insured person and its beneficiaries. The notes column has no structure the firm can map. The partner keeps it as a text field on the household and asks each adviser to sort it at the next review, instead of guessing its content during the import.
How long can a firm keep former clients' data?
Under UK GDPR, a firm must not keep a former client's personal data for longer than it needs it, and it must be able to justify that period. The ICO's guidance on storage limitation, read in October 2026, opens with this rule: "You must not keep personal data for longer than you need it". It adds that you "should also periodically review the data you hold, and erase or anonymise it when you no longer need it". A customer database makes that review possible, because one retention rule applies to one database instead of a copy of the spreadsheet on each laptop. Record the date each client relationship ends, and the reason you keep the file after it, such as a record-keeping duty your regulator sets. Then review the ended relationships on a fixed date each year. The ICO says this guidance is under review after the Data (Use and Access) Act, so read the current page before you write your policy.
Where should a firm host its customer database?
A customer database can run on a vendor's shared cloud, on an instance dedicated to your firm or on your own servers, and the choice decides who holds your clients' personal data and where. A shared cloud leaves the servers to the vendor, so ask where its data centres are and which subcontractors process your data. A dedicated instance keeps your data apart from other customers' data while the vendor still runs it for you. Your own infrastructure gives your firm control of the data, and it also hands your team the updates, the backups and the security work. Standards runs in each of these setups, with its shared cloud hosted in Europe. The connectors differ by setup: Gmail is the mailbox Standards connects on its cloud, while Outlook runs on a dedicated instance or on your own infrastructure. Check the mailbox your firm uses before you pick the setup.
Building your customer database in Standards
Standards is a workspace where a firm builds its own customer database: its own record types, such as households, contracts and assets, and qualified links that carry the role, the share and the ownership. In Architect mode, the assistant designs the objects, fields and views with you, in a draft you publish. You can then attach your cleaned spreadsheet to the assistant, and an agent reads it and creates the records in batches. In Auto mode the agent changes your data without asking; in Manual mode it asks for your approval before each change, and a deletion or an outgoing send asks in both modes. Each record keeps its history: who changed what, colleague or agent, with the previous value. Standards files each Gmail thread on the records whose email addresses match, and a bot records Zoom, Meet or Teams calls, then files the transcript and minutes on the participants' records.
Standards has no import wizard and no automatic duplicate detection, so the cleaning of step 3 stays with your team, and the agent works from the file you give it. Each record also gets its own drive, and supporting documents can carry the type, status and expiry date your firm sets up for them. Standards' engineers set the workspace up with you, and Standards is priced per person per month with the setup included; you get the price at the first call. You can export any filtered view to CSV, up to 100,000 records. To weigh it against the tools you already know, read how Standards compares with other CRMs, or browse the industry pages.
Questions
Before you switch tools.
Bring your client spreadsheet to a first call.
Standards' engineers set Standards up with you, on your own record types.