Aithentic turned scattered spreadsheets
into a controlled, self-serve migration.
A guided import flow that lets prospects bring their existing inventory instead of losing deals to manual onboarding.
1
The
problemSales couldn't close enterprise prospects who already managed their inventory elsewhere — in another platform, or in spreadsheets exported from one. The only path onto Aithentic was a technical specialist manually re-entering their data, which didn't scale past a handful of deals and slowed every sales cycle down. The product problem: let a prospect bring their own messy inventory and reach a working Aithentic account without engineering involved. 01 – A prospect starts from the inventory file they already have — no manual re-entry required.
2
Constraints, and the alternative I rejectedPre-sale phase — no live users, no usage data; designing for a scale I could only estimate from what sales expected to show in demos (thousands of rows). Source files came from arbitrary systems, with inconsistent columns and missing fields. The feature was scoped to admin-only accounts, so the flow didn't need a permission matrix of its own.
The alternative was keeping the manual path: a technical specialist maps and enters the data for every deal. I rejected it — it doesn't scale, adds services cost to every deal, and does nothing to shorten the sales cycle it was meant to fix. 01 – Import sits alongside manual entry and bulk edit as one of several ways to get assets into the system — the manual path stayed available, it just stopped being the only one.
3
Partial import instead of all-or-nothing A single bad row in a spreadsheet of thousands shouldn't block the rest. I designed a three-way triage — Ready, With Warnings, With Errors — so valid rows import immediately, non-blocking issues stay editable in place, and only critical errors are held back. The alternative — reject the whole file, or send the user back to fix and re-export — would have reintroduced the exact friction the feature was meant to remove.01 – Each warning names its specific cause, not just a generic flag. 02 – A final summary confirms exactly what will and won't be imported before anything is committed.
4
Two edit modes for two different problems A systemic issue — the wrong department mapped across every row — and a handful of individual outliers aren't the same problem. One bulk-edit pattern would be too blunt for one and too slow for the other. I designed column-wide edit for the first case and selective row edit for the second, at the cost of building and maintaining two interaction patterns instead of one. The alternative was thousands of individual clicks for systemic fixes, or no precision at all for outliers.01 – Column-wide edit updates a field across every row in the dataset at once. 02 – Selective edit lets users choose specific rows and correct just that column for the selection.
5
Treating upload failure as a first-class state Enterprise files are large and get uploaded over office networks that aren't always reliable. Losing progress mid-upload on a multi-thousand-row import — especially mid-demo — costs more than a slow upload does. I designed explicit states for lost connection, unsupported format, failed upload with retry, and interrupted upload with resume, instead of a generic error toast.01 – Lost connection is a named state with a clear next step, not a generic failure. 02 – An interrupted upload can resume without losing progress already made.
6
Edge cases
and impact Warnings are broken down by type — missing supplier, missing support partner, missing expiry date — with counts, so the cause is visible, not just a flag. Autofill offers a faster alternative to manual bulk edit for missing values. Multiple import sessions can run in parallel, each tracked independently, so one failed batch doesn't block the others.
Shipped pre-revenue, so there's no adoption data to cite. What I can point to: the flow was built to hold up against enterprise-scale test data — thousands of rows, concurrent sessions — which is what sales needed for credible demos. Post-launch, I'd track import completion rate, time-to-resolution on warnings, and the percentage of demo prospects who complete an import.01 – Multiple import sessions run and are tracked independently, so one failure doesn't block the rest. 02 – Every import is logged and traceable back to the person who ran it. My role
I collaborated with the BA and CTO throughout. The BA prepared the base logic; I reviewed the flow early, aligned decisions with the CTO, and designed the triage model, both bulk-editing modes, and the resilience states for upload failure. ← Previous Case • ListkitNext Case • Respeecher →