[AnimalMuppet]

To add to point 1: Let's say the customer is a bank. They cannot lose track of even one penny, or they're in regulatory trouble. Your software had better be up to that level of not losing data.

Similar to your points 2 and 3, I would say "customizability". Customer A wants different things than customer B, because A has a different set of other systems it has to integrate with, and a different set of procedures built around those systems, and lives in a different regulatory environment, so they have different reporting requirements...

I would add one other point: Scalability. Enterprise software can't depend on any one computer being up, or any one data link. It needs to be able to cluster, and failover, and replicate data between clusters. It also needs to be able to handle large amounts of throughput, and enormous data tables, and so on.

[greenyoda]

Both of the above comments are great answers from the technical point of view, but I'd like to add one more thing: customer service. When people pay a lot of money for enterprise software, they expect to be able to get competent and timely help for their questions and problems. A startup that sells products or services to businesses might need to learn something about customer service if they want to be able to compete with established players in their field.

[mattbrewsbytes]

Customer service is important especially for tech support. However with some enterprise software, like ERP systems, you achieve the Vendor Lock-In trophy pretty quickly after implementation so you may find this to be something a startup can be very disruptive about: responsive and helpful customer support.

A typical scenario may play out where you have to put a ticket in, wait for a rep to contact you and they ask basic info, log files, etc. then it gets handed off at shift change to another rep, then you need to escalate to a manager who actually knows stuff and can solve your problem quickly.

Not all vendors are like this though. If it is software you have built - a good policy would be to have the software committers rotate into tech support shifts regularly. Can you imagine the joy a frustrated IT admin would have if the customer support person has the right answers quickly? Or utters the phrase "yeah, I helped write that module, let me look at your log files and we'll get to the bottom of this".