Creating an account in WHM takes a minute, and most of its fields can be changed whenever you like. Three or four cannot, in any practical sense, and those are the ones worth slowing down for.
For creating many at once, creating multiple cPanel accounts at once deals with the bulk route. This is about getting one right.
The username is nearly permanent
It names the home directory. It prefixes every database and every database user. It appears in file paths, in backup filenames, and in the account's mail configuration.
Changing it afterwards is possible and amounts to a migration. The paths inside the account's own configuration files do not follow, so applications break in ways that take a while to trace.
WHM suggests a username derived from the domain, usually truncated. That is fine for a client with one site and meaningless for a client who later runs six, where examp tells nobody anything.
Prefer something that will still make sense in three years; the company in place of the domain, if those differ. Keep it short: database names inherit the prefix and there is a length limit, which bites when an application wants a descriptive database name and there is no room for one.
The primary domain defines the account
It is the account's identity throughout the panel, and it is the domain the certificate, the mail configuration and the default document root are built around.
Additional domains can be added later as addon domains without difficulty. Changing which one is primary is the awkward operation, because everything was arranged around the original.
So ask which domain will still be the main one in three years, rather than which the client happens to be launching first.
Dedicated address
Whether the account shares the server's address or has its own is decided here, and moving it later changes what the domain must resolve to, which means a DNS change, propagation, and the possibility of somebody missing it.
Most accounts do not need one. Certificates no longer require it, which was historically the main reason. It genuinely matters for a client sending significant mail who wants their own sending reputation, and for one whose reputation you want isolated from your other customers.
Managing IP addresses in WHM explains the allocation side.
What you can change freely
The package and every limit in it. The feature list. The password. The contact address. All of these are edits, not migrations.
Which means there is no reason to hesitate over them at creation. Put the client on a reasonable package and adjust once you know their actual usage. Creating and managing hosting packages deals with building the packages themselves.
Set the contact address to something external
Not a mailbox on the account being created.
A full account cannot receive mail, so the warning that the account is nearly full is refused by the account it is warning about. It arrives reliably while nothing is wrong and fails at the one moment it was needed.
Ten seconds now, at creation, when the field is already in front of you. cPanel contact information and notifications goes into which notifications to keep.
Do not send a password by email
Set one, have the client change it at first login, and send it separately from the username.
Also tell them plainly that you never need their password to help them, because you can open their cPanel from WHM. That one sentence prevents the habit of clients emailing credentials whenever something breaks. A risk you inherit every time it happens. Opening cPanel from WHM without a password walks through your side of it.
Check the DNS zone that was created
Creating an account generates a DNS zone, whether or not the domain is meant to be served from here.
If the client's DNS is hosted elsewhere, that zone is inert and harmless, until someone points the nameservers here and it starts answering with records nobody reviewed. Mail records are the usual casualty.
Look at it once at creation rather than discovering it during a cutover. Planning a DNS cutover explains the sequence.
Then the part that is not technical
An account exists. What decides whether this client is profitable is what is agreed in the first week, onboarding a new hosting client walks through that, and what support to include covers the boundary that keeps it profitable.
Check what the account can actually do before handing it over
An account created from a package inherits that package's limits and feature list, and neither is visible to the customer until something refuses.
grep -E 'PLAN|MAXPOP|MAXSQL|MAXSUB|MAXADDON|FEATURELIST' /var/cpanel/users/username quota -s -u username
Read this once at creation rather than waiting for the first support request. The counts for mailboxes, databases, subdomains and addon domains are the ones customers reach, and each produces a refusal that reads like a fault rather than a limit.
The feature list is separate and decides which tools appear at all. A customer who cannot find backups or a file manager is usually looking at a feature list rather than at a bug, and that is a two second answer if you checked.
Confirm it works before sending the details
An account that was created is not the same as an account that functions, and finding out from the customer is the expensive route.
curl -sI "https://$(hostname -f):2083/" | head -1 ls -la /home/username/public_html/ | head mysql -e "SELECT user, host FROM mysql.user WHERE user LIKE 'username\_%'" 2>/dev/null grep -c . /etc/userdatadomains | head -1
Log in as the account once, from the panel, and confirm the file manager opens and a database can be created. Both fail in ways that are invisible from the account list.
Then check the address the site will answer on. A new account on a server whose DNS is not authoritative for that domain will not serve it until the domain is pointed here, and telling the customer that in advance prevents the first ticket.
Write down what you agreed
The technical side of creating an account takes a minute. The part that causes disputes later is what was never written down.
Record, per account: which package, what was promised about backups, who owns the domain, what the renewal price is, and who the technical contact is when something breaks.
The domain ownership is the one worth being explicit about. A domain registered by you on a customer's behalf is a domain they will eventually want, and settling who holds it at the start is a conversation rather than a dispute. What to include in your hosting terms covers the document.