B2B (Business-to-Business) software is different from B2C (Business-to-Consumer) software for several reasons, but the most important one is this: In B2B, each customer isn’t an individual but a company with its own unique needs and workflows. If your software isn’t compatible with the way a company operates and there are no convenient workarounds, you risk losing their business, which brings me to the first important aspect of B2B software…
Customizations
In the B2B software world, your software may solve every problem a company has, but it may still end up coming short because it doesn’t solve those problems just the way they need. As a result, both prospective and current customers often request changes to the software. The most common requests we encounter as a maker of carbon accounting and energy management platforms include:
- Custom dashboards
- Custom reports
- Custom fields or options when entering data
- Custom notifications
- Custom logos and wording
Having a built-in ability to create modular, preferably drag and drop dashboards is an important asset in meeting custom dashboard requests. Custom reports are equally important, and it’s often possible to arrive at a common reporting format, which may benefit more than one customer.
If you haven’t designed your B2B software with customization in mind, you will likely have a lot of problems down the line with your software looking like the car designed by Homer Simpson with seemingly unrelated features sticking out like a sore thumb.
Custom car design by none other than Homer Simpson. Image by Electronic Arts
In order to be a product company, not a consultancy, you should avoid one-off custom features as much as possible and focus on features that can be customized instead. It’s a tight rope to walk on – features that support customization introduce complexity, and that may not only make your software harder to use for the end users, but also make it harder to maintain for you. One-off features, on the other hand, can easily turn out to be a maintenance nightmare because they are specific to one customer only, are not usually tested as well as the core software features, and are easier to break after software upgrades.
Integrations
After customizations, integrating with company systems comes up as a common customer requirement, and the most requested integration is probably SSO (Single Sign-On). If a large number of employees are going to use your software, Active Directory integration (usually via LDAP) is the most popular SSO request. It’s a relatively easy integration to do, isn’t unique to a single customer, and saves you from dealing with support requests about user account issues like forgotten passwords.
There are basically two types of integrations from a technical point of view – integrations using your software’s API (Application Programming Interface) and integrations using everything else. The former is the ideal one because you have the most control and usually the least amount of additional work to do other than documenting your API well, but it requires the company to have their own software developers or contractors to do the integration.
Other integrations may require connecting to company systems by using APIs (SOAP used to be common, but REST APIs using JSON is getting popular for data exchange) and reading and parsing files (usually CSV) on an FTP site, which in this day and age is still popular. You may also push data to other software products such as internal company dashboards. Integrations that depend on internal company systems tend to be more fragile due to the increased number of dependencies and may occasionally break for reasons as simple as the company IT department’s decision to change the address of an internal API service without telling you.
These days B2B cloud software is quite common, but some customers may still request on-premise installations of your software due to regulations or their 3rd party software policies. While on-premise installations are not really integrations per se, they still require you to adhere to the internal software deployment and testing procedures of a company, and can turn out to be gargantuan tasks in some cases, so beware.
Backward Compatibility
Unlike many B2C software where “fickle” users can switch from one software to another on a whim, switching from B2B software can be quite challenging especially when there are significant switching and training costs are involved. When your software is customized to the needs of a company, has several integrations with that company’s proprietary systems, and after who knows how many meetings that spanned months or even years to arrive at this successful outcome, there has to be a really good reason for a company’s decision makers to switch to another software provider and go through the whole process all over again.
With B2C software you are allowed to move fast and break things especially in the beginning. In B2B software, however, backward compatibility is important. Your software doesn’t sit in isolation – it’s connected to other systems, and a lot of people depend on your software to do their jobs. Just like it’s hard for a company to switch to another provider, it’s also hard to make major changes to existing B2B software with a large user base. And there lies the dilemma – how to change or improve functionality without making potentially breaking changes and requiring extensive training. At the end of the day, if some things need to change in your software, it all depends on whether the new features/improvements are worth the trouble for the customer. At large companies it’s not uncommon to come across software with user interfaces that look like they were designed 20 years ago, and you can probably guess why.
In my opinion, over time the relationship of B2B software providers with their customers starts to resemble a marriage for lack of a better word, especially the software in question is vital to the customers’ operations. A well designed B2B software attuned to each customer’s specific needs may not win any user interface design awards, but it gets the job done, and that’s what really counts in the end.
Related: