Build apps · Your App Cloud
Create a useful customer database
Bring customers from your shop export, newsletter list and sign-up sheets into one record each. Decide when two records are the same person, where each came from, and who may change it.
Built around a purpose
One record per customer, with its source and consent.
For businesses whose customers are spread across a shop export, a mailing list and a spreadsheet or two, and who get a different customer count from each. That might be a shop selling online and at markets, a studio with a booking tool and a newsletter, or a nonprofit with donors in two systems.
For illustration: a coffee roaster in Oakland, California sells through its web shop, at two weekend farmers' markets and to about 30 cafés. Its customers sit in four places: the shop's order export, a newsletter sign-up list, market sign-up sheets typed into a spreadsheet, and wholesale accounts in the bookkeeping tool. Many people appear in more than one, spelled differently.
A customer table where each person and each café appears once, carrying every source it was merged from and a dated consent field. Beside it: named segments that the newsletter, the wholesale list and the market staff share, a queue of likely duplicates waiting for a decision, and a log of correction and removal requests.
Records that staff add and change, sign-in for each person who uses it and any email the app sends are backend capabilities, so this database is an app with data. If you add an agent, model and service usage is metered separately. Build and preview it on any plan. Putting it live needs Go or Pro. See pricing
List every place a customer is recorded
Write down each source, what it holds and who updates it. Note what identifies a person in each one: an email in the shop export and the newsletter list; a name, a phone number and sometimes an email on the market sheets; a business name in the bookkeeping tool. Those columns become your match keys.
Write a field dictionary before any import
Give every field one line: its name, whether it is required, and its format. Here an email or a phone number is required, a ZIP code is optional, and wholesale accounts also need a business name and a buyer's contact. Store phone numbers one way, with the area code, so matching works.
Import one source at a time against a match rule
State when two records describe one customer: the same email for a person, or the same business name and ZIP code for a café. Start with the largest source, then add the others one by one. Describe a review list of likely pairs in Studio instead of automatic merging, and decide each pair yourself.
Keep source and consent as their own fields
Give each record its source and the date it arrived. Write down what counts as agreement to email for your business, such as a ticked box on the market sheet, and record how and when each customer agreed. Decide that a merged record keeps both sources and that an unsubscribe in either one wins.
Define segments in words, then as filters
Write each segment as a sentence first, such as wholesale cafés in Alameda County, or web buyers with no order in 12 months. Then save it as a named filter with that sentence beside it, so the newsletter, the wholesale price list and the market staff all start from the same definitions.
Decide who changes records and how removals work
Market staff might add sign-ups and fix typos, while only the owner merges or deletes. Add a request record for customers who ask to be corrected or removed, holding who asked, what they asked for, the date and what was done.
Scope the first version
What a first version includes.
Customer table
One record per person or business, with the required fields from your dictionary, a type such as individual or wholesale, and the date the record was created. Purchases stay in their own records, linked to the customer.
Likely-duplicates list
Pairs that meet your match rule or come close, such as one phone number under two emails. Each pair waits until a person merges it or marks the two as different people.
Source and consent
The source of each record with its date, and an email consent field saying how and when the customer agreed. A merged record lists every source it came from.
Named segments
Saved filters, each with a one-line definition beside it, such as lapsed web buyers: last web order more than 12 months ago. Anyone who opens a segment reads the same rule.
Edit rights
Who may add, change, merge and delete records, through the access you describe for each collection. The staff who use the database sign in to the published app.
Change and request log
Who changed a field, from what, and when, plus each request to correct or remove a record with its date and outcome. When a merge goes wrong, this is where you trace it.
Test it in the preview
Before you share it.
- Import a duplicate on purpose: the same customer as Emma Clarke with emma.clarke@example.com on a market sheet, and as Emma.Clarke@Example.com with a differently written phone number in the shop export. The pair should land in the likely-duplicates list, not as two customers.
- Try to save a customer with neither an email nor a phone number. The form should refuse it and name the missing field.
- Merge a pair where one source says yes to email and the other holds an unsubscribe. The merged record should follow your written rule and stay out of the newsletter segment.
- Open five records in the lapsed web buyers segment and check each against the sentence beside it. Then search for a customer who ordered online last month and confirm the segment leaves them out.
- Sign in with a market staff account and try to merge or delete a record. Both should be refused. Sign in as the owner and confirm both work.
- Run a test removal request for a sample customer. The record should go as your rule says, the log should keep the request and its date, and the customer should drop out of every segment. Then export your app's data and confirm the record is gone from the export too.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Database
Keep data and context for apps and agents
Authentication
Give the right people access
Email
Keep conversations moving
Shape the details
Make it work for your world.
- Keep a customer apart from what they bought. When every order row repeats a name and address, one change of address leaves several versions of the same customer behind. Link orders to the customer record instead.
- Restoring an earlier version of the app in Studio changes the app, not the records inside it. A wrong merge has to be fixed from the change log or by hand, which is why merges wait for a person.
- Each import is a snapshot of that tool on the day you exported it. Once the database is live, add new customers in the app and bring later market sheets in as a deliberate import matched on your rule. Otherwise the old spreadsheets grow again beside it.
- Collect only the fields you will use. A birthday or a household size is one more thing to keep correct, and one more thing to find and remove when a customer asks.
A little more context
Good questions.
How is this different from client management?
This guide covers the records themselves: one per customer, where each came from, what they agreed to, and who may change them. Client management builds the ongoing work on top, such as engagements, next actions and documents for each client. You can set up the database first and add that layer later with the guide below.
Can I bring in customers from the tools I use now?
Yes, as files. Export the customer list from each tool, bring the largest one into Studio first, and review the likely-duplicates list after each further import. The Excel and CSV pages below cover preparing each file.
How do I handle a request to delete or correct someone's details?
Log it first: who asked, what they asked for and the date. Correct or remove the record under your written rule, then check the segments and any list you exported from the database earlier, such as a newsletter file. What the law requires depends on where you and your customers are, so confirm the rules that apply to you.
Can an agent help keep the records clean?
You can add an agent inside the app that lists likely duplicates or records missing a required field, when asked or on a schedule you set. Treat its list as suggestions. A person compares each pair and decides before anything is merged. Model and service usage is metered separately.
Explore Pricing for plans, included capabilities, and usage details.
Start from what you have
Bring the file you already use.
Keep exploring.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building