User-friendlier name for JSS

It depends on the level of interaction your clients have with it. For our users, the only things they need to know are:
1) Use Self Service to install software yourself.
2) the system as a whole that we are using on the Macs is called Casper.
3) on rare occasions users may ask what the jamf process is they see in Activity Monitor or top. I tell them that's the "Casper agent".

They don't need to know what JSS is or Recon or Composer etc.

If your "clients" are in the tech support field, don't mince words. Call the components exactly what they are so you can have proper conversations about what goes on behind the curtains.

Just curious, but in what location would users be seeing the JSS name? In the Self Service application sidebar (if plug-ins are configured)? At the user enrollment screen? Those are the two main places I can think of where an end user would even see it. Is there somewhere else they encounter it I'm not thinking of?

Since the server name can be any FQDN your organization is comfortable with, I'd imagine you can name it whatever you want, and they'll see that name in the few places it might show up for them. We use the term "mac" as part of our JSS name so its obvious what its for, but truthfully we aren't too concerned about the name of the JSS itself.
As @AVmcclint points out, they are more likely to see jamf and jamfAgent processes running in Activity Monitor and wonder what those are.

@marc_grubb Would I be correct to assume that you're referring to the DNS name assigned to a JSS? If so, this becomes a complicated but flexible answer.

First, the DNS name component of your JSS URL should probably be a DNS alias and not the A record for your tomcat server or load balancer.

You can use redirects, either internal, external, or both to simplify access to what is typically the only end-user facing JSS function, the enrollment page. I've seen "enroll.company.com" or simply "enroll" used to redirect to jss.company.com/enroll

I do agree with @AVmcclint and @mm2270, but I suspect that you might have been referring to the server/DNS name.

Followup: our JSS' address is casper.mycompany.com so if by some chance a user sees that, we tell them "that's the server for the casper system." Like any server system, it should be treated as a "need to know" basis. If they ask what Casper is, I point them to jamfsoftware.com and they can read the marketing info. All the details about the infrastructure and configuration should stay within the IT group responsible for it.

Just tell them it's the friendly neighborhood ghost....
....I'll be here all week....

Thanks for all the responses. I definitely should have specified that I was referring to the JSS' URL, though @milesleacy figured out what I meant.

I want the URL to be so simple that users don't even need to ask, "What is casper.domain.com" or "what is jss.domain.com" I want it to be self-explanatory. Even the word "enroll" means something to us, but not the users. "setupmymac"? "macapps"? "macs-at-companyname"?

I love the idea of aliases - good tip!

We also use something like the casper.mycompany.com model, and for the most part we don't bother explaining it because no one outside of our team & local tech support accesses it anyway. We don't use the /enroll feature, although we could I suppose - we actually host enrollment packages outside of the JSS itself - but even if we did, we'd just provide a link in the documentation and be done with it.

As for the domain naming, though - that's totally up to you, isn't it? You can set up redirects in DNS so that my-computer-is-shiny.mycompany.com points to casper.mycompany.com/enroll.

we have an internal link shortener, so instead of typing https://jss.mycompany.com:8443 we can do a go/jss or for the enroll link, go/osx. Easier for most of our local techs to remember, too. I left my dns entries the same but we can make it easier to remember elsewhere. The only failure is that safari requires http://go/ instead of go/ due to search being the default tendency in OS X 10.8 and higher.

BTW, I decided to use macmgt.subdomain.domain.com, since the company does not allow servers at the domain level. Thanks for all the valuable input!