You need to be ready for any identifier that is exposed to users/customers needing to be changed, and changing the identity of a row in a database and propagating that change to all foreign keys is just asking to break data.
If the data has no natural business key, you can add an additional field for a "business identifier". This should be optimized for the processes it is used for. Telephone keypad entry means numeric only. Over the phone/verbal means avoid similar sounding symbols (B/D, M/N, etc). You can even autogenerate some easily memorable phrase ("green jelly").
The effect of this is that the business can later change how they want to refer to records, and the only data schema change is either adding a new column for that style of id or transform the ids already there. The change doesn't propagate through the entire database, and you still have one id (the surrogate) that is valid over time.
In short, I would avoid exposing surrogate keys to users. As the comments point out, surrogate keys should almost never change. Conversely, businesses want to change everything. If the surrogate key is exposed, it is just a matter of time before the business wants to change it.
As a side note, when I say "exposing" here, I mean to give the key to the user with the expectation that they use it directly (like calling in to support with their order number).