How to draw a use-case diagram for the given context?

Given the following description of a tracking request to DHL

In the age of Corona, we order many things online. The delivery does not always work out as planned, so we are interested in getting (more) information about the delivery.

The DHL packet service has a comprehensive web service where it provides information on shipping and receiving packages. Among other things, page visitors can search for contact information on the DHL webservice. Another option is to contact DHL via a chat. Requests in the chat are answered automatically by a DHL AI, one instance of the DHL webservice. A visitor can send a request (via the chat), which includes also entering the consignment number of the package to the DHL AI. Then, in order to get information about the shipment, the visitor needs to authenticate in the webservice, which promotes the visitor to a customer and the DHL AI is allowed to reply to the chat request. In case the DHL AI cannot answer the request, it forwards the request to a DHL employee. To shorten the waiting time the customer can optionally contact the DHL employee via phone.

How to draw the use-case diagram? Is this correct:

and how would I model the "... optionally contact the DHL employee via phone" use case? Would this use case extend the forward request use case? Can we then just associate the customer with the extended use case like this

but then wouldnt the "contact DHL via chat" include the "send request" use case?

A use case normally should correspond to a user goal, and unless it's an extension, it should also make sense independently of other use-cases. In this regard:

• Reply to request does not make any sense on its own. So this "use case" is probably a detail of the use-case Contact DHL. The DHL AI would then be a secondary actor of the Contact DHL use-case.
• Send request seems likewise to be a detail of how to contact the DHL agent.
• Details such as Enter consignment number or send request are user interface detail. Use-case should not be used to model user-interface. This is a design topic, and putting it in the use-case would force to use one specific user-interface approach without considering better alternatives.
• Authenticate is not a use-case. It's a constraint. Imagine that you have a system with Single Sign On (SSO): an authentication use case would then make no sense since there is no interaction with an actor to achieve it.

So keep the use-case as simple as possible:

• if you start to think about the details of the scenario, and successive steps, you're no longer modeling a use-case, but a control flow: use an activity diagram fro this level of detail.
• if you start to take a use-case and then decompose it into smaller cases based on the narrative, there are big chances that you'll be mislead to do functional decomposition. This is not recommended for use-cases, since it leads to very detailed diagrams.

Now to the optional use-case: optional typically suggest to use an extension. But does Contact by phone really extend the Contact via chat? I believe these two forms of contact are two different things. I therefore see two approaches:

1. Just make a use-case Contact DHL and in the description of this use-case you explain that the contact can be via Phone or via Chat. This is my favourite approach.
2. Make a use-case Contact DHL for the general case. Make to specialisations Contact DHL by chat and Contact DHL by phone that each could implement the general case as best fits. This approach is more complicated, but it allows to take into account more fundamental differences between the specialisations, such as the fact that an AI actor is involved in the chat and a human operator is involved on the phone.