Shopify POS(shopify.com) |
Shopify POS(shopify.com) |
"The second idea is to create a POS system that integrates fully into Shopify. Thus one can use Shopify to manage sales for all the store's inventory both those that one sells through the web and also those that one sells from the physical store. The POS front end for Shopify will allow for Shopify to expand into those with both an online presence and those who also have a storefront. This is perfect for small businesses. I believe it could be very disruptive to the POS market because it would be very easy to adopt for customers."
Back when I applied to the Shopify Fund there were little requirements it just asked for ideas: http://web.archive.org/web/20111018133854/http://www.shopify...
I never heard back from them.
I bet their customers have been asking for a way to synchronise their shop floor stock with their online stock, and Shopify would naturally want to be the provider of the whole experience.
There's probably many reasons why your idea never got picked up originally. They may have been already working on or thinking about it; it may be similar to another idea submitted; they may not have expected it to be a viable option at the time.
The fact they didn't even respond sucks as that's not a good community spirit. Just be pleased that you've managed to predict what the future was. The trick is how to do something useful with those predictions.
All I will say is that its a bit unreasonable to assume that Shopify didn't have this in the game plan since going public. With Square slowly moving into Shopify's territory this is a fairly expected movement for Shopify.
It's very frustrating that they can release a POS system, however fail at, for example, complex sales reports.
I wish they'd get it together because they would blow everyone out the water.
I'm glad we finally have a generation of POSs that no longer fit the pun.
Excellent work, Shopify!
The site doesn't say that the POS supports a barcode scanner, but the video says that it does (and shows it in use). As a retailer, not having a barcode scanner would be a prompt deal breaker[0]. It should be featured somewhere on the microsite.
[0] lack of a barcode scanner isn't bad if you have 16 products. Once you're managing any serious level of inventory, especially with unique size/color combinations, there's so much risk for error if each item isn't being scanned. Then there's speed of service to the customer; it's just quicker.
I work with ATG, Hybris and IBM WebSphere mainly. These are the biggest players in ecommerce and some of the biggest brands with massive turnovers use these platforms.
Magento is seen as a bit of a joke among big enterprise ecommerce players. The kind of thing will a low entry barrier and with a userbase primarily made up of small retailers.
However, I would love to start my own ecommerce agency and the low barrier to entry could make magento the perfect choice for me. I'm not sure if any retailers actually spend serious money on it though, unlike the 3 big players I previously mentioned.
Am I the only one that immediately reads it as Shopify Piece Of Shit?
Edit: I see that is the retail price from http://hecklerdesign.com/product/windfall-for-ipad/
Moreover, I can't really be brought to care about these types of POS systems, primarily because they're all categorically atrocious. Many of my favorite coffee shops have been replacing their registers with iPads, and the universal result has been longer lines and more errors in recording orders. These things have consistently caused a regression of the customer experience in businesses. They're slow, they're unwieldy, and for whatever reason people demonstrate considerable ineptitude at using them. In my opinion, there is absolutely nothing wrong with the cash register. Things like Square should be used only in instances where using a traditional register would be untenable. The fact that companies are needlessly adopting these things and subsequently worsening the experience for their customers is tremendously disappointing.
The iPad will never be better at taking people's credit cards than a traditional register. It wasn't designed to, and companies should stop pretending otherwise.
Are you serious? You do realize that most "traditional registers" are used in conjunction with a credit card terminal and/or a computer + monitor POS system right? Both of those things are computers, and the iPad is slowly replacing a very large number of the things that a computer was traditionally used for...primarily because of three main advantages: portability, size, and enhanced UI (multitouch, gestures, etc.). All three of those (especially the last) offer huge advantages for registers and POS systems.
Sure, most offerings are currently somewhat buggy and scrappy. But what new technology isn't? I can guarantee it will get better. This is pretty classic innovation life cycle (http://en.wikipedia.org/wiki/File:InnovationLifeCycle.jpg). What you're saying is the equivalent to somebody in 2005 saying "Flash memory will never be used in place of traditional hard drives in laptops." That person would, today, feel pretty stupid.
The search engine market is saturated, and Yahoo! already has a tremendous foothold. I have serious doubts about the whether Google can succeed so late in the game.
I wonder why they stopped offering the whole kit. My only guess it was a MVP style trial balloon offering to gauge interest before building their own hardware. Or, it didn't fly, which may not bode well for Shopify either.
[0] http://appleinsider.com/articles/13/02/20/square-launches-ip...
In the past we've tried to sell our wares at Makerfaires and the like, and in the end we'd be getting people to use our laptop or iPad and place their orders through our site.
This dramatically simplifies the whole affair!
Credit where credit is due, this is pretty awesome :)
I haven't had the need to dig into Shopify in years but will be curious to see how it handles some of the complexities of multi-front retail.
http://www.shopify.com/technology/3032322-new-feature-metafi...
Is this a "winner take all" or "winner + 2nd place take all" space?
I feel bad for the local cafe that hitches their wagon to an eventual loser–especially if their data is locked in.
Just needs chip/flash (EMV) support!
1) Stability 2) A massive user base 3) An infrastructure to support that massive user base
BitCoin has none of those things, so I'd expect a discount on it!
hit me up here, on twitter (@orenmazor), or email: oren.mazor@shopify.com
Kimball's The Data Warehouse Toolkit is the definitive tutorial on the subject.
One of our early adopters was a very notable/early Shopify customer who encountered the kind of problems you describe with templates and customization. I am pleased to say they have been successful using Forward and Shopify combined in order to solve these problems, and are planning to migrate completely when the time is right.
Shopify is a great solution for small business without irregular catalog and checkout requirements. I am however surprised that they haven't done more to support businesses that grow beyond this stage.
That makes a whole lot of sense to me, and would be the only acceptable path to take in the eyes of their shareholders.
Also, checkout has a small legal nitpick here in europe, where a check has to be somewhere and in shopify is not. That means plenty of EU stores might be in a grey zone. Same with cookies in the checkout, but that's another story. I guess they will fix it but i guessed that 7 months ago.
I like Shopify in many ways, but after two (small) stores with them i have two main issues:
- EU distant. I feel US market is the main thing for them and EU is left behind using weird solutions for complex tax cases or pricing, few payment gateways, and so on. The checkout issue ilustrates this.
- Pushin new features while not fixing old ones. Shopify 2, Shopify Payments US, and now the POS are the examples. Meanwhile my app has to do crazy stuff to sync my products ids with their native ids.
Said this i will probably keep using it but Prestabox is tempting me for the next project. Any experiences with it?
Also, Shopify guys, the 15 days in advance warning for an api change in mid august was nice!
For example, the devs at my company that have had to use shopify hate it. Their systems are based on hacking javascript for everything. The deployments are very painful too. No way to see what it will look like without previewing it live on the site.
(Example: most products are free shipping but a few large products are not free; there was no control to exempt products from free shipping, nor any control to say products were not eligible for certain shipping methods. Not all merchants can overnight a 50kg box, for example.)
If that's not good enough there's apps like Better Shipping that can set up more complex shipping rules - http://apps.shopify.com/better-shipping
http://services.amazon.com/content/fulfillment-by-amazon.htm
I think there was FBA integration in Shopify but they're dropping it, but an app still let you integrate with FBA.
I think in Shopify you can view how many abandoned carts there are in the orders section, and it's not filterable.
I mean how difficult would be for Shopify devs to add a reports section on stuff like this. Just tabulated data would do, I don't need any animated graphs. It's very frustrating because the data is just out of reach in Shopify.
Edit: I'm not a Magento advocate here, I really really want Shopify to get better quick so I can stop using Magento.
For an environment like shopify (which I've never used, so speculating), their reports are much more likely optimized database queries or views, or even created from specially stored statistics data not from querying raw db tables, with caching or pre-generation at some point. This means there's a lot of thought behind every report, and what's possible with the current db/stats schema. Adding a column to a report might mean modifying the db schema.
The final issue is that user interface complexity goes up as reporting flexibility goes up. A super powerful interface that few people take the time to use is worth less than a limited interface that provides value to more people. The task is attempting to satisfy power users and more complex needs, while providing a very useful default functionality out of the box.
Once you start juggling the vast amount of data that needs to be stored, fetched, calculated and referenced to provide a report, it becomes a lot more than "why dont you just". And thats before scaling the system to the non-fail-whale standard that we run our infrastructure at.
But it is coming very soon. In fact, it's already available to PoS customers.
As I mentioned, feel free to ping me to talk more about this. I would love to have more input.
We found that the strategy works really well on paper but there are significant scaling issues on the querying side when you throw massive amounts of data at it. A simple sales report over cities for one of our larger shops under moderate load would could take 5-10 seconds to generate, which is pretty unacceptable. Caching would only take us so far because of how much data gets ETL'd every moment.
I definitely don't discount the dimensionally modelled strategy, but to make it proper fast, and not 1990's let-me-hit-report-and-go-get-a-coffee fast, you might need to write your own OLAP stack that's optimized for what you need[0]. I'd also do it in go or c.
Once we ship, we'll do a technical post on what worked and what didn't.
[0]I'd love to be proven wrong on this, so if you can generate fast reports with massive amounts of data ETL'd in real time, I'd love to hear from you. oren.mazor@shopify.com
You're actually at the coalface and I'm the bookworm, so I am totally prepared to be schooled on this one.
We did partition all of our dimension and facts tables, which helped a great deal. Aggregates were a problem that is specific to us, so we couldn't cheat the usual way that reporting servers do.
The other problem is that our stack is suddenly fully of things like java and olap and postgresql, which made onboarding people who wanted to help, and just debugging, a pain.
I like that comment about the coalface/bookworm, but sometimes it takes somebody on the outside to see what I'm missing.
There's no API order creation at present, but the API is consistently evolving as the platform does.
Order creation will be open soon.
Every e-commerce product across-the-board has this feature, and it's disappointing to see a platform as well-crafted and mature as Shopify still without many of the essentials.
We can now officially create orders via a POS system, but still can't create an order on our own website without registering as a customer or jumping through 3rd party shipping/tax/payment APIs.
You can do very well at much, much lower cost in the Python world: pandas, PyTables, or even just straight numpy.
Seriously, using any of these would make the report generation time basically zero, and you'd just have to make your ETL work quickly enough to feed it; how well this can be solved depends on how you store the original data ("pre-facts").
The book written by this guy http://blog.wesmckinney.com/ (and the guy himself, if you can get him) will probably advance you way more than experiments.
We ended up with a golang solution that we use essentially like you would with a column store. It's very fast and extremely thin.
Ouch. Do you really feel so well acquainted with their internal design that you can use such strong language? It comes across as dogmatic.
Would you have said that if I urged him to get a hammer to hit on nails, rather than a screwdriver? It is about as dogmatic. (you can put nails into a wall with a large enough screwdriver - I've done it myself before when the nail was small enough and i had no hammer - but it's still the wrong toolkit)