I understand the appeal of Salesforce, though in my experience it is just as clunky and slow as the software it replaced. I'm sure there are configurations that are not that way, but it's a horrible part of my day to day experience using it as a customer support module. Comments take 4 seconds to add. Opening a case in a new tab is 30 seconds or more. Comments and feeds load progressively, slowly, making it nearly impossible to get to the beginning of long discussions. URLs are long and crazy and have no useful info or anything cool in them. We've had Salesforce consultants and experts come in and gain a second or two here or there but it's been an awful experience over the last 5 years.
Had similar experiences with Netsuite and to a lesser extent Jira. So many layers of configuration options and hooks make everything super extensible, but it comes at a a cost and that cost is usually performance.
Yup, the "enterprise" software space is generally incredibly expensive and buggy and a poor user experience, and there is nothing anyone has ever been able to do about it, as firms want custom code just for them, and so the development/maintenance cost can't be leveraged over millions of customers all getting the same software like the B2C space. So given that the market is 3 orders of magnitude smaller, you have a choice of adding 2 orders of magntitude to the cost, and decreasing quality by 1 order of magnitude, or some other combination of this. That leaves you with a few options:
1. Don't allow businesses to customize at all, make them fit to you. That can work with something like ADP, but little else. A lot of the cool B2B startups think they can displace incumbents by just building cool, fast software, and then they are perplexed why they can't gain marketshare when every other customer has some bespoke use case they don't support.
2. Build a general uber-programmable platform that businesses can customize themselves -- now you are in the "slow", "poor user experience" territory but at least it works and is cheaper than option 3
3. Hire consultants to write bespoke products from scratch for each business. That's the old IBM Services model.
So if your baseline is Microsoft Office, then the performance/user experience of your favorite online B2B platform is going to be terrible. But if your baseline is IBM Services, then it's a godsend.
Choose 3 and then watch the consultants build the custom software using a low/no code platform. Now you are still in the slow and poor user experience and no customization options and more expensive and worse support ;-)
I think it’s pretty sad that enterprise software is mostly stuck the way you describe. There are companies willing to invest in fast and user friendly custom software though; the company I work for is pretty successful at doing just that.
All companies in this space start out fast and user friendly, but to gain additional customers in this space they need to add more features. See my first item. Then they either fail or end up an uber-platform. Again, this has nothing to do with your company, it is just the nature of the market, and it's funny when someone gets an idea to start a "lean", "fast" product as if no one else had thought of that before.
Really if you think you can do better than X, whether X is oracle forms or SAP or whatnot, it's important to understand where X went wrong. Hint: it's very rarely because they were "old-fashioned" or didn't realize that customers liked fast software that was easy to use. The founders of X were just as smart/capable as you are, but they faced a market challenge and made some choices with trade offs. If you limit your analysis to "they didn't know software should be fast", then you are not going to end up any better than they are once you reach their scale. I am not trying to say that every incumbent always made the right choices. But an understanding of where they went wrong needs to go beyond "they went wrong because they are old fashioned" or "they went wrong because they didn't realize software shouldn't be filled with bugs". There are real hard problems here that need to be understood before you are in a position to improve on what the incumbents are doing.
I agree, it’s their business priorities which result in engineering that leads to bad software. What I’m saying is you can choose to not buy into one of those uber-programmable enterprise platforms and instead (let someone) build fast and user friendly specific software just for your needs. All of the customization and dynamic crap can go out of the window that way, which will allow engineers to make things fast and user friendly again.
The problem is that the definition of "just for your needs" lasts about a year, max, and then your needs change. Businesses are constantly re-organizing and engaging in process engineering, and this creates rapidly changing needs. Go through this a few times and at some point you will get the bright idea that you need to create some DSL/platform metaframework to allow customers to auto-configure what "just for your needs" means or else you will be buried in a pile of feature requests that your tool doesn't have but the competitor does. And then third parties will come along and you'll want to package their work to create pluggable tools that customers can install. Then you'll spin up app store.
Then throw in all the regulatory and compliance stuff that businesses need to trust storing their data with you. Add EU regulations and you will end up building data centers in different parts of the world. Then you will want to spin up training to use your custom DSP. And localization packs. Then you will need APIs to pull data in and out as customers will fear lock-in and they'll want you to integrate nicely with some other service. Then you have to figure out how those APIs work with your metalanguage. Then other customers will demand the ability to reskin everything with their corporate logos, custom login screens, support for SMS and two factor auth, support for third party identity providers, scripts to enroll/unenroll users, admins will want scripting platforms to manage all the complexity created by adding the other features, Etc.
>What I’m saying is you can choose to not buy into one of those uber-programmable enterprise platforms and instead (let someone) build fast and user friendly specific software just for your needs.
the problem is not everyone can afford a IT dept with software programmers that can build out custom software.
If IT is not their core most companies seek out software that is already out there with somewhat decent reputation.
edit: at one of my previous job, they have a in-house software that was build with older technology that needs to rebuild. they outsourced it to Capgemini. it started when i join the company and by the time that i was out (4 yrs). they still didn't get it covert. they kick out Capgemini around two years in and hand it to another consulting company and the new consulting company junk out Capgemini's code and start from scratch.
i'll like to know more details on how they botched this project, it always make me curious how they botch it up for 4 years and two million wasted.
> the problem is not everyone can afford (a IT dept with) software programmers that can build out custom software.
Agreed, though isn't this often just a problem at a strategic level? C-level doesn't understand digital transformation, so there is no strategy and no budget, or they think they can just buy it with platforms like Salesforce.
Having custom software built is only getting cheaper because our development tools are getting more and more powerful and managed cloud infrastructure is extremely compelling due to removing most of the ops from devops and being cheap at the same time, so costs could hardly be an argument anymore, right?
But yeah, there's always the risk of hiring a firm that has a quality problem, or uses terrible tools to build software in the first place (which is what I was referring to with the joke in my first comment in this thread).
Enterprise software is a minefield, how can we fix that? :)
I have personally seen two 30+ million projects trashed. Not including the wasted man hours spent internal employees to support the consultants. IT projects have an incredible failure rate.
Salesforce was brought in by many sales teams, initially, because the internal systems were too slow to write and the sales teams could just setup salesforce and get going!
You forgot the other part, to make business in the enterprise it matters more to talk to the right people than what the software actually does, and the large majority of such companies see anything IT related as cost center.
Someone told me way back in time that in the ERP sales process, your two top answers are:
Q: Can your system do X?
A: Yes (doesn't matter what the question is, or that an entire add-on would have to be built that could never be cost justified).
Q: As a company we do things like this, will your system work?
A: Yes, our product works with your process, no matter what it is.
I have observed this to be true. Customers particularly love the second one, so telling someone that they must change their process to work with your super simple un-customizable product can often be a deal-breaker.
I worked in a startup in the B2B space a while back, and it's amazing how much big customers can push you around and demand features. The salesguys would promise something and then a week later we'd have the feature in a special patch build for them. I heard Cisco did the same thing, and by the time they got big they had hundreds of special branches for different groups of customers. It was a mess.
Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.
Yes, it takes special fortitude to fight off the demands of your precious new mega-customer, be they a Cisco or whoever. Sometimes they'll really screw your product up if you let them. (Though sometimes also they'll give you those jewels of requirements that you really needed).
It's a sliding scale. You have to pander to them to some degree - there's no choice. But it takes grit to refuse to e.g. branch your core code or otherwise compromise your architectural integrity.
The problems are when the sales team does not appreciate the downstream costs of just letting this one patch in. And when you're a struggling startup, sometimes they're right and the social proof of the deal (and the revenue) make it a good choice to compromise your principles this once.
And sometimes you just screw your product up by not listening to what customers need, or by assuming that you know it better than them.
For now i refused to do custom branches, instead the product is made more and more configurable. And it's more successful approach so far than trying to maintain a separate version for every customer.
Honestly most businesses think they need a lot of customization because they think they're oh-so-special, but in fact something like 1) would work great for them. I know, I've worked in consulting and built software for companies who would have been better off with an off-the-shelf solution.
Unless there is a product designed for the specific needs of their industry, then the 80% of their needs covered by a generic system still means 20% of their needs are in fact oh-so-special
I once worked on a CMS designed specifically for the print industry by a company that was itself a separate arm of a printing company - and even then we had to have an entire system to write custom estimating engines in Python, because without modelling the exact configuration of machines and processes used in each print shop you couldn't produce a useful estimate for how much jobs would cost.
Love this comment. My company is rebuilding our EHR software right now to make it more customizable among other things. Know any good resources on making the right architectural and product decisions to protect against or prevent this eventual fate?
My general advice is not so much about the software as controlling your corporate appetite for customization. There is just an incredible cost to bespoke customization, while the use cases of it are often things like executives' vanity at getting live dashboards or something else. You can have an in-house team build some forms atop a database, and you can even make that work, but only if you rigidly fight feature creep. If you can't fight the feature creep, might as well go with one of the big solutions so that features are reflected in bottom line costs and have to explicitly be paid for out of your business budget, rather than implemented by making requests of your in-house dev team.
This, also if you want a good piece of software to fit your needs the current process must be well documented and reviewed many times.
I am currently working on a large project, which unfortunately needs to communicate with DB2 and interact with AS400 (old ERP system). At this point nobody knows how things work and how the business operates exactly. Managers hold pieces of information but it is not documented at all. I have hit many road blocks because one thing was said, which turned out not to be true after a bit of investigation.
I could develop this software in 3 months, but it is taking 1+ years due to lack of documentation, developers not being on the same page, and nobody understanding the current systems.
Yes. Hire an architect with a proven track record and significant experience and give them the responsibility. Reading a few medium articles or an O’Reily book won’t be a substitute.
no, they just do it horribly - there is no reason to tank perf. it's a system built by consultants, for consultants - aka the people that don't know how to actually do it.
Maybe none? I think Netsuite is particularly slow though. Luckily I only have to use it for timesheets but even for that it should have its own job number for the time wasted waiting for it to load.
Once an enterprise reaches a certain level of scale that amount of complexity is almost unavoidable. Tools like Salesforce and JIRA are great for providing the needed flexibility within guard rails and a shared vernacular.
I am going through this right now in a project. A lot of configurations break the database model and can't be really modeled by the database so you end up doing a lot in code which is way slower. Seems we need a type of database that can support these super-flexible customizable data models better. Maybe something where the data model and stored procedures written in a language like C#, Java or JS are understood by the database and optimized.
You're not the intended user of Salesforce. The UIs and flows you use are mostly data entry funnels for the true user: management and executives. You didn't pay for the software; they did. "End-user" satisfaction is low on the product feature list.
Every time your client slows down, somewhere an executive was promoted.
I’m not sure I understand your point? My understanding is the intended users of Salesforce are most certainly the sales team.
And I say this out of experience with using it as part of a sales team at a car dealership I worked at years ago. Every sales person in the company was expected to log all the customers they interacted with, track phone numbers & other info, set reminders to makes sales calls, make notes of what you talked about in said sales calls, et cetera, et cetera. And management was adamant that we did these things.
And for good reason. Sales is a very data driven industry, so to your point yes, it’s great for upper management to be able to track & aggregate all of the data company wide.
It’s been too long since I used it for me to really remember or comment on the performance of the software. But if it’s as bad as the OP is saying that’s a real problem. If you have a whole sales team using this, and performance issues are constantly slowing them down and wasting time, that’s something that should seriously be addressed.
I guess you’re saying though that they just don’t care if the sales team experience sucks? As long as management gets their data?
Haha
My experience has been bit different with medium size companies. Small companies just dont buy any custom-developed software. Medium-sized have the money to pay for custom development, but not for buying SAP. And the executives are extremely sensitive to the effect of the software on work efficiency - basically this is what they pay for, the software is supposed to make employees more effective so they can avoid hiring more people. If the application gets slow and can't keep up with the business then they need to move more people to handle the slow task and the app developers get grilled.
On the other hand, in large companies, management quite often ignores it, they can just hire more people and thus grow their kingdoms.
I made a similar observation while working at a Fortune 500 company that used Salesforce. Decisions about the company's Salesforce implementation were clearly made by people who didn't care too much about data entry UX. The problem was that they did care greatly about data entry -- and data entry, at least in part due to being needlessly cumbersome, tended to fall far short of expectations.
Yeah, I’m definitely not convinced there are configurations of salesforce that aren’t terrible. Other products that are often configured terribly I’ve generally seen an example or two of one that actually was better, but I’ve never seen a salesforce that wasn’t slow as molasses.
The typical JS heap is above 90MB out of the box. Locker service is the main culprit for that, and Locker Service does cause some slowdown. Server-side, they are multitenant and the tenants you are sharing compute with are frequently running massive data operations on a regular basis. Those tenants have no incentive to get things running faster because they don't pay for compute hours. As long as the operations run within Salesforce's governor limits, who cares?
Salesforce's response to the client-side half of the problem is migrating from Aura to Lightning Web Components. LWC is statically analyzable and Aura is not, so they can get some optimizations in that way. On the flip-side, LWC is a piss-poor framework because of how they've stunted it for optimization's sake.
Half of the beauty of Salesforce as a developer is the fact that I can build in a month what would typically take a standard web dev team a year to piece together. That's only true so long as my team works in Aura with all of the scaffolding tools and libraries we've built over the years.
Let's hope it's not something laughably simple as adding indexes to their tables! I mean, that's like something I'd forget and I don't even play a DBA on TV
Couldn't agree more! I'd like to add to that the terrible UX. In fact, Salesforce is so terrible that there are dozens of businesses built around just configuring it for you.
It's slow and the UI is stuck in 1999 unless you pay extra for what they sell as the more modern UI, which takes you from 20+ years behind to only like 5 years outdated.
Lighting is free. The only time you have to pay more is to get custom pieces of your system built in classic rebuilt. In what ways are lightning's UI "5 years outdated?"
This is a good article and history is Salesforce. Another shorter developer focused perspective: Salesforce is a relational database editor. You can create tables, columns, and relationships, app in a nice UI without writing code. You get automatic views and edit forms for records in the tables. And the whole thing is built on a platform where you can write custom sandboxed code to manipulate those records, or expose them over APIs to external systems.
The platform is both powerful and pretty clunky. Salesforce development is consistently 20 years behind established best practices. Learning Salesforce means learning the thousands of limitations and broken parts of the ecosystem. And it’s non transferable knowledge.
I want to add. Not 100% non transferrable. I was able to deliver a project on Service Now without any Service Now training, using my Salesforce architecture background.
Pre-pandemic, Dreamforce--which is basically Salesforce's user and partner show was one of the largest trade shows in the tech industry. I think they were up to about 120,000 attendees or something like that because a huge amount of work goes into customizing Salesforce for a specific business.
"...From December 2 to December 6, we expect more than 60,000 attendees will spread out across six venues on the Las Vegas Strip, promising to make re:Invent 2019 the biggest re:Invent yet..." AWS re:Invent 2019
"...Well, here we are: a little over a week after Salesforce’s 17th Dreamforce. As a lush green forest burgeoned in downtown San Francisco, over 171,000 people from 120+ countries around the globe came together to have the time of their lives with fellow Trailblazers, learn how to help their customers succeed, and promote equality, sustainability, and trust — in short, to transform their businesses and the world we share..." https://www.salesforce.com/blog/dreamforce-2019-infographic/
A lot of the value is the access control part of that. You can set up a role hierarchy and/or groups and only see the records you're supposed to have access to when you query. Plus configuration of what fields different user types have access to.
The downside of that is it means every query, no matter how simple, is a join against multiple internal tables to enforce those rules.
I’ll sprinkle that Salesforce employees have a huge pledge not to break your software as they update it 3 times a year.
On flip side, meticulous saving of cpu and memory means your solutions are super constrained. You need to do all sort of tricks like 90s game programmer and still can run yourself into corner on larger systems. Back end is supremely unevolved - their serverless functions have been in beta forever and apex is like 20 years old Java.
I got my start doing Lotus/Domino development and it was a surprisingly powerful system. We developed all kinds of internal workflow and document management tools that ran basically the entire company. The document store 'database' model it used reminds me very of the NoSQL movement that came over a decade later. One pretty amazing thing at the time (mid-late 90s) was that you also got usable web interface to all your tools almost 'for free' (which is what half the people used). When combined with Lotus 123 it would spit out very nice reports and graphs with only a few lines of code. In many ways it was way ahead of its time and it took years for most other tools to catch up.
One thing we never used Lotus for though was mail, calendar or contacts.
One place I worked at had something similar as well, it's just that all my memories are of using it for mail, calendar and contacts. And the stupid log-in dialog!
You can. Airtable is what salesforce would look like if it were built today. Because CRM is so dominated by salesforce though, Airtable's defaults are not CRM and it doesn't market itself as such.
That's already happening, and it's causing further fragmentation, so now companies are investing in "IPaaS" tools to merge their data. Which creates even more non-transferable knowledge. It seems customer and marketing data is a mess because marketers will invest in every shiny new tool that promises "actionable insights" from a mountain of data. As terrible as Salesforce may be, it's not as bad as Salesforce + Segment + Informatica + Looker + Lotame + etc.... But that's the world digital advertising has created. Anything for an extra click.
Each extra tool provides a date for a date when marketing will be useful. As a pm I was told that we couldn’t advertise because our marketing integration wasn’t done.
A CMO can go from shop to shop delivering nothing but broken ad tech integrations with the job of fixing the mess from the last person.
in my experience, every vendor we looked at who competes with salesforce is not interested in your business unless they are allowed to take over your entire backoffice. for example, we only wanted it for the CRM and order ingestion via manual entry & API, and that was okay, while other vendors insisted on also taking over our inventory management, invoicing, fulfillment, etc, rather than allowing us to simply integrate with the minimal set of APIs which we needed to sync our systems with theirs.
Give Hubspot a gander. We want to handle your entire front office. But we're also perfectly content just handling customer data and gdpr requests for you.
I will say that I feel better about our clients underusing a $2500/quarter HubSpot account than I do about our clients wasting $100k+ on Salesforce Pardot.
Well I was specifically responding to someone who couldn't find a salesforce replacement because they all wanted to manage the back office. So it seemed relevant rather than shilling in my eyes.
probably pipedrive. it's pretty good for small sales (and some marketing) groups to manage their pipelines. easy to get up and running and fairly flexible for what it is. it's not going to replace salesforce though.
hubspot is a mid-market marketing automation product, sitting between little pipedrive and huge salesforce. it's also pretty decent for what it is, helping medium-size marketing (and some sales) departments coordinate across various channels. it also won't replace salesforce, but is appropriate for a mid-tier company (maybe ~$20-200MM in revenue).
salesforce is a huge sales channel management platform with at least a couple marketing automation products bolted onto it, along with all sorts of other semi-related stuff, like SCM (supply chain mgmt). this is because they want to own the totality of "marketing", which encompasses all of product, price, promotion, and distribution.
(i've done some consulting in this area and have helped clients pick and set up these things)
I would love to have a chat with you - my company is in the middle of trying to decide on what route to go right now. We’re on Zoho right now and trying to make it work. Available for a chat?
I was pretty sure Firebase was in a position to kill Salesforce’s platform, but I guess they never sold it as business platform (plus Google wood never be able to execute human Sales and Support at Salesforce scale)
MS Access was far more pleasant to use. I haven't used it in years and I still haven't seen anything that will give you a relational database and front end with as little effort.
You would likely get something faster and nicer to use too, but you can’t just do it once ... you need to keep moving because otherwise the team shrinks and you lose the expertise to make even smaller changes. That stagnation is what kills a lot of custom systems.
No. I had to integrate a Django based booking system with Saleforce. Django is a pleasure to use as a developer (once you understand it). Salesforce is absolutely terrible, clunky API and just a horrendous developer experience.
Salesforce is amazing, in the sense that it truly lives up to its name. Everytime I've been hired into an executive role I've cancelled our Salesforce subscription and productivity has gone up.
Its clunky, slow and overly complex if you ask me. But their success cannot be denied, thus they must have an amazing salesforce.
Come in, shake things up by changing a big system to put their stamp on things, (no telling if productivity would’ve gone up if nothing had happened, e.g. company was already growing), then bounce to the next executive gig before the honeymoon wears off.
Check out this reply to my other comment asking for their background as an executive.
> [I’ve been an executive] 2 times. First I left because of a disagreement on strategy after 2 years. The second I left because of mismanagement at the highest levels.
I’ve looked like an ass before, but I think I did OK w/ my original comment.
I heard moving into a new home and then immediately burning it down to camp in the back yard is great for the maximizing your Daily Steps KPI also. This conversation of "what I did":"what the outcome was":"what the goal was":"what the organization needs to win" seems a bit imprecise.
In my case, the upstream ERP was there for historical reasons and literally wasn’t used beyond a few reports. The old system wasn’t modified with the business as it grew.
I'd love a longer answer. You seem to be happy to give quips and tidbits, but no substance in your answers.
Great, you've replaced your CRM with Office365 spreadsheet and a documented process in a wiki. Your spreadsheet has history, so audit logs are captured and you can backup. You have a documented and adhered to process for altering data in the spreadsheet.
But depending on your use-case, Salesforce may never have been a good fit. If you're following processes that can actually be adhered to by reading a document to manage your business - your business is extremely mature, well defined and unchanging, has no bad actors (because hitting "Download" on the top-right literally exports all of the company private data) with little compliance requirements, and doesn't require international or external integration, and will never experience unprecedented growth.
If these assumptions are wrong, please share some detail because I'd love to hear about the workflow in your organisation.
Like most highly successful enterprise software companies, their focus has definitely shifted to sales. They have the budget to fly executives around in their corporate jet and take them golfing and schmooze while using all the big talking points like "compliance". It's hard for superior, cheaper, but smaller products to compete because they have reached that "nobody ever got fired for choosing salesforce" stage.
Feel free to explain it, because you’re clearly posting on a site with a mostly American audience. So the way you’ve portrayed yourself as an executive shaking things up and canceling SalesForce contracts is getting less and less accurate with each comment that follows.
I worked with Real Estate Agency (<20 employees) and they were looking into CRMs. After trying out half a dozen CRMs they ended up commissioning a custom one. There is no single CRM out there that is designed for you.
Most CRMs (and especially Salesforce) have seen every business model under the sun and are customizable to fit any business process that you can write an ERD for (i.e. literally anything).
Oftentimes when people think they need a completely custom solution, it's because they're getting caught up on the default naming conventions and/or default sales processes (which are customizable in basically every mainstream CRM).
I would agree that no CRM is designed specifically for anyone -- that's the whole reason why any of the remotely good ones are built with configurability and customization in mind. The out-of-box-experience with most CRMs is always a traditional "product sales" paradigm, simply because that's the most common. You can definitely customize it to work with other types of models though.
I've used Salesforce at every company I've worked at for the last 8 years. Here are my observations:
- There is a special place in hell for the person who made the decision to have leads and contacts as separate objects. It creates all kinds of complexity. Some may have a need to work with leads but for clean reporting, you almost have to dump leads. Most B2B companies I know don't use the lead object and autoconvert everything to Contacts. But it has always seemed like a bad decision to have both.
- There is a long line of companies that have tried and are trying to disrupt Salesforce - none have succeed and my take is that this is because of the ecosystem and app exchange. That makes it very challenging to overcome.
- Salesforce has made improvements in their interface (Lightning is, by most counts, an improvement), but an entire industries exists to make up for the shortcomings of Salesforce. Sending emails directly or programmatically is pain, so we have Outreach and Salesloft. Entering data is too slow - so there's Dooly. Their marketing reporting stinks - so there is Fullcircle and Bizible. They own Pardot, yet somehow still can't top Marketo, Hubspot or Eloqua - which is a pretty amazing fail imho. And the Pardot integration really doesn't add a ton of value over other solutions. But as noted above, this weakness is also a strength because you've got a huge ecosystem.
If I'm starting a company right now, I'd probably go with Hubspot because there is just enormous power in the simplicity of having all of the data for both marketing and sales in a single system. Not that Hubspot doesn't have it's own issues, but reporting has always been a huge problem at every company so if I can't avoid this pain even a little, I'd consider it a big win.
The intended difference between contact and lead is that a contact is someone who you have some sort of a business relationship with -- either you are trying to sell them something, you are working with them, or have worked with them in the past. Leads are supposed to be wholly separate from that -- they might be a person, they might be a company, they might just be a rumor.
They way leads is originally intended to be used, is that you'd dump a bunch of garbage into that table -- b2c data from web forms, incomplete records, mass-imported lists from affiliates/events/etc -- and then it would be the job of sales to sort through it to find the records that are of any value. You wouldn't turn them into a contact until it was determined that there was an opportunity to sell them something.
But, leads as a concept really don't make sense in some industries. In many b2b industries, by the time you interact with anyone at a company, it's already well determined who you are and what product you're interested in. This is properly entered as a contact/opportunity.
Agree. I've built CRM's for multiple industries now, starting prior to any interaction with salesforce.
There are many reasons to keep leads out of contacts, messy imports and the unstructured nature of what a "lead" can be are big ones, traceability, unauthenticated data capture issues and ease in reporting are a few others.
It's always less of a kludge to have a system that keeps them separate but lets you seamlessly convert or associate a lead object into a contact object, when it makes sense (for lead objects that have sufficient similarity to a contact), and has an option to bypass the lead table and create a contact directly.
In my experience trying to shoe horn into a _contact only_ abstraction creates more problems because the abstraction is too simplistic or even flat incorrect for many businesses.
edit: From a sales agent "user" perspective you do often want to hide these abstractions from the UI depending on the industry and/or lead type, too many systems force their users into unnecessary duplication of effort.
Oh I get it. But as I said in another response below, what you're describing is the stage of a contact, not separate objects (in my opinion). You could just as easily have a single object but where the status was "lead" (no company name needed) and "contact" where you add the company information and the ability to add them to an opportunity.
You’re right, it could be done that way, but for the orgs that do use leads, it would mean a lot of repetitive filtering on pretty much every business process. The difference in functional concept between a lead and a contact are great enough that processes (both software and human) between the two rarely overlap. A foreign key does all of this for free. For this reason, I think they made the right choice, especially since the orgs that do not like the concept of leads can just simply not use them.
Whether Salesforce intended it or not, the platform has moved far beyond just Sales. In the multitude of cloud products currently available, almost all of them use the Contact object as something other than a lead. So I guess from my point of view, a Lead can always be a Contact that is captured/not, but a Contact may not necessarily be a "lead", in the traditional sense of word anyways.
Given that Salesforce is the only CRM I know in my fairly young career, I can definitely see many of its shortcomings and do not envy the engineers/product managers that have to address those.
I think if someone is starting a company, Salesforce is not the right option, both because it is extremely expensive, and its not exactly plug and play if you're looking for customizations.
And that is totally valid, but I’m guessing there were some architectural decisions behind splitting it into its own object in order to give it support from other customizations and processes. But in this case it would be impossible to make everyone happy =/
Salesforce owns Marketo now. My company is using it along with our Salesforce org. Integration is pretty seamless. Although we do have to train users on how to write in Microsoft SQL Server 2016 which is what Marketo is using apparently.
I really enjoy these articles. I don't know a ton about Retool, but I know these articles are often written by or in the style of their Growth analyst, Justin Gage (https://randomshit.dev/) who seems to be fantastic at writing articles about what these are and how they work in his own right.
These types of posts are a refreshing change from what company blogs have become (or maybe always were?): garbage vendor content pushing their agenda.
I understand how Retool could be used to do some really cool stuff on top of Salesforce, but this post is also just an informative expose of an industry giant.
Justin recently did another one about Accenture, whom I worked for a while back, and really appreciate the story that is being told.
Kudos for these fantastic posts. I look forward to reading these every time i see reool.com pop up.
Salesforce is a master work of lock-in-as-a-product (LIAAP). The best part is that it’s not even a good or original product. It’s success lies in the company’s ability to sell a mega package of trivial CRM systems to non-technical sales people. It may eventually wear thin but it’s target demographic is spectacularly niche and self-consuming that there’s little need to disrupt it.
And while sales people tell other sales people they need Salesforce in order to not maintain a software stack of their own. Those same other sales people turn around and tell developers to maintain integration with the Salesforce APIs.
I'm a pretty new Salesforce admin, and so far it has been a horrible experience. Apart from its horribly sluggish user experience, developing for it as also very frustrating.
You can't restore backups! You can export your data, but there's no way to import it, because you can't set the object Id or autonumbered fields (like the case number, which gets communicated to the customer). They used to provide an extremely expensive recovery service, but they stopped doing that. That's just unbelievable for a business product.
I also can't count how many times I looked up an issue and found an "Ideas" post that's over ten years old, with 10k upvotes and no reaction from Salesforce at all. Id doesn't seem like they work on the core product anymore, they just release new things that you need a license for.
> You can't restore backups! You can export your data, but there's no way to import it, because you can't set the object Id or autonumbered fields
Have you tried marking fields for user set IDs as external IDs. This field can then be used while doing upsert. But what do you mean by there is no way to import it? Apart from Dataloader there are a host of companies that offer this feature.
Suppose a bad actor has gotten full access to our Salesforce, deleted everything and emptied out the recycling bin. We need to restore everything.
Luckily, we used the weekly export feature and have all our data, we only need to get it back into Salesforce. But how do we do that?
- Dataloader can only restore one object at a time. We have 350 different objects.
- We need to restore the relationships between objects. They are saved by Id, but we can't keep the original Id. So we have to keep track of the original Id and the new Id for each inserted record, and replace them in every other object. That also means we have to insert the objects in topological order. If there are any cycles or self-relationships (like Account.ParentAccount), we have to fill in the Field with NULL first and update it later.
- Even after all this effort, we still can't recreate the values for autonumbered fields. If it's a custom field, we can change the type to text, insert the values and change it back. For standard fields, there is no practical way to do it. No company can help us, because it's just impossible to do using the Salesforce API.
You have to buy a specialized backup product like Ownbackup or Spanner. These in turn, utilize Salesforce's bulk apis. Salesforce does not let anyone touch the underlying databases.
It's baffling that a product like Salesforce relies on paid third party products to deliver an essential feature like restoring backed up data.
And even those can't change autonumbered standard fields, like the case number. That's problematic, because they don't only live in Salesforce but get referenced from outside.
You have to adopt an ERP mindset when working with Salesforce. That is you are trying to satisfy auditors and have a clear permanent record. You do not update key fields like Case Number. Usually you deactivate or soft delete a record. You then repoint the external systems to the new record.
My company had 3 instances at one point after acquisitions. Two of them got merged so we’re stuck with two because of the number of customizations and the different sales approaches / teams between the two divisions.
One of them upgraded to lightning required by some feature. The experience nice with lightning (even slower) has been worse than classic. Meanwhile the other instance is till on classic.
We made the mistake of embedding business logic into sales force and integrated with their API only later to find out it can take upwards of a minute to just convert a lead to a contact via API depending on the current load on the system.
I have been working on the Salesforce platform for about 3 years now, and it has been a pretty enlightening experience(good and bad). It has certainly been lucrative as well. I would say that a lot of the issues around Salesforce stem from how easy it is to write or configure a terrible solution. Something that looks like it works but is so far from any sort of optimization.
Much of Salesforce implementation development also goes unvetted by the client. I have worked and currently work on projects where I constantly ask 'how did this ever make it into production...and how has no one noticed that this is hot garbage for 4 years'. Eventually someone digs deep enough and whoever is managing that project at the time gets the brunt of the blame unfortunately...
Retool recently released “modules”, and it made me think the same thing, that this is one step closer to the thing they’re trying to replace.
Resolving merge conflicts in json (which is what defines a retool app) is another area where the benefits of “yes code” become more obvious. “No code” is not something I’m convinced is good. I personally think embracing code (but making it optional) leads to a platform more developers would enjoy
To pick on salesforce a bit, notice how the example of how to define the drop down they are using XML. That’s not “no code”, it’s just a constrained form of coding. Basically any library or framework that embraces code can also offer higher level abstractions just like Retool or Salesforce, without having to have the “no code” part to solve the problem. “No code” is also tangential to being a saas product, these tools could work more like codesandbox than dreamweaver or frontpage, for example.
But was one supposed to write that code in the example oneself? I thought it showed code generated by this venerated "no-code" tool... If that's not the case, then the whole "no-code" moniker is marketing BS.
Salesforce is a full business app development platform with almost unmatched flexibility, fully hosted and programmable. CRM doesn’t really begin to cover it.
This reads like I’m a zealot. I’m not. But there is nothing that I’ve seen that can do what it can do and, if you know how it works, you can leverage it for incredible time and efficiency savings for developing and deploying business apps.
This is true, if you really know what you’re doing you can make salesforce sing. If you actually understand its breadth and depth Salesforce is a pretty amazing platform.
My company had a lot of data in SAP and also a lot of data in Salesforce (don't ask me how they decided what to put where). Sometimes we need data from one or the other for projects and so far it was always that getting SAP data was extremely tedious to impossible while getting Salesforce data is usually pretty straightforward. I am not sure if that's caused by the teams that manage the systems but it's definitely very notiecable.
I'm just waiting for Salesforce to be disrupted. It has become so large and all encompassing that it is hard to get into for the lower end. Seems like a ripe area for a low end competitor but I haven't seen anything great yet.
Not because it’s hard to make a better product, many already exist. But because it’s engrained into the DNA that makes up an enterprise. At some point you just buy Salesforce. Not because you need it, or even because you want it. It just manifests itself. You don’t get fired for buying Salesforce.
Having evaluated dozens of CRMs to replace my company's internally built system, here's my five cents:
- Salesforce is slow, expensive after adding add-ons, costly to customize, and visually unappealing. The older and less tech-friendly workers I've surveyed found it painful to use. The same might be said of many Salesforce competitors, including MSFT Dynamics and Netsuite. SugarCRM also has many of the same failings, but its UI/UX is better IMHO.
- Close.io, Pipedrive, Salesloft, Nethunt, Nutshell, Nimble and few others have a simpler and more engaging take on CRM that seems to be easier for a wider variety of users to adopt.
- A big chunk of CRM's perceived value is better found through sales training that focuses on qualifying customers and good work habits.
- CRM cannot turn most under or non-performing salespeople into performers.
- Many performing workers will resist adding contacts and data to a CRM for several reasons, self-preservation instinct being most prominent.
- Nurture marketing, once a CRM innovation, has become an annoyance for client/customer prospects... particularly over email.
- Predictive CRM requires either a lot of data to train, or hard to obtain signals. The concept underachieves.
The next great thing may very well be inversion of CRM, whereby your customers/clients automate the acquisition, evaluation, negotiation and purchase of products or services. At the enterprise level this exists for commodity products & services, but it's largely non-existent at the SMB/SOHO level. The normalization and quantification problem is significant, but I'm confident ML will address some of these challenges in due time.
Tl;dr ... there's still no substitute for hiring the right people. Charisma, emotional intelligence & motivation always surpasses sales automation.
Act! back in the 90's right around the time Symantec bought them. Seemed to be just about perfect for what most small businesses would need. Out of nostalgia I did some searching and the amount of times it changed hands and what they are charging (per month!) for it now I can only imagine - it's probably as heavyweight or more so than SalesForce.
Salesforce just has a weird flow. I think I have the gist of it, but man do you have to use it for quite a while before it starts to make sense - all while you wait and wait and wait for anything to happen after you submit something. Ugh.
The most interesting thing in this post was that Mark worked for Apple in 1984 and stayed in good terms with Jobs long enough so that he was still Benioff’s mentor in the 2000s before Jobs died
Marc Benioff's book Trailblazer goes into that story a bit more. The rest of the book is pretty good too.
This thread seems dedicated to picking Salesforce apart from the technical side but you should really look at it from the business value side and as an ecosytem.
Salesforce has certainly defined digital transformation for a lot of companies.
Anyone that wants to beat Salesforce is going to have to be 10x better or come in from a new or niche angle.
No code, slack/chat interfaces and AI assistants seem to be viable paths.
It’s amazing content in an otherwise opaque category of enterprise software and services, which are so strongly embedded in part because no one knows what they do and how they’re used in practice.
Salesforce is uniquely amazing in that its development and extension environment is extremely close to the dreams of Smalltalk developers and the like. Loads of extensibility and introspection possible on basically every view of your system.
Yeah it’s slow but honestly you’re spending most of your time looking at the data and writing it up, the slowness doesn’t matter that much in the long run imo.
"So he gave Salesforce simple subscription pricing that scaled according to usage. In 1999, it was $50/user per month. Software-as-a-service (SaaS) was born."
I would say that the Bloomberg terminal was an earlier example of a SaaS.
Where I work, we are planning to ditch our very expensive web portals and mobile apps to go all-in with Salesforce. We plan to build several Salesforce lightning communities to be used as our front-end portals. Salesforce will convert these communities to mobile apps as part of our contract. Along with the base Salesforce org, we have Marketo (marketing), Service Cloud (customer support), Financial Force (ERP), Tableau (BI), Tableau CRM/Einstein Analytics (analytics), B2B, and Mulesoft. The only products I question are Financial Force, B2B, and Mulesoft as they are very expensive for what you get.
It's incredibly powerful software that when implemented well, can streamline processes, provide easy access to information, and make teams really efficient.
Lotus notes was single process bound. I worked at a company that I believe is still using it today, really sucked when you started a search in one tab and then the whole program became unresponsive until it completed the search.
I've done quite a bit of Salesforce development in my career. First as a full-time employee at the start of my career, and later on as part-time side gigs. There are a lot of negative comments here about Salesforce, and they are mostly all valid. Salesforce is not the least bit sexy, and can often be frustrating for both developers and users. There are a couple of good things about it that I wanted to share though:
* A single developer can be incredibly productive at automating a company's business processes. Fresh out of college at my first job I was the only developer supporting hundreds of daily users across our sales, customer support, operations, and finance departments - most of whom were basically working out of Salesforce full-time. Salesforce also proved really adaptable for supporting all of the crazy sales campaigns or operations initiatives that management could dream up - often with quick turnaround times. For me there is no question that the Saleforce licensing costs (or some other low-code alternative) are worthwhile for most businesses vs. trying to build internal systems from scratch.
* Developers are in high demand, and I have received lots of requests from former colleagues looking for a Salesforce developer - even a decade after I moved away from full-time Salesforce development. When I have accepted these offers I've literally been told I can charge however much I want (although I do tend to keep it reasonable).
* You tend to have much more direct contact with your users than in other B2B or B2C development roles. And users are often super-appreciative of even simple changes. It really is a great feeling to see the difference that your work makes firsthand, and I have had some great working relationships with sales and support managers over the years.
* The core Salesforce platform (forms and data modeling, workflow, API integration, etc.) is actually an incredible piece of product design and engineering in my opinion. I know it's getting long in the tooth these days, but the team that built all of that deserves credit for getting so much of it right. All the stuff that Salesforce has built or acquired since then, unfortunately, has been much less impressive.
* Salesforce is expensive for sure, but not as bad as the pricing on their website would suggest. Apparently nobody pays the list price for Salesforce licenses, and a 50% discount from the list prices is not uncommon in my experience.
Ultimately I am glad I decided to get out of Salesforce development if only because the developer experience with almost any other programming language is just so much nicer. But I learned a lot from the experience - and I think those early interactions with users and firsthand experience of how business are run have made me a more well-rounded developer. I was also able to use the skills that I learned while doing Salesforce development to transition into a role building web applications, and pursue a more traditional development career.
And now as I am eyeing retirement, I am contemplating getting back into Salesforce consulting on a part-time basis.
As someone who has spent the past several months using Trailhead to learn Salesforce - even picking up some badges for things that seem practical this thread is making me reconsider my choices.
Have I wasted my time in learning Salesforce?
I know that there is what is effectively a cult following of Salesforce evangelists but I was hoping this would be valuable in the long term.
I think Wikipedia has a list. Perhaps not just of FOSS CRM, but usually their lists of software have a License column; with a bit of luck you can sort the table on it. Otherwise, copy-paste it into a spreadsheet and sort it there.
Build your own custom and in house CRM that you know from top to bottom, which does precisely what your company needs. And keep it closed in your private network.
The site has a CSS issue that prevents the "Retool" logo to be clicked on mobile. If someone from Retool reads this, it's related to ".site-header::after" having an absolute positionning AFAICT.
"Salesforce’s point-and-click database editor and drag-and-drop UI builder alone make it much more than a CRM. But when you bolt on other apps and 3rd-party APIs, it gets close to programming without code: a new way to build software."
Seems analogous to Wordpress for building websites, without actually knowing how to build websites, yes/no?
Absolutely, it's not a perfect analogy but it's a surprisingly good one.
The value is in the sheer size of the ecosystem and the idea of everything being plug and play, even if the reality often necessitates actual code when you get past the happy demo path to your business's weird edge cases.
Nothing against Salesforce but please don't call it a software company. They are not a software company but rather an investor. They invest and acquire other companies. The majority of their revenues still come from their investments rather than their products. To their credit they have been doing some great investments over the years, but they have no capabilities of building anything themselves.
Now, I know all tech companies buy other companies. That's not new. But most tech companies also have some capabilities to innovate and building new stuff. That's an important difference. Buying a small tech company to accelerate development of a particular product is different than buying a company like Slack which already dominates the market and can be integrated into the eco system and then transition to mostly maintenance.
Salesforce do tend to buy a company and then brand that company's products as part of Salesforce. The result is a mess. Want the same data in your marketing cloud than your core? Nope, it's a different database and data model and true syncing of data can be a nightmare. What you're left with is the same as if you'd bought products from 5 different companies and built an integration layer to tie them together. Funnily enough, Salesforce has had to build an data integration platform to help untangle its mess of acquisitions and of course the customer has to pay extra to use it.
Why can't they be both? They literally are a software company. And yes, they acquire other software companies.
Plenty of companies in other industries (e.g. consumer goods) are conglomerates, often a result of acquisitions - it doesn't make them pure "investors."
@jjeaff Of course they do development. They have software engineers and buy real software companies with software engineers. Someone needs to maintain all the software they keep integrating into their eco-system (some products which they acquire remain independent). But their business model is to expand by buying or investing in other companies. They don't invest in building new stuff in house. Partly because they don't really have the capabilities to build something like Slack for example that would dominate the market.
As a former employee (and not one acqui-hired) I don't know how you could say they're not a "software company", but I did say something similar during my time that I still stand by which is they're not really a "tech company" in the way Facebook/Microsoft/Amazon/Google/Apple are. They do have a few thousands of in-house devs working on "core" products, and lots of other devs from various large acquisitions (e.g. Heroku) mostly separated from that, there's a good deal of tech and some smart engineers, but I'd still call them a marketing or sales company instead. This distinction is mostly only relevant to programmers in that it describes and predicts an internal mindset for how problems are approached and how budgets are allocated. It's hard to describe without examples I don't really want to get in to, but as an illustration you could make an axis with one end being clearly a tech company like Facebook and the other being not a tech company like Walmart (despite Walmart having some impressive tech/smart engineers). Salesforce sits quite a bit further away from the tech end than people think.
