Is This Survey Broken or Rigged? I Used Cursor to Find Out

I recently bought a new car: a Volkswagen Polo, model year 2026.

I’d been looking at several options, but the Polo really stood out. It’s built in Brazil, and I’ve always had a certain affinity with the Volkswagen Group: I like their cars and I’m familiar with them. After doing my research, I decided to go for it.

The Financing Trap

As part of the process, I explored financing options with different advisors. After comparing alternatives, Banco Santander came up as the best option. They were offering some very attractive interest rates, especially for the first few months of the loan. My plan was (and still is) to take advantage of those initial rates and then refinance later with another bank. Finding a rate that competitive again would be hard, but the idea was simply not to keep the Santander loan beyond the seventh month.

The process moved forward. The car purchase itself had its own issues with the dealership, but that’s another story for another day. What I want to focus on here is my experience with Banco Santander.

Once the loan was finally disbursed, I noticed something unexpected: an insurance product had been added to my credit without my consent. I went back to the contract, reviewed it carefully, and couldn’t find any section where I had agreed to that insurance. That’s where the first real frustrations started.

There were several other issues along the way, which I won’t go into detail here. But the moment that truly caught my attention came later, in a much more subtle way.

The Suspicious Survey

A few days after everything was finalized, I received an email from Santander asking me to complete a customer satisfaction survey. It included a standard Net Promoter Score (NPS) question, asking me to rate my experience on a scale from 0 to 10.

When I tried to fill out the survey, I noticed that if I selected any score between 0 and 6, clicking on the follow-up options produced no visual feedback at all. It felt like the inputs were broken or disabled.

However, if I selected a score between 7 and 10, the experience was completely different: clicking an option would display a visible checkmark, confirming my selection. The form behaved exactly as expected.

At first glance, this felt suspicious. It almost looked as if the survey was designed to discourage negative feedback: if users with low scores see no confirmation of their selections, many will assume the form is broken and give up, and the data skews positive.

That curiosity pushed me to dig deeper.

Enter Cursor

I decided to download the survey page and analyze it locally. I saved the HTML along with all its assets (CSS files, JavaScript, images) and opened the folder in Cursor.

My first instinct was to ask Cursor’s agent to help me understand what was going on. I described the behavior: “When I select a score between 0-6, a follow-up field appears but clicking on the options produces no visual change. When I select 7-8, a similar field appears and clicking shows a checkmark. Why?”

Cursor started exploring the codebase. It looked at the HTML structure, identified the field names, and then dove into the CSS. Within minutes, it found the problem.

The survey was using custom-styled radio buttons. Instead of the browser’s default radio inputs, the CSS was hiding them with appearance: none and rendering a custom checkmark using the ::before pseudo-element when an input was selected. This is a common pattern for creating visually consistent forms across browsers.

The CSS rule that displays the checkmark looked like this:

.hs-form-checkbox-display input:checked::before,
.hs_buena_experiencia___dispuesto_a_recomendar_el_credito_de_vehiculo
  .hs-form-radio-display
  input:checked::before,
.hs_mala_experiencia___nivel_de_satisfaccion_en_asesoria_y_servicio
  .hs-form-radio-display
  input:checked::before,
.hs_mala_experiencia___dispuesto_a_recomendar_el_credito_de_vehiculo___7_y_8
  .hs-form-radio-display
  input:checked::before {
  content: "\2713";
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
  color: #ef2c2c;
  font-size: 18px;
  font-weight: 800;
}

There are selectors for the “good experience” field, for “satisfaction level,” and for the 7-8 score range field. But the selector for the 0-6 score range field, hs_mala_experiencia___dispuesto_a_recomendar_el_credito_de_vehiculo_0_a_6, was missing.

The weird part is that the field was actually working. The inputs were receiving clicks, the internal state was updating correctly, the values were being captured by HubSpot’s JavaScript, and the form could be submitted with valid data. But because the CSS selector was omitted, no checkmark appeared when you clicked an option. From a user’s perspective, the clicks appeared to do nothing.

A Bug, Not a Conspiracy

Cursor helped me confirm this was a CSS bug, not an intentional design decision. The evidence was clear:

1. The 0-6 field was correctly included in other CSS rules: input box styling, row backgrounds, flex layouts. Only the :checked::before rule was forgotten.
2. When I inspected the hidden hs_context field in the form, I could see that clicking options in the 0-6 field was actually updating the form state.
3. Injecting the missing CSS via the browser console immediately fixed the visual issue, confirming that the problem was purely presentational.

It’s a sneaky kind of bug: the form was functionally correct. Unit tests checking that clicks update the form state would pass. Basic end-to-end tests verifying that the form submits with the correct data would pass. Only visual regression testing, or a human actually looking at the screen, would catch this.

The fix was adding one more selector:

.hs_mala_experiencia___dispuesto_a_recomendar_el_credito_de_vehiculo_0_a_6 .hs-form-radio-display input:checked::before

Finally, I Could Complain

Once I understood the problem, I opened the browser console and injected a quick CSS fix:

const style = document.createElement("style");
style.textContent = `
  .hs_mala_experiencia___dispuesto_a_recomendar_el_credito_de_vehiculo_0_a_6 
  .hs-form-radio-display input:checked::before {
    content: '\\2713';
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translate(-50%, -50%);
    color: #ef2c2c;
    font-size: 18px;
    font-weight: 800;
  }
`;
document.head.appendChild(style);

Suddenly, the checkmarks appeared. The form had been capturing my clicks all along, I just couldn’t tell. Now, with visual confirmation, I could complete the survey with confidence and submit my feedback about the unauthorized insurance and the other issues I’d experienced.

The Uncomfortable Truth

Even if this is just a bug, the outcome is the same.

The lowest scores, where frustration is most likely to show up, are precisely the ones where users get no confirmation that their feedback is being recorded. An unhappy customer meets a form that looks unresponsive. Some will give up. Some will retry a few times and leave. Some might even bump their score up to 7 just to see a checkmark appear.

And that has real consequences for how the data looks and how problems are surfaced internally. If your NPS dashboard shows mostly 7+ scores with detailed feedback, and 0-6 scores with sparse or no feedback, you might conclude that unhappy customers just don’t have much to say, when in reality they had no way to tell if their clicks were registering.

Intentional or not, it’s a curious coincidence that the bug happens exactly where negative feedback matters the most.

What I Learned

• Visual state and functional state are not the same thing. The form was working correctly at the data layer, but from the user’s perspective nothing was happening.
• Unit tests and basic E2E tests would not catch this. The :checked state was correct; only the CSS rule to display it was missing. You need visual regression tests, or someone actually looking at the screen.
• Missing visual feedback distorts metrics like NPS. When users can’t see that their input was recorded, they abandon forms, retry clicks, or change their answers just to get a response.
• UX bugs can have ethical implications when they systematically affect one group of users. In this case, the unhappy ones.

And yes, I finally got to submit my complaint. Whether anyone at Santander reads it is another story.