Lessons learned from building a CSV importer with Lior Harel, founder of Staircase
We sat down with Lior Harel, co-founder and CTO of Staircase AI, who shared his experience with building an in-house CSV Importer at his last startup.
August 12, 2024
We sat down with Lior Harel, co-founder and CTO of Staircase AI, who shared his experience with building an in-house CSV Importer at his last startup.
Staircase AI is pioneering Customer Relationship Intelligence. The platform leverages AI to analyze millions of customer interactions and turn them into actionable human insights, impossible to spot with the naked eye. Staircase reveals deep human signals and uncovers customers' health, sentiment, journey events, risks, and opportunities.
The ability to import CSVs was a critical part of our workflow, but our CSV Importer actually launched as an internal tool first. We wanted it to be user-facing initially but found that it was really just too complicated. Our customer success teams ended up logging in on behalf of the user and just doing the import for them.
Eventually, we started charging a professional service fee because it was taking our team so much time to onboard customers (note: OneSchema customer PracticePanther faced the same issue).
For me, the largest consideration was what would prevent us from having to encounter cases where we would have to “undo” imports for users. While it may seem simple, undoing an import is actually very complicated. This is because an upload can trigger numerous automation to occur which have huge implications if they’re undone. It’s not only the record itself that you need to undo, but also all the downstream resulting events of that upload.
Because of this, we decided to invest in a robust “preview” pane so that our customers could see exactly what their data import would look like in the product (e.g. this import will update X records and create Y new records). The main goal of the preview was to decrease support tickets submitted, and the subsequent manual work that our team would have to do to fix the issues.
.png)
Usually, two people were working on it, and then we had to dedicate some design resources as well for certain features.
In the first few months, we developed a V1. After testing it in production, we found out it simply wasn’t good enough and had to develop a new version from scratch.
This second version included more advanced features like the preview feature I mentioned previously, column mapping, guessing the column mapping based on expected values for the columns, etc. The first version was very naive and resulted in too many data discrepancies and incorrect imports, so we had to start over to make it usable.
Even after building the second version though, the maintenance effort was endless. Features that seem very straightforward turned out to require a lot of effort. For example, one major issue we faced was with supporting date formats.
Anyone who’s used Excel knows that it doesn’t matter what date format you put, when you export it Excel will put it in a different date format. Sometimes, even within a given file, there are multiple date formats. Because of this, we had to build in functionality to ask users what their preferred date format would be for the file during the import process. Additionally, if the user was on a Mac and the file opens in the “Numbers” app, for whatever reason the CSV date format will change.
This particular feature was so much effort to maintain that we eventually decided to not support importing Excel anymore – only CSVs.
We were evaluating vendors for everything. We didn’t want to build things like managing size uploads, managing images, analytics, etc. I always prefer to use a service. For startups, velocity is a key factor and I didn’t want to invest the time building an importer when we could be focusing on the core product.
For the CSV Importer feature though, I actually didn’t even think about the fact there would be a vendor in this space. I was building it in 2016 and there may not even have been companies at that point, so we didn’t evaluate any before building it in-house.
We ended up dedicating an entire team to work on it and invested so much effort – that’s why I was so happy to be connected to OneSchema since we’re tackling the problem again. This time we can save a lot of time and resources by using a vendor.
{{blog-content-cta}}
We sat down with Lior Harel, co-founder and CTO of Staircase AI, who shared his experience with building an in-house CSV Importer at his last startup.
Staircase AI is pioneering Customer Relationship Intelligence. The platform leverages AI to analyze millions of customer interactions and turn them into actionable human insights, impossible to spot with the naked eye. Staircase reveals deep human signals and uncovers customers' health, sentiment, journey events, risks, and opportunities.
The ability to import CSVs was a critical part of our workflow, but our CSV Importer actually launched as an internal tool first. We wanted it to be user-facing initially but found that it was really just too complicated. Our customer success teams ended up logging in on behalf of the user and just doing the import for them.
Eventually, we started charging a professional service fee because it was taking our team so much time to onboard customers (note: OneSchema customer PracticePanther faced the same issue).
For me, the largest consideration was what would prevent us from having to encounter cases where we would have to “undo” imports for users. While it may seem simple, undoing an import is actually very complicated. This is because an upload can trigger numerous automation to occur which have huge implications if they’re undone. It’s not only the record itself that you need to undo, but also all the downstream resulting events of that upload.
Because of this, we decided to invest in a robust “preview” pane so that our customers could see exactly what their data import would look like in the product (e.g. this import will update X records and create Y new records). The main goal of the preview was to decrease support tickets submitted, and the subsequent manual work that our team would have to do to fix the issues.
Usually, two people were working on it, and then we had to dedicate some design resources as well for certain features.
In the first few months, we developed a V1. After testing it in production, we found out it simply wasn’t good enough and had to develop a new version from scratch.
This second version included more advanced features like the preview feature I mentioned previously, column mapping, guessing the column mapping based on expected values for the columns, etc. The first version was very naive and resulted in too many data discrepancies and incorrect imports, so we had to start over to make it usable.
Even after building the second version though, the maintenance effort was endless. Features that seem very straightforward turned out to require a lot of effort. For example, one major issue we faced was with supporting date formats.
Anyone who’s used Excel knows that it doesn’t matter what date format you put, when you export it Excel will put it in a different date format. Sometimes, even within a given file, there are multiple date formats. Because of this, we had to build in functionality to ask users what their preferred date format would be for the file during the import process. Additionally, if the user was on a Mac and the file opens in the “Numbers” app, for whatever reason the CSV date format will change.
This particular feature was so much effort to maintain that we eventually decided to not support importing Excel anymore – only CSVs.
We were evaluating vendors for everything. We didn’t want to build things like managing size uploads, managing images, analytics, etc. I always prefer to use a service. For startups, velocity is a key factor and I didn’t want to invest the time building an importer when we could be focusing on the core product.
For the CSV Importer feature though, I actually didn’t even think about the fact there would be a vendor in this space. I was building it in 2016 and there may not even have been companies at that point, so we didn’t evaluate any before building it in-house.
We ended up dedicating an entire team to work on it and invested so much effort – that’s why I was so happy to be connected to OneSchema since we’re tackling the problem again. This time we can save a lot of time and resources by using a vendor.
{{blog-content-cta}}
