Danfoss
Modernize Complaint Handling

To understand the current state, we conducted research interviews with 8 users across North America and Europe. The frustration was immediate and consistent: processing a complaint case was far more inefficient than it should be.

At the centre of it was a single missing piece of information: the Purchase Order number, which is an integral part of processing any case. Unfortunately, the PO number is almost always absent when a customer submits a complaint. In fact, in approximately 90% of cases, a CSR starts a case without one.

Danfoss CSRs operate across two platforms: Salesforce One CRM and SAP. A case is created in One CRM, which triggers a quality notification and initiates the Return Management Process in SAP. Because these two systems don't sync, any changes made in One CRM don't carry over to SAP, and vice versa.

With no reliable bridge between them, CSRs frequently enter placeholder data just to get the process started. This creates a case they know is incomplete, and hoping to reconcile it later.

Complaints from customers arrive by call or email. A Quality Manager at Danfoss then manually reads and categorizes each one, and assigns it to the relevant CSR. The CSR manually searches through the email for reference numbers, which are often missing entirely. The entire intake process, from submission to case creation, is handled by hand.

When a case is submitted to SAP without accurate data, the validation fails. The CSR then has to either navigate through several pages and tabs in SAP to manually cross-reference data points, or contact the customer directly to ask for a PO number - which approximately 50% of Danfoss' business customers don't have on their own systems. Neither path is fast. Each one pulls the CSR away from higher-value work and introduces further delays for the customer waiting on resolution.

This is where the 15 minutes per complaint goes. Not to judgment calls or skilled problem-solving, but to data retrieval that, in principle, should never have been the CSR's job.

Danfoss' main point of contact suggested the most obvious intervention: make SAP easier to navigate so CSRs could find the right sales documentation faster. SAP's complexity is real: it requires deep system knowledge that many CSRs actively avoid, and new hires aren't easily onboarded to it. One CSR put it plainly:

Improving that navigation would reduce friction. But it wouldn't address why CSRs were in SAP looking for that information in the first place.

After speaking directly with CSRs, a larger pattern emerged. The quality of every case hinges on data that comes from Danfoss' customers, who aren't trained to know what a Purchase Order number is, let alone where to find one.

We knew asking them to provide it more accurately wasn't going to work. The gap wasn't effort or intention. It was that the process had been designed around an assumption customers couldn't fulfill.

This is where the real problem lived: not in SAP's interface, but in the intake. The moment a complaint was submitted without the right data, every step downstream was compromised.

We looked at how Amazon handles returns. A customer doesn't search for their order number or invoice, they find the product, and everything else is already attached. The system surfaces the relevant data; the customer just confirms the action.

We believed that same logic should apply here. What if Danfoss' customers could simply identify the product they were raising a complaint about, and the system handled the rest? The PO number, the sales documentation, the SAP-required fields, all pre-populated based on the product and transaction, already synchronized, no cross-referencing required. The CSR receives a case that's complete before they ever open it.

This shifted the design question from:

Instead of starting with fragments, we proposed starting the experience with structure. Danfoss' customers can log into a dedicated portal where they access their order history, select the exact product in question, upload photo evidence, and submit a complete, structured claim.

By the time that claim reaches Danfoss, it's no longer a question, it's a well-defined case ready for action.

A standardized intake changes what arrives in a CSR's queue, but not what happens next. The second part of the solution was redesigning the case management experience itself: giving CSRs a system where validated data is already waiting for them, next steps are clear, and the need to switch between platforms is eliminated entirely.

Once a complaint is submitted through the customer portal, the case arrives with all relevant fields pre-populated. Because the system already holds validated product and transaction data, it can automatically surface a recommended resolution path: the CSR reviews, confirms, and proceeds. What previously required navigating through more than 10 pages across 2 systems now takes 2 steps to complete.

Not every complaint comes through the portal. Danfoss' customers still call in, and those interactions still need to result in a properly created case. For these situations, CSRs can create a case manually, but the experience is fundamentally different from before.

Rather than needing the exact PO number upfront, a CSR can search using any identifier a customer is likely to have on hand: a part number (most common), material number, or sales order number. The system resolves whichever identifier is provided to the correct PO, pulling directly from SAP's back-end.

For cases arriving by email, the CSR can paste the message directly into the system. It parses the content automatically, extracts any recognizable identifiers, and maps them to the right case data. No manual reading, no cross-referencing, no tab-switching required.

The synchronization failure between Salesforce One CRM and SAP was never a technical problem waiting to be solved; it was a structural one. Two separate systems built by two separate companies were never going to sync reliably. The right answer wasn't a better bridge; it was to stop needing one.

By building the case management system natively within SAP, CSRs now work in the same environment where all validated data already exists. There's no duplicate entry, no risk of changes failing to carry over, and no reason to open a second platform. The system CSRs once avoided because of its complexity becomes the place where their work is finally simple, because the complexity has been handled for them before a case ever reaches their queue.

The design intervention was always aimed at three compounding problems: data that arrived broken, a process that required too many hands to fix it, and systems that were never meant to work together. The projected outcomes map directly back to each one.

Case creation time reduced by 80%: from a baseline of 15 to 30 minutes down to 5 to 10 minutes on the happy path. The time CSRs were spending on retrieval and reconciliation is now handled before a case ever reaches them.

Data accuracy at intake increased by 80%, driven by SAP-native integration that eliminates copy-paste errors and dummy data at the source. The 80% of cases that previously started without a PO number now arrive complete.

Context switches reduced from 4 to 5 system jumps per case down to 2. The structural gap between One CRM and SAP, the one that was never technically fixable, is no longer a gap CSRs have to bridge themselves.