First of all, I would start off presenting yourself:
Dear XYZ support team
I am the web developer in charge of example.com website.
By presenting you this way, you are establishing the frame to treat you, hinting that you should be presupposed to be somewhat proficient, so they could choose to answer in a more technical detail. Note that if it actually was your fault (such as not finding the changes because you were connecting to the wrong webhost), the higher knowledge you implied to have, it's more likely they will probably look down on you as not a good "expert" (even though we all make silly mistakes from time to time).¹
I don't think that telling them that you are the "administrator" of the website conveys this, since that could apply to anyone with an administrator account on the CMS, regardless of their proficiency.
¹ Not that it will matter much after they close the ticket. Unless you contact them so often that they remember you, which would be nice if they have a good opinion, and probably mean they will dumb down even more if they think you have no idea at all.
Second, explain clearly the issue:
My customer is experiencing an issue where his WordPress 4.9.4 install doesn't show the updated content after editing. He claims this happens on different computers and browsers. It will eventually be shown, though.
I am stating the problem, the technology used up to the actual version. And also, the facts that you didn't verify yourself are being qualified as such (it wouldn't be unlikely that you were told something that was wrong).
Third, state the troubleshooting you already performed and their results:
There is no caching plugin installed, and the option "Show stale content" that is available on the site preferences is disabled.
Then, you may advance your hypothesis:
Do you have any other caching layer that may be affecting the customer? Is there a caching proxy (such as squid or varnish) serving the pages before being served by Apache?
Here you are guessing that there is a proxy serving cached pages. The mention of actual packages can be useful in case the support team didn't know about "caching proxies", but remembers that there is something called "varnish" installed there.
Thanks for your attention
Be polite in your tickets, keep the ticket identifiers on the subject, take care of your orthography, organise the text in paragraphs. A text that is nice to read will be easier to handle than one where you need to guess what it is talking about, and just for that it will probably be answered quicker. Plus the effort spared on understanding it can be directed to the actual problem.
Include screenshots if needed (and supported by the ticketing system). In same cases they may show the problem better than a text description (sometimes, there is a crucial hint there that can be obtained). If you are using the command line, provide both the command and its output.
Beware that making a text too long may have the opposite effect, too. If you think the long explanation can actually discourage the reply, you can arrange differently:
Dear XYZ support team
Do you have any caching layer in front of your FooWebsites package?
The issue I am facing is that the customer doesn't see immediately the changes he performed in WordPress 4.9.4.
I have already checked the following things:
(…)
If some of the data is long (like a debug file), you can provide that on an attachment. This way, if irrelevant, it can be skipped by not opening. Depending on the ticket platform, they may otherwise need to scroll down seven pages of logs before reading the next reply.
If there is some extra information they would be unlikely to need, you can simply offer to provide it (“I recorded a video performing the publication steps and where the problem can be seen, would you be interested on it?”).
You should sometimes follow-up acknowledging that their solution worked. Specially if you have been back and forth with the tech support. Rather than presenting a list of possibilities for fixing the stale content issue and not hearing back, it is nice to receive:
Thanks a lot, changing that option in cPanel solved it. You are the best!
This way, the HelpDesk can note the issue as fixed as and close it. Take it with a grain of salt though, as it may be that the ticket had already been closed after their answer, and thanking them would reopen it (generating more work). So if you think this will be the case, it may be desirable not to do it (specially if it was an easy answer for them). If you don't know the status of the ticket at their side, I would recommend erring on the side of acknowledging the solution and thanking, though. The people answering you are humans (hopefully), and deserve being treated as such. It is generally really simple to reclose such a "Thanks" message.
In general, try to follow guidelines for posing technical questions, such as the famous Eric S. Raymond How To Ask Questions The Smart Way.
It may take a bit longer to state what you tried instead of simply saying "WordPress doesn't work", but that way you are presenting your proficiency by your work. And it may even spare you the question entirely (stating the issue may hint a solution, or provide a way by which you can get confirmation of what is happening by yourself). It will anyway be faster than if they had to start asking you "In what way it doesn't work, what did you tried?" following a script.
I recommend sending an email/ticket instead of calling. Unless you have an expensive support contract (and probably even then), calls will be handled by the lowest Tier, and may actually need to convert that into a ticket if escalating as noted by Gypsy). If you contact by email, the information you provided (not the way the first Tier understood some parts of what you said) is available to anyone handling the ticket (even yourself!), which allows a less noisy communication. It also spares you from having to explain everything from the beginning to every agent each time you are transferred.
You mention that you write a lot of these emails and they are a waste of your and everyone elses time. I would argue that there is something wrong if you need to spend too much time in relation to the "normal" work to keep the thing up. Perhaps you are not so proficient [in the way your friends WordPress is installed], the webhost is doing some uncommon things, their tech support is incompetent… At one point it may make sense to switch providers.
You may find out that even if your question is crystal clear, you are being provided long answers with many points not too relevant to your issue, "wasting their time". For example, after asking to which host you should ssh to, they are not only indicating where to find it, but also how to access by FTP and explaining how to download and run PuTTY.
This doesn't mean that by not grasping that you are proficient they spent a lot of time in order to explain you basic concepts. When there is a frequent question, there will be a template for the solution, and it is actually faster to reply explaining everything than cutting down to just what was asked. So, if there is a case that the rest may be useful, it makes sense to leave it even if it may be a bit redundant for your profile.
Having a written communication goes both ways, as you can skim the reply to the part where they explain what you wanted. However, if you need to ask back, do read everything and confirm it was not at another part of their reply.
Nevertheless, no matter how well explained is everything, sometimes you will get in contact with a tech support who will fail to properly address your request the first time.
