Yes, I know I ended that title in a preposition. Criticizing grammar of this kind is the sort of mindless pedantry up with which I will not put.
Many struggle with writing user stories. The common “as a,” “I want,” “so that” format is widely used and is a useful teaching tool…to a point. Be careful if you are having divisive arguments about what type of user should be named. If so, you are showing a hallmark of the novice in the Dreyfus model for skill acquisition.
It’s important not to disparage those who are working through who is the user in a user story; they are working their way towards understanding the true value of their work.
A problem can arise when a simple and formulaic answer is desired. Granted, such a practice may grant increased efficiency in story writing though it will likely cut off much needed creative and exploratory practices needed to produce astonishing results.
The goal of a user story (originally, Kent Beck wanted them to be just called ‘stories’) is not to write better user stories; it is to go beyond requirement and into true understanding. For this, you need to who who the software is for, what problem it is solving for them and why that problem is valuable to be solved.
My advice is to avoid restricting what ‘user’ can mean as it may cut you off from useful insight and deeper meaning into what you’re building. Instead, favor creating diagnostic means of knowing if you have chosen a good understanding of who given work is for.
Consider this as an experiment. Answer the question, “Do I know how this thing I’m building will change the world of those who will use it?” If not, you may not yet understand for whom your work is valuable.