For me, Bigcommerce crossed the line from incompetence to scam in the way many once promising startups do, in dealing with customers and money. This isn’t to say they were acceptable before that point, they were blisteringly incompetent, money just cleared up the reasons for it. Lets take a look at the sorry tale that led SemiAccurate to Bigcommerce and why we feel it necessary to call them out.
Note: The author became involved in this story late in the process but people he knows and is associated with have been part of it from the beginning. We will try to be as objective as possible but some of the parts recounted can’t be purely so. SemiAccurate’s manager, Copper, was also involved in the process.
The story started out with an eCommerce website project that people close to SemiAccurate were involved in, a small store being moved from an outdated framework to a more modern and maintainable solution. It had all the normal constraints, small budget, unclean patchwork database, and tight deadlines. The number of product types were small, barely over two dozen, but the possible variants for each one ranged into the thousands. From a database point of view there were a lot of possibilities but it was not a complex database by any means.
One of the first things the people doing the site revamp realized was that the old “database” wasn’t actually a database, just a bunch of linked spreadsheets held together with the proverbial bubble gum and baling wire. As soon as the links and connections were parsed and documented, the first real order of business was to import it in to a real database. This went along easily enough with only the usual database glitches.
Initial evaluations of eCommerce platforms lead us to Shopify, a platform that was quickly ruled out because of item variant limits. It worked just fine in tests but internal item count caps would have forced splitting things up in a way that would be a maintenance nightmare down the road. The search for suitable platforms began again.
One of the first edicts the project planners laid down was a simple upload and maintenance method, the people who would be running it after the initial move were not very computer literate. Coding a solution with Amazon APIs for example wasn’t an option for both cost and maintenance reasons, custom is always a bad idea here. If changes needed to be made later, a simple GUI and 3rd party support was a necessity. That narrowed down the field to basically one, Bigcommerce.
Bigcommerce has a slick looking site if you like dumbed down phone UIs but ironically the customer was a good fit for that. Their features and documentation would support the number of variants needed for this store with one minor change to the database, and a deeper dive into the documentation confirmed that Bigcommerce was the closest fit to all of the project needs. Everything else had fatally low constraints or glaring maintenance red flags so Bigcommerce it was.
The first indication of a problem with Bigcommerce came in the form of the initial picture file upload. Webdav was the method of choice for sending pictures of products to BigCommerce if you didn’t want to use the GUI for each of the thousands of variants individually, FTP was not available. The first upload was quite slow but everything arrived, however once the pictures were uploaded it effectively locked the account. The account read as being over bandwidth even though the account type included unlimited bandwidth. The development team was then told that they needed to upload pictures individually or have them uploaded along with the product file to avoid locking up the BigCommerce system. There was no diagnostic error message, just a lock that effectively ended all possible work until Bigcommerce reset things.
For some reason uploading that many images to a directory through their imports/uploads mechanisms locks their system but there is no process for uploading nested files. A support ticket was filed on a weekend and support was not provided until the project manager called BigCommerce on Tuesday or Wednesday of the following week. Progress on the ticket was nonexistent until a follow-up call was placed after a week of waiting, Unfortunately there was not a fix, they just said it was reset. The initial error of exceeded bandwidth on an unlimited bandwidth plan was never escalated nor resolved to our knowledge, to this day months later it will still lock their system.
Note 2: Over a month later, one of the people working on the project was told that there were too many inodes on a single layer of the directory. This caused their web GUI or WebDAV to time out, they didn’t know which one it was. The file count was well within their stated limits, there was no option possible to make subdirectories or otherwise partition the files, and to date months later, Bigcommerce has still not resolved the problem or contacted any of the developers affected by it.
Once this was dealt with, or not dealt with as the case may be, the developers set about formatting the full database to output formats that Bigcommerce could import. The idea was to upload some test data, export them from the site, and try and re-import them into the customer’s database. This was done for future maintenance reasons, both ways needed to be easy for the end-user to manually sync local and site resources.
As normally happens this process uncovered a host of other database problems, mainly things like reserved characters being used in the product names, image files not exactly matching the database descriptions, and similar small cleanliness minutia. The first few test uploads to Bigcommerce were agonizingly slow then hung with only minor feedback from the site. Occasionally there was an error box that asked to continue or abort but neither choice would complete the process or unhang the system. There was no progress bars or any other feedback other than the aforementioned error box.
To make matters worse, during the transfer there was a pop-up that has a progress bar and it gives you a count of how many records are processed. A big problem with it is that unless you let the entire import process complete you can get no error messages. Even when you let it finish the information is rarely helpful. There is no option for even a slightly technical person to debug the import process it either locks or says it completes even if it doesn’t. Often the system would just hang and never let you know it was stuck so at best you let it sit 15 minutes and if it didn’t progress, you canceled the import – losing all hope of possibly seeing a scant few errors messages. Maybe.
While this was unnerving it wasn’t exactly abnormal when dealing with large serial uploads. When the now hung browser window was restarted and the user logged back in to Bigcommerce, the last uploaded item was different every time even if the process was repeated twice in a row without changes. That struck some people working on the project as odd but they kept trying new ways of uploading. Delimiters were changed, documentation pored over, smaller batches attempted, and even just the database without the associated product pictures were tried. Nothing had materially different results.
Bigcommerce has a feature where it will either pull images from another location on the web or take them as direct uploads. The preferred direct method still locked the account so webdav was not a viable option. With more than 30,000 images to upload, the one at a time web interface obviously wasn’t an option so both automated methods were attempted. Neither worked any better than WebDAV although a few more typo/delimiter level errors were uncovered in the many attempts. None of the offered upload methods would work, everything failed with a hang 100% of the time no matter what anyone involved tried. There seemed to be literally no functional method to upload data to Bigcommerce.
When in doubt file a tech support ticket. With tickets filed the project manager waited. And waited. And waited. After about two business days of radio silence, a call to Bigcommerce tech support was placed and a technician started the troubleshooting process. Actually to call the person on the other end of the line a technician was giving him far more credit than he was due, he didn’t have a clue much less something as sophisticated as a troubleshooting script to follow. To say he didn’t understand the platform he was supporting was an understatement, he didn’t really understand computers at a fairly basic level.
The call started going badly when the technician reported that the problem was not repeatable on their end because he didn’t know how to change delimiters in Excel. No really, the support explanation he gave was that he didn’t know how to change delimiters in Excel so it couldn’t actually be a Bigcomerce problem. *BLINK* The caller politely explained to him that they were not using Excel, they were using LibreOffice which does indeed allow you to change delimiters.
This didn’t go over well but the support person continued to plug away at our problem. His next helpful advice was that we shouldn’t be changing delimiters because if he couldn’t do it in Excel, Bigcommerce didn’t support it. I am aware that this does not parse in any logical way but that was the explanation given. Efforts to explain to him that Bigcommerce does indeed support delimiters other than comma, a big problem if your product names have, oh say, commas in them, failed.
It took a long time to get across to this technician that the Bigcommerce documentation directly states that other delimiters are officially supported. That documentation and the drop down menu on the site which explicitly allowed different delimiters seemed to convince the “tech” that it may be possible even if it was beyond his skill level. He then came up with the helpful suggestion of using the GUI to manually enter all roughly 30,000 products one by one. When the potential time involved with this ‘fix’ was pointed out to him he decided not to continue advocating that particular path.
Confused but educated the technician didn’t do the expected transfer to a higher level of support, he instead promised to escalate the issue and someone would follow-up. In case you don’t see where this is headed, no one ever did. In the mean time more attempts were made with different delimiters, different fields, and numbers of items. Nothing worked.
Several days and several follow-up emails from the coders without responses later, another call to support was made. This time the advice given was a bit more technical. To paraphrase the response, you are doing too much, try smaller batches. Also try smaller batches without custom delimiters. It was again explained that this has been tried in dozens of different combinations of size and delimiters with no luck prior to the call. Eventually the support person said that he couldn’t recreate the problem on his end but it could be a memory limit problem on the server. He promised to escalate the issue.
Over the course of the following weeks, several attempts were made to find out the progress of this escalation and prior ones. Emails and calls were placed to try and get either in contact with those it was escalated to or get their direct contact information. None was ever given, it was full radio silence from Big Commerce. There was never any useful information or help provided through any of these contact attempts, nor was a single request ever followed up on by Bigcommerce, ever.
Enter The Account Exec:
Sometime in the following weeks the project manager got a call from their Bigcommerce account exec asking how everything was going. He politely offered to help with random items that had nothing to do with where we were at in the process. It was if he was phoning in from another planet. Our initial phone conversation with our “account exec” indicated that he was not technical support but could offer “other help.” So rather than call our account exec for technical support we used the more typical channel of “tech” support. That said emails were never returned, nothing was fixed, and there was no follow-up. At this point the project was several months in and something as simple as a .CSV upload was still not working. This is the point where the author got involved.
Enter Me Too:
I was asked to keep an eye on things and document them in case it ended up as much of a debacle as it seemed. Since I had been occasionally answering technical questions from project personnel, I was at least familiar with the situation on a cursory level. After a while the project manager asked me to step in and make the call to the Bigcommerce account manager because she was so fed up with the lack of responses and abjectly broken features that she didn’t want to deal with them. I was technical and know how to ask for things to be escalated for technical reasons so I lead the call. Some on the team even believed my obstinance and ability to not let some things go would be an asset here. With such praise, how could one say no?
The first thing we did was call the main Bigcommerce main number and ask how to get a refund to the fees charged to date because their site simply did not work as advertised. We were promised a refund, told that “you clearly qualify for a refund”, and asked if there was any way that the situation could be solved at this point. We said we wanted the refund but were willing to listen to what they had to say in case they actually had solutions to the myriad problems encountered so far. We were promised answers and got a voicemail from the aforementioned account manager shortly after the call concluded.
When we got on the phone the account manager asked us why were were not calling him directly instead of tech support. We replied that he didn’t indicate that he was technical on his earlier message, just asking us if we needed help with tax tables and formatting. We felt we were correctly routing tech questions to tech support and other issues which there were not until this point to him. He explained that he was indeed technical and “knew this product very well“. Finally after more than two months, progress, maybe.
Even though it was late in the day on a Friday he promise to get in touch with our database tech and assist with any problems. During this conversation we pointed him to the tech support tickets and calls we had filed along with associated data, samples, and errors. He said he didn’t have access to any of that, quite curious but possibly understandable. SemiAccurate is used to support personnel doing a cursory bit of homework before calling an annoyed customer asking for refunds, in this case that clearly didn’t happen.
During this call our product manager started asking hard questions about why there was no escalation process, why there wasn’t a single response from tech support, and why things were dead in the water. She basically wanted what the account manager had promised, help. Instead of addressing the issues the Bigcommerce account manager called our project manager sexist names. Stunned she asked him if he just called her the name she thought she heard. He stammered and said, “No, I called you [another sexist name]“. The project manager walked out of the room and refused to talk to him from that point on. She had no wish to deal with anyone who responded to valid technical and managerial questions with belittling and sexist names. I continued on.
Asking about the escalations we were promised, he had no idea who to talk to about that or the status thereof. Again he didn’t have access to any tickets filed or information sent but promised to follow-up. This was the first sign on actual progress on solving our problems. He indicated that he saw some problems, that it could be our use of non-comma delimiters, and several other things. The call concluded with him promising to follow-up after he had a chat with our database guy.
A New Process:
Later that day our database programmer reported that he did give the account rep a full rundown of the problems, attempted solutions, and the general state of the project at the moment. The account rep would follow-up with answers. The following Monday there wasn’t any response so at noon an email was sent. Other than headers and names the full response is below.
[Database guy] had sent me the export and I tested multiple scenarios over the weekend. Simple products went in fine, only issue seemed to be when creating SKU’s with products.
What I’d suggest doing here is first running an import of the basic product data, that way the products are created and assigned Product_ID’s as well as images are pulled in. After that, export from the site, merge the SKU’s in for the products that are available to be personalized, then update.
I recommend just breaking up the process a little bit, do it in stages and it should be fine. Splitting up the batches makes it easier to resume if an import fails, rather than purging all products and re-importing.
Thank you for the patience and let me know if you have any questions.
In essence, the “technical” account manager told us to do all the things we had tried that we told him didn’t work. There were absolutely no new ideas, information, or solutions offered. The project manager tried to clarify this in an email and our initial thoughts were confirmed, he was telling us to try the same things that failed before again. The only minor difference was to do it in a two-step process that failed in earlier testing and took us dangerously close to the unmaintainable process problem.
In situations like this if you don’t actually try the things tech support tells you, they generally stop bothering to try and help you from that point on. Even with the abject lack of help from Bigcommerce so far, we decided to try it again. Needless to say it failed and the uploads hung in the same way but hours more of everyone’s time was wasted.
The net result was that when following the account manager’s instructions, the upload status showed zero imported product but upon reloading and checking manually, 33 of the 30,000+ went through. Repeated attempts with hours of waiting resulted in a high water mark of almost double that amount getting through although the count varied with every attempt. This new upload method was tried from multiple locations, it wasn’t a connectivity problem on our end.
Some additional attempts the database programmer ran involved following the account manager’s instructions with *1* item in the .CSV, something that certainly met the smaller chunks requirement. It too failed. As did stripping out all characters that could potentially be delimiters from the database and uploading it again with the default commas as delimiters. This got absolutely no farther than the custom delimiters, it wasn’t a delimiter issue, Bigcommerce was abjectly broken.
The database programmer wrote several detailed emails with processes attempted, error logs, samples, and everything else this type of person is known to compile. It too was ignored. Radio silence. All the promises of help and technical assistance seemed to be at a dead-end and still no responses issued from Bigcommerce unless we followed up, nothing ever started on their side. This time nothing happened no matter how we attempted contact, something that is always a bad sign.
Moving Things Forward:
In the best practices of dealing with lost causes and unresponsive companies, I wrote an email to the project manager asking where our promised refund was, why there was no acknowledgment of the issues raised, and why there was no response to the data submitted generated by his “solutions”. I also CC’d the two listed CEOs and founders of Bigcommerce.
For some odd reason soon after this was sent, the account manager decided to acknowledge our requests again. Better yet he suddenly received all the emails that the database programmer sent days prior and responded to them. Unfortunately this meant he didn’t respond to any of the points I raised and conveniently left out all of the CC’d names at his company. His response, again edited for names and formatting, was….
Sorry I hadn’t had a chance to reply to you earlier, it has been a busy day. It seems to be an issue with the SKU’s primarily. In the files you sent over there was some option set information in the SKU rows, however, I cant be certain that is causing a problem. Unfortunately I haven’t had an opportunity to test them either.
A large import like this may work better through the API, more information on the API can be found here: https://developer.bigcommerce.com/api
That is a little advanced for me but I know you all are very technical and the API may be a better solution.
In short he now was saying in no uncertain terms that their entire upload process was non-functional and they knew it. It didn’t work and he couldn’t be bothered with trying to help us even though he had earlier offered to do so claiming high levels of technical and product knowledge. The entirety of the “solution” was effectively to use the provided API, the very thing they are being paid to simplify and work around for the non-technical user. Bigcommerce’s web site advertises features that their service promises to provide. None worked, literally none. No support was given. No tech support tickets were ever followed up on. When pressed they ignored the problems until we CC’d management and only then told us to code it ourselves.
There was one other option offered but it was by voice to the database programmer and not in writing. It seems Bigcommerce has a programming team to assist with imports, something that the service you pay for and their web site promises to do for you. This the Bigcommerce value add that they charge and were paid for but failed to deliver in a spectacular fashion. Their automated process simply does not work but the idea of actual assistance from someone technical at Bigcommerce was intriguing. That said it wasn’t a long-term option because of the original maintainability requirements but if it could move things forward….
Needless to say the generous offer was not an offer of help but an added service that was charged at full rate plus what seemed to be a bit because it wasn’t purchased during initial setup. Then again it wasn’t offered until months into the project and only then once it was clear how abjectly broken Bigcommerce’s product is. For the record the price tag for this service was higher than the project budget. It was politely declined.
More worryingly not a single one of the emails asking what was happening to the promised refund were replied to, instead the account manager always responded to technical threads from the database programmer adding in people from managerial/process threads if absolutely necessary. Does this sound worrying to you too?
After this was pointed out in another email, with the same CEO/founders CC’d, someone from “Support Escalations” finally replied to one of the emails sent by the database programmer weeks before. After nearly a month there was a sign of actual support, not just someone who couldn’t mentally sort out the difference between Excel, a web based eCommerce platform, and his own lack of basic computer skills. The entire email said:
Thanks for your patience and I am so sorry for the delay due to a backlog of escalations we are currently working through.
Apologies for the problems importing your SKUs! I have tracked the problem to a software issue with including the (.) period in the “Product Name” column for an option SKU.
In other words, the stall in “80.csv” was being caused by this field:
[C]Personalize for $15.00=Yes
I tried doing a find and replace to the fields in the CSV so that I was importing to remove the periods:
[C]Personalize for $15=Yes
and the file imported without issue.
I have documented this as a software issue with our developers under
BIG-8056 “Importing Option SKUs with a period (.) in the Product Name column stalls the import”.
A fix will unfortunately not happen overnight- but hopefully now at least with knowledge of the issue you can sidestep the problem. I am so sorry for the trouble.
Please reply to this email if you are having any more outstanding issues with importing and I will look at them ASAP.
Thanks for using Bigcommerce!
Your Friendly Support Rep
No we are not kidding, that was the response from higher level support after three weeks of waiting, pestering, and sending logs. We should at this point note that the “Support Escalations” “technician” was again completely and totally incorrect. During the upload with all delimiters removed mentioned above, periods were stripped and it made no difference. We can not explain how he came to the above conclusions other than he flat-out made them up. We still doubt he actually tested anything.
For some reason none of the people on our end were comforted by his prompt 20+ day documenting of the issue, incorrect though it was. That said we still removed the periods and followed his suggestions and retried the upload. For some reason it did not fix the issue or change anything which only reinforced our fabrication theory. Last time it was attempted nothing has been fixed and no further followup’s to this or any other communication with Bigcommerce have been received.
Note 3: According to our database programmer, the problem with their explanation was that “ALL” previous records except the last one would import just fine with the decimal point in the Product Name field. This could be confirmed by looking at all the items from the last import. In short their explanation was BS and anyone with a cursory knowledge of databases could see this instantly from the logs. Don’t forget this is from, “Support Escalations”, not an Excel genius on the front lines.
Similarly two subsequent letters to our account manager have gotten absolutely no response, not even the usual miraculous discovery of previous emails. The promised refunds were not given weeks later, and more troubling the credit card used for the purchase continued to be billed by Bigcommerce. This is what prompted SemiAcurate to consider Bigcommerce a scam rather than an incompetent and troubled startup.
Technical problems, even abjectly broken sites are not uncommon in the startup world. Lackluster technical support is all too common too but it is a rare case where there is absolutely no way to escalate a real problem. Once you get to the point where someone from, “Support Escalations” fabricates issues and claims it solves problems, you know something is amiss. More importantly, even the most disorganized of startups tries to fix broken products, something we saw absolutely no sign of from Bigcommerce.
Before this article was written the author searched for a Bigcommerce press contact and found only a 2+ month old help wanted ad. An email identifying the author as press and indicating that he intended to document this story was ignored, and to date there has been no further contact since the escalations reply. The account manager also refuses to respond to us when asked about technical issues or refunds. The promised refund was never given and the credit card company eventually had to reverse the charges. Bigcommerce is however still trying to charge the client every month.
Throughout this whole process, two things were clear. Bigcommerce has absolutely no technical support capabilities much less an escalation process. Everyone, technical or not, who contacted them by phone had the same reaction after the call, one of, “Did they really just say that?” Secondly there was never any follow-up of any kind without angry prompting from the customer. Bigcommerce would only respond to concerns when it threatened their future income, and then only by changing the subject. If it looks like a scam, quacks like a scam, you can make up your own mind.S|A
Note 4: Copper here, my impression of the whole system that is BigCommerce is that is it not a company that wishes to retain customers. Get customers, yes, retain them, no. Most companies that are in the service field attempt to communicate with their customers when there is a problem. The account manager’s communications seemed utterly and completely divorced from reality. We learned why at the end of our relationship with BigCommerce in that he cannot directly see the technical support tickets, or be bothered with getting them when needed. That business oversight strikes me as a structural deficit that can have no good ending.
Most companies that are in the service field attempt to keep a customer by a) apologizing for any issue that is on their end, we do so here at S|A (and we’ve had our share of software headaches) and b) extending the service for free, offering discounts, etc. as an attempt at making the customer feel like their business is worth keeping and that you will offer a product they can use in the long run. If you read the comments about Bigcommerce at Glassdoor, many of them like this indicate a workplace that reflects our experiences with the company.