Low-code tools give Autodesk sales and service staff a business advantage

By Mark Samuels

December 3, 2021

Audio mode

Autodesk is using Salesforce’s low-code tools to build new applications that connect internal teams and share data that can be used to improve customer experiences.

Tzvetana Duffy, Senior Director of Enterprise Engagement Platforms at software specialist Autodesk, says low-code development has helped bring its sales and customer success teams closer together. This new level of collaboration has produced a range of benefits for the IT team and the rest of the business.

While the sales team was already using Salesforce, the customer success team – which is responsible for the adoption of a product once it’s sold – was using another platform. According to Duffy, this best-in-class platform was poorly adopted and expensive, costing north of half a million dollars per year in licences. Duffy’s team knew they needed a different approach, and they were keen for both teams to use Salesforce:

So, what we decided to do is to see how we could bring the sales and success teams together in the same system.

With the help of low-code technology, they created a custom solution in Salesforce Flow that allows sales and customer success staff to see the same information. They used Salesforce App Builder to drag and drop the elements that would be required for the new platform. They also used Salesforce Connect, which allows companies to access and handle data stored in external sources, without leaving the Salesforce environment. Duffy explains:

Having sales and support in a single system has improved collaboration. People can work together. Now, when a customer success employee builds a deck for our customers, the salesperson also has direct access to it. When the salesperson has conversations with clients, the success person can see it. They don't have to go to a different system. That collaboration is a result of the project.

Challenge

The business challenge that the firm originally faced – a lack of collaboration between two internal business teams – wasn't related to low-code technology, but it was solved with low code. By making sure sales and customer success teams could see the same information, cross-business collaboration was improved, says Duffy:

When you look back at our initial challenge, it's like, ‘wow, how could we build something so fast?’ But, of course, we just tailored the solution to our specific needs. Sometimes simple is better.

There were some concerns about how the integrated Salesforce platform would be implemented and adopted across the organisational boundaries of sales and customer success, she admits, but low-code development helped bring both teams together:

We were able to sit with the success reps and design with the Salesforce system by clicking and dragging items and asking them, ‘How do you like it? Is that how you want to see it?’ That was an amazing experience because a business systems analyst was able to do these things sitting with the actual consumer of the product.

Duffy argues that bringing the business into the development process in this way represented a sharp break from the past, where IT developers would sit in isolation and create products without having as much interaction with the people who would end up using the tools. This integrated low-code approach also produced benefits when it came to system adoption:

Low code made the development time much faster, because we don't have to have these handoffs between IT and users. But most importantly, it really helped us boost adoption because the customer success reps knew we could personalise the system in the way they wanted. It felt like they were co-creating it with us.

The project took about four months to complete – without low-code tools, Duffy reckons it could have taken as long as eight. The project, which went live last June, helped reduce the demand on internal staff. Rather than having to rely on developers, they passed many of the system-design elements to user-experience specialists and business analysts.

The business benefits aren’t just related to implementation. Low-code development means the IT team doesn’t have to dedicate so much of its resources to creating new, customized features for customer success staff. Duffy estimates that low-code development will help to reduce the time her team dedicates to long-term system maintenance by as much as 30%:

I really care about not spending too much time on maintenance. I want to build new features. I don't want to maintain old code in the system.

Salesforce

While the low-code features are new to Autodesk, the company has worked with Salesforce for 15 years. The firm is part of the Salesforce advisory board and keeps in touch regarding new features. In a lot of cases, Autodesk pilots these features. Duffy’s team saw the potential of the no-code features and were keen to explore how the technology could create a joined-up approach to sales and client data:

I have about 20-plus SaaS applications that my team manages and develops. Salesforce has an unsurpassed ability to nurture their customers. They work with us. They’re constantly looking for how we can do things better. I have to say honestly that we don't have this experience with any other big SaaS company. They just really go above and beyond.

Duffy’s team manages about 15 projects on Salesforce concurrently. Having seen the benefits of low-code development since last June, they’re now looking at how the approach can be applied to other areas of the Autodesk business:

These low-code tools help us minimize dependencies. When you write code, you might touch similar objects and developers can step on each other's toes or create dependencies. With low code, none of these dependencies exist. Our developers would prefer to go with Flow because they can just drag and drop the stuff they need. We can use the expertise of the business analysts and user experience specialists. So, there's no need for me to sell these tools. They're just selling themselves.

As for advice for other IT and business managers who are thinking of going down the low-code route, Duffy says they should ensure they engage regularly with the people who are going to use the final product. That might sound obvious, but the evidence suggests joined-up thinking is rare in many in big companies, she concludes:

There’s a lot of people who are responsible for processes and trying to bridge conversations between technical people and users. So, make sure that IT people talk to their end users and don’t just go with the business process improvement people. It's important to try to understand what your user needs and wants.