Worth clarifying that we don't do any of this - we absolutely don't scrape the data of your 1st degree connections or anyone else; only leads that you explicitly query.
Email addresses are then verified using sources in the public domain.
I agree that this is all certainly worth emphasising further and I think we could do with further clarification points in the FAQs.
Finally, we originally built this as an internal tool, but decided to wrap it up as a public facing one.
You need a "Delete my account" button. I just signed in to take a look and realized I needed an API to really test a few addresses and didn't want to bother.
Our users really are across a bunch of different industries. That's the thing - this is such a widespread problem that it's not constrained to one space. Data from Saleforce -> Mixpanel; eBay -> Shopify; NationBuilder -> centralised data warehouses are some examples.
We're very much focussed on automating the process of getting rows and rows of data out of one system and into another. (e.g. transfer all of today's sales data from one platform to another)
IFTTT is much more event-based (e.g. when I receive an email from person x, send me a text)
The focus is much more on people who are currently running existing, manual processes in spreadsheets (e.g. monthly reporting) and has much less of a database element. For example, we don't do any of the "loading" stage in a typical ETL process.
This is an awesome concept- I always find myself trying to get the best deals. The biggest issue for me is the upfront fee. A percentage of final savings would be far preferable.
Thanks for the feedback. The big pain point we are focussing on is when you are given someone else's spreadsheet that you are not familiar with. It then can take hours to get your head around how they have put it together.
In this regard, Slate is most useful as way of semi-automatically documenting the spreadsheet.
We made the Iron Man example specifically for HN - possibly not the best thing to pitch big financial firms with - fair point!
I've spent weeks trying to understand a large spreadsheet. Mind you, a lot of that was persuading people that I was correct when I said what it was actually doing was at odds with what they though it should have been doing!
We think a lot of the value in Slate will lie in the ability to alter the level of detail you can see in the model. One of the really exciting ideas we have is to allow you to group together nodes in a tree to form a "parent node" representing some higher level functionality (e.g. by geographical region as you suggest, maybe EMEA forecast for example) . Then there will be the option to take the general overview of the spreadsheet, or dive down into the details.
Hi, then if you are building this you should put a real database in the middle and work on hierarchies, structures, mappings, comparisons and drill downs. You should allow multiple users to pull data from said db into their Excel. You should do this better than the existing (crappy) solutions like HFM or BPC. If you do that, I see quite a lot of value for finance-controlling.
Sorry you did not find it helpful for the sheet you tried it on. We have not yet implemented a way of showing 2D nodes in an intuitive manner and this is one of our focuses for the next release.
You mention context - I think this presents possibly one of the biggest barriers to adoption. We included the ability to jump back to the cell in Excel as a result of similar feedback. There is definitely a lot more that can be done though.
You also allude to where we think Slate can be really powerful - documentation. If we were to implement the ability to annotate and group together nodes in Slate, you can give a general overview of how the spreadsheet is working, with the option to dive deeper and investigate the nitty gritty, if needs be. All too often you are given someone else's spreadsheet with no context, and this is where we think further value lies.
Would love to take this conversation to email to discuss further. I'm fraser@useslate.com
What we have found is that one of the biggest problems in the BI space is the fact people are not able to code and resort to some of the horrific formulae we see. But agreed - including macros would add a huge new layer of complexity!
I much prefer reading Excel spreadsheet with complex formulae, than those with complex macros. It's much easier to follow things around and literally 'see' what's going on.
Email addresses are then verified using sources in the public domain.
I agree that this is all certainly worth emphasising further and I think we could do with further clarification points in the FAQs.
Finally, we originally built this as an internal tool, but decided to wrap it up as a public facing one.