Four jobs, and the order matters because each one depends on the last.
Getting the assistant or agent access to what it needs to answer: the customer record, the order status, the stock level, the open ticket. Through an API where one exists, and through a read-only database view or an export where one does not.
Creating the ticket, updating the record, issuing the refund. This is where the risk lives, so it gets the narrowest permissions the task allows and an approval step wherever the action cannot be undone.
Knowing which customer is asking, and proving it before showing them anything account-specific. An assistant that will discuss an order with whoever quotes the number is a data-protection problem, not a feature.
The other system will be down, slow or rate-limited at some point. The assistant has to say "I cannot reach that right now, shall I get somebody" rather than invent an answer or hang. Designing that path is work, and skipping it is how a good demo becomes an embarrassing launch.
Three situations, in descending order of how well they usually go.
WHMCS, cPanel, Shopify, Stripe, Razorpay, most modern CRMs and helpdesks. These are the good case: documented, authenticated, versioned. We are an authorised WHMCS reseller and write WHMCS modules, so that one in particular is familiar ground rather than a discovery exercise.
Common with older in-house software. Workable through a read-only view and a narrow write path, but it means your schema becomes part of the contract, so an upgrade on their side can break it. We say so before starting rather than after.
A desktop application, a portal with no API, a process that lives in somebody's inbox. The options are browser automation or a file exchange, both fragile, and sometimes the honest answer is that the integration is not worth its maintenance cost yet. We will tell you that too.
What gets integrated, and where it runs.