For customer service I find that the real automation "gains" tend either to be in debugging the rest of the organization or in driving a customer to give up on finding a human to talk to.
This is true of automated IT processes in general; for human-operated processes there's always a certain amount of "slack" between how the process is written and what needs to be done to make it actually work. The knowledge for the latter is concentrated in lower-ranking staff - the "NCOs" - and often unknown and unknowable to those running the system. Converting the system to automation only converts the known process, so it tends to fail hard until the slack can be taken up elsewhere or learned and incorporated.
I've worked indirectly with customer support, in that we built FAQs and flows that made users do some troubleshooting themselves before contacting support - a simple couple-of-steps plan of checking your fuse boxes or checking the website for expected maintenance or known outages before calling support.
The next layer of automation would involve people going through one of those call menus; ideally once the customer ends up at an agent, they will have all their data and files right in front of them already.
This is true of automated IT processes in general; for human-operated processes there's always a certain amount of "slack" between how the process is written and what needs to be done to make it actually work. The knowledge for the latter is concentrated in lower-ranking staff - the "NCOs" - and often unknown and unknowable to those running the system. Converting the system to automation only converts the known process, so it tends to fail hard until the slack can be taken up elsewhere or learned and incorporated.