Mild disagree.
The saying "you can't solve social problems with technology" usually means - at least in the places I have heard / used it - "If your workforce fights a process - be it for the process being stupid, tools being slow, incentives do not align with policy, whatever - especially a control step, no amount of mandatory tech enforcement of that process step will yield better results." At best you get garbled data because someone hit the keyboard to fill in mandatory fields, sometimes, the process now works OUTSIDE of the system by informal methods because 'work still needs to be done', at worst, you get a mutiny.
You have to fix the people(s' problems) by actually talking to them and take the pain points away, you do not go to 'computer says no' territory first.
In my experience, no org problem is only social, and no tech problem is merely technical. Finding a sustainable solution in both fields is what distinguishes a staff engineer from a junior consultant.
Another point of view on that.
I work on SaaS platform as engineer. We can have some people from customer A asking for bunch of fields to be mandatory - just to get 6 months later people from that company nagging about the fields saying our platform sucks - well no their process and requirements suck - we didn’t come up which fields are mandatory.
I've been thinking a lot about that lately, and I agree. I used to be hard in the "You can't solve social problems with technical solutions", but that's not the whole truth. If people aren't using your thing, sure, you can brand that as social problem (lack of buy-in on the process, people not being heard during rollout, ...). However one way of getting people to use your thing/process is to make it easier to use. Integrate it well into the workflow they're already familiar with, bring the tooling close, reduce friction, provide some extra value to your users with features etc. That's technical solutions, but if you choose them based on knowledge of the "social problem" they can be quite effective.