The backend can. But what’s exposed to customers will be a very very small subset of that capability. Hence why only the csrs can perform that function.

The business undoubtedly did a crude cost/benefit analysis where the cost to expose and maintain that public interface vastly outstrips the cost for the few people that have to call in and change their name.

> The business undoubtedly did a crude cost/benefit analysis where the cost to expose and maintain that public interface vastly outstrips the cost for the few people that have to call in and change their name.

Haha, not likely.

In reality the org is so drowned in technical debt that changing the last name involves manually running 3 different scripts that hit three different DBs directly and the estimate from the 3rd party dev consultancy that maintains the mess for how long it'd take to make a safe publicly usable endpoint is somewhere between 2 years and forever.

OK, so why not have a customer support bot add the “operation description” into a message queue (SQS, Kafka, whatever) if a formal API doesn’t exist for that operation? The csrs can then handle that task async and the customer can get a sms / email when their request is fulfilled? Why force things to be synchronous and irritate the customer?

It’s not exactly a difficult design problem. Unless I’m missing some thing.