When I was working with SAP on one of the localizations of their ERP software, the solution that was causing the most problems was something called “sales and purchase ledgers”. It was a part of the annual VAT return form.
It was also an old piece of software and the one that consumed considerably more resources from support than any other report. The biggest problem with it was the fact that every company used it differently — at least according to the product managers.
Table of Contents
Because of this diversity of use cases, the documentation was too high-level and feature-based rather than process-based. The UI was also created before UX reviews became a thing, so it was difficult to understand.
The problem was made worse by the fact that the majority of customers had been using the ledgers for a long time and had gotten used to the fact that our content was inadequate. Their knee-jerk reaction was to file an incident with support.
At the local branch, product managers maintained a very close contact with the customers. They were part of the same "club". I used this to solicit critical feedback on several occasions.
But this story started when, at one point, the tax authorities decided to do a major overhaul of the form. It was a big disruption and all clients were expecting SAP to provide the update on time. I used this opportunity to improve their experience.
Step 1: Improving content on our end
I started with our internal data. I didn’t believe that every single customer was using the product differently, so I went to support and asked them to analyse customer incidents from the previous year and see if they find any trends.
Sure enough, they realised several things:
- Until a certain point in the process, every customer was following roughly the same procedure that only then branched out into a dozen variations. While I didn’t have the capacity for the variations, I could cover the main process with documentation.
- 20-30% of the support incidents were due to customers misunderstanding something about how the report works, or a specific field on the screen. I could easily fix this by changing the documentation, providing better contextual help, and improving UI copy.
I really invested into my relationship with support. I made it a rule to show them I valued their work, and regularly asked them for feedback as people with first-hand experience with actual user problems. They reciprocated.
First, I sat down with the developers and scrutinized every pixel on the screens. I:
- Threw out some UI elements altogether,
- made some more UI elements hidden by default,
- gave feedback about UX that allowed the developers to avoid problems that required the user to do something unintuitive.
- Improved the wording on the remaining errors and UI elements.
- Provided useful and tactical contextual help.
Then, I did a major overhaul of the help portal documentation for the main process.
Step 2: Working with the customers
Because the legal change was important, customers were sitting at the edges of their seats waiting for us to roll out a pilot so that they could start migrating. This was the first legal change in a long time that affected every single customer in such a major fashion.
I wanted to show our users that their feedback is heard and appreciated, so I had an idea. The product managers had an internal forum (called SAP Jam) where they made announcements to the customers. It had more than 3000 members. So, I secured buy-in from all stakeholders and wrote something like this:
Dear all,
We would like to show you a prototype of the new version of the sales and purchase ledgers. You will be able to ask the developers any questions you have. Please be ready to provide feedback.
For more information, join our user feedback forum.
Your product managers
The “user feedback forum” was something I created just for this. It was a page on SAP Jam where I could invite people and interact with them. But it also had tabs, and the “sales and purchase ledger feedback project” was just one tab. My ultimate plan was to carry over the same engaged customer base to other feedback loops under other tabs.
Circa 300 customers signed up for the group and became my user feedback sandbox. More than 100 of them attended the prototype presentation.
During the presentation, I followed the usual user testing rules. Mainly I just let them talk and wrote down every hiccup or question they had during the process. Then I asked open-ended questions and wrote down more. When we were done, I went back and changed the content to better suit the users.
Initially, users were skeptical and there was much venting that was not directed at the prototype itself. But as I posted updates in the user feedback groups, people realised that they were actually being heard. They saw that the software itself was working as they expected it to, and that documentation was finally becoming useful.
Results
Shortly before the final roll-out of the software, we held our annual Customer Forum. It was the biggest external event of the year. Usually, I do a booth for everything documentation and UX, but this year I joined the booth for the sales and purchase ledgers team.
We were expecting a flood of people. This was our most difficult transition to date. But only a couple people showed up, including a Vice President of a major company that said that she was very pleased that “the vendor is listening to them”. It was a big hit.
But the real results came when we sat down with support a year after and re-calculated the amount of time they spent on supporting the sales and purchase ledgers. And the result was huge: 1,5 FTE months less than the year before, or a 20% change.