Onboarding customer data with AI

How the bot works

Eight steps. The profiling and the validation are ordinary code and cost almost nothing to run; the model is only asked the questions that actually need judgment.

1. It takes the file as it arrives. A spreadsheet with five tabs, a CSV, a JSON export, a database dump, a zip of all four. No “please reformat and resend” — that request is the reason onboarding stalls.

2. It profiles every column. Type, format, null rate, how many distinct values, the range, a sample of real rows, and whether the contents look like personal data. Profiling happens before a single mapping is proposed, because the column name is the least reliable thing about a column.

3. It proposes the mapping. Each source column to a target field, with a confidence value and the reason it matched — content, name, format, or a mapping you approved for a previous customer. A low confidence is reported as a question, never resolved by guessing.

4. It writes the transformation, not just the mapping. One address field into five. Three date formats resolved per column from the distribution, not row by row. Phone numbers to one format. Their codes translated to yours. Each rule is readable, editable and versioned — it is a rule you can audit, not a model asked the same question twice.

5. It validates before anything loads. Required fields, formats, referential integrity, your own business rules, and duplicate detection across the whole file — so two spellings of the same account are caught before they become two accounts.

6. It separates what will not load from what loaded with a question. Two piles, always, and never a silent third one. A row that cannot be loaded comes back with the exact ask — which row, which field, what is missing. A row that loaded but looks odd is loaded and flagged. A silent partial load is the failure mode this design exists to prevent.

7. A person signs off the mapping. The mapping, the transformation rules and a dry run over the whole file go to a human as one reviewable document. They approve it, edit a rule, or send a specific question back to the customer. Nothing is written to your live system before that.

8. It writes the load record. One row per row: the source file and cell range, the target record, the mapping version, which rules touched it, what changed, the outcome, the reviewer and the timestamp. The load is re-runnable and reversible because the record is complete.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your target schema

The fields, their types, what is required, and the code lists a value has to land in. This is the document the whole thing is measured against, and it is yours.

Your validation rules

Formats, referential integrity, ranges, and the business rules that only make sense in your company — a credit limit needs payment terms set, a site needs a parent account.

Your code lists

Payment terms, statuses, regions, categories. What their values translate to, and what happens to a value that is not on your list.

Your duplicate policy

What counts as the same account or the same contact, how close is close enough, and whether a probable duplicate is merged, flagged or held.

Your PII handling

Which fields are sensitive, which are never loaded at all, what is masked, how long the source file is kept and who can open it.

Your thresholds

What blocks a whole load, what blocks one row, and what loads with a question attached.

Your channels

Where the sign-off request lands: email, Slack, Microsoft Teams, or a ticket in whatever your implementation team already works out of.

Your systems

Which system is the target, and whether we write it through an API, into a staging table you control, or as a file for your own loader.

The words it uses

The tone and length of the question that goes back to the customer, and the versioned prompts behind it — yours to read, yours to tune.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every proposed mapping carries a confidence value and the reason it matched, and every transformation is a readable rule rather than a model asked twice. You can see why the bot thinks cli_addr is your shipping address before you agree with it.

Versioned prompts you can tune yourself

The prompts behind the judgment calls are yours to read and yours to tune. A change is a reviewable diff, replayed against the same customer file so you can see exactly what it would have done differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Automation handles the columns that map cleanly. The mapping as a whole is signed off by a person before anything reaches your live system, and an ambiguous field is a question rather than a guess. That boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per row: source, mapping version, rules applied, what changed, the outcome, the reviewer and the timestamp — plus token usage and cost for that run.

It can be configured to run in any business. The schema and the rules are yours: your target fields, your validation rules, your code lists, your systems. The customer-onboarding wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the stack you already pay for. We're not replacing your database.

• Salesforce
• HubSpot
• Microsoft Dynamics 365
• NetSuite
• QuickBooks Online
• Xero
• PostgreSQL, MySQL or SQL Server
• Snowflake or BigQuery
• CSV, Excel, JSON or a database dump
• SFTP, S3 or a shared drive
• Email, Slack or Microsoft Teams

Works well for

• Accounting and bookkeeping firms — A new client arrives as a ledger export from whatever they ran before, and it has to land in your chart of accounts.
• Wealth management firms — A book of business transfers as a custodian file, and every account and holding has to map before it goes live.
• Managed service providers — Every new client hands over an asset and user list in its own shape, and it has to fit your PSA's fields.
• SaaS platforms — Customers arrive with their own history, and the import is the part of onboarding that stalls.
• Insurance agencies — An agency you acquire shows up as a policy export, and the fields rarely line up with your management system.

How a rollout works

Nothing goes live on day one. A dry run over a real customer file comes first, and it is where your own numbers come from.

1. 01Discovery

   The quote call, then a working session. We read your target schema, two or three real customer files you have already onboarded by hand, the mapping decisions your team made on them, and what access your systems allow. You get the rule design, the exception classes and a written scope.

2. 02Dry run

   The bot runs over files you have already loaded by hand. Nothing is written anywhere. It produces a mapping and a per-row outcome, and we compare it, row by row, against what your team actually did. Every disagreement is either a rule to fix or a miss worth knowing about — and this is where your own accuracy numbers come from, on your own customers' files.

3. 03Assisted mode

   Live onboardings. The bot profiles, maps, transforms and dry-runs; a person reviews and approves every mapping before the load. The work gets faster to do. The control doesn't change.

4. 04Optional standing mappings

   Optional. Where a customer sends the same file on a schedule and the mapping has been stable for a while, that one mapping can run on approval-by-exception, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No percentage of time saved, no mapping-accuracy figure, no “onboarding in hours not weeks”. We haven't run this on your files. The dry run is where those numbers come from, and they'll be yours.
• No customer claims on this page. No names, no case studies, no logos.
• It doesn't fix bad data. It finds it, names it and asks. If the customer's file genuinely doesn't contain the field you need, no amount of modeling will produce it — and the honest output is a question to the customer, not a value.
• It isn't a data-quality program or a master-data strategy, and it doesn't replace the judgment of whoever owns your schema.
• Fully autonomous loading isn't on offer. The design assumes a person signs off the mapping. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI map a customer's data file to our system?

Yes - and the honest version is that it proposes the mapping and a person approves it. An AI agent can profile every column, work out what each one actually contains rather than what it is called, propose a target field for each with a confidence value and a stated reason, and write the transformation rules for the fields that need converting. What it does not do is decide on its own that a column it is unsure about is close enough. That is the one decision that quietly corrupts records downstream, so it goes to a person every time.

Will it load data into our live system on its own?

No. The mapping, the transformation rules and a dry run over the whole file go to a person as one reviewable document, and the load happens after they approve it. Every load is scoped to a run id so it can be rolled back as a unit, and one flag puts the whole system back to dry-run-only with no deploy. Where a customer sends the same file on a schedule and the mapping has been stable for a while, you can choose to let that one standing mapping run on approval-by-exception - but that is a decision you make, per mapping, after you have seen it work.

How does it handle a column it has never seen before?

It reports it as unmapped rather than finding somewhere to put it. The profile - type, format, distinct values, a sample of real rows - goes to the reviewer with the question stated plainly: here is what is in this column, here are the two target fields it could plausibly be, which is it. Once you answer, the decision is saved as a rule, so the same column from the same customer never asks twice.

What happens to rows that fail validation?

They are reported, not dropped and not guessed at. Every row ends in one of three states: loaded, loaded with a flag, or not loaded with a stated reason - and the counts are reconciled against the source file before the run is called finished. A row that cannot be loaded comes back with the exact ask: which row, which field, what is missing, and which rule required it. There is no silent partial load, because a silent partial load is the specific failure this design exists to prevent.

Can it handle messy real-world data - one address in a single field, five in another?

Yes, and that is most of the work. One customer sends an address as a single blob, the next splits it across five columns, a third puts the unit number in a notes field. The bot writes a readable transformation rule for each case - split, normalize, resolve a date format per column from the distribution rather than row by row, translate their codes to yours - and the rule is editable and versioned. Where a value genuinely is ambiguous, it is held rather than resolved by guessing.

Does it work with Salesforce, HubSpot, NetSuite or our own database?

Yes - by API, by a staging table you own, or by producing a file for your own loader, alongside Microsoft Dynamics 365, QuickBooks Online, Xero, PostgreSQL, MySQL, SQL Server and warehouses like Snowflake or BigQuery. If your target is not one of those, the question is only whether it offers an API, a bulk import or a staging table; most do, and a staging table is all a dry run needs. Naming a system means we can read or write it, not that we are partnered with it.

Is there a record of what it did to each row?

Yes, and it is designed for the person who has to explain a wrong record six months later. One immutable row per loaded row records the source file and cell range, the target record, the mapping version, every rule that touched it with its version, what the value was before and after, the outcome, the reviewer who approved the mapping and UTC timestamps. The intent is that someone who was not there can reconstruct any single field from that one row - and that the whole load can be rolled back as a unit.

What stops something in the customer's file from changing what the bot does?

Cell contents, sheet names and column headers are treated as data and never as instructions. Every model call runs as structured output against a fixed schema, untrusted text is kept out of the instruction block, and anything that reads like an instruction is quarantined, flagged for a human and logged. A spreadsheet cannot approve its own mapping. Separately, the validation rules and the hard stops sit outside the model entirely, so there is nothing there to talk around.

How long does it take to get running?

The first milestone is a dry run, and it needs three things: your target schema, two or three real customer files you have already onboarded by hand, and the mapping decisions your team made on them. We will not quote you a timeline before we know which systems are involved and what access they allow - you get a real one in your quote, once Ozzie's call has gathered the details.