Sooner or later a client needs something their package does not give them: more disk, another database, a few more email accounts. WHM lets you change one account's limits without touching the package it came from, which is exactly what you want for a genuine exception and exactly what you should avoid doing as a habit.
This covers where the settings are, which ones take effect immediately and which do not, and the bookkeeping problem that quietly builds up if you do this often.
Modify an account, or upgrade it
Two screens in WHM change what an account gets, and choosing the wrong one causes most of the confusion here.
Modify an Account changes this one account's limits directly. The package it was created from is untouched, and so is every other account using that package. The account's limits now differ from its package.
Upgrade/Downgrade an Account applies a different package wholesale, replacing every limit with that package's values. Any individual adjustments you made previously are overwritten.
So: a client on your standard plan who needs 2GB more disk is Modify. A client moving from your small plan to your large plan is Upgrade/Downgrade. Using Upgrade/Downgrade on an account you had customised silently discards the customisation, which is the mistake worth remembering.
Changing one account
Open Account Functions then Modify an Account, and choose the account. You get the same fields as account creation, filled with current values.
Disk quota. In megabytes. Raising it works immediately; lowering it below what the account already uses does not delete anything, but the account is instantly over quota and cannot write new files until it is under again. Check current usage before reducing.
Bandwidth. Applies to the current month's counter.
Databases, email accounts, subdomains, addon and parked domains. Raising is safe. Lowering below what exists does not remove anything; the client simply cannot create more.
Dedicated IP. Assign or remove one. Removing an IP from a site with SSL means the certificate needs attention afterwards, so do not do this casually on a live site.
Save, and the change is live. There is no restart and no propagation delay for quota changes.
What the client sees
Quota changes appear in the client's cPanel immediately, though a page they already had open will show the old figure until reloaded.
The disk usage figure itself can lag a little, because cPanel caches it rather than recalculating on every page load. If a client insists their usage is wrong right after you changed something, have them wait a few minutes before investigating further.
WHM does not tell the client you changed anything. If they asked for more space, tell them it is done: otherwise they will keep watching an old number in a stale tab and conclude nothing happened.
Checking the account first
Before adjusting anything, look at what the account is actually using. Account Information then List Accounts shows current disk usage against quota for everything you host.
Show Accounts Over Quota is the screen worth checking weekly. It lists accounts that have hit their limit, and hitting a disk limit produces symptoms that do not look like a disk problem: email stops being delivered, WordPress cannot write uploads, and databases refuse writes. A client reporting several unrelated failures at once is very often simply full.
You can also open the account's cPanel directly from List Accounts without a password, and use its disk usage view to see which directory is consuming the space. It is frequently backups a plugin has been writing for two years.
When more disk is the wrong answer
Raising a quota is quick, which makes it tempting when the real problem is elsewhere.
If the space is old backups, deleting them costs nothing and fixes it permanently. If it is a log file growing without limit, more disk delays the same conversation by a month. If it is genuine growth, raise it, and check your own remaining allocation before you promise it.
That last point matters: every megabyte you grant comes out of your reseller pool. WHM will let you promise more than you hold without warning you.
The drift problem
Modify an Account is the right tool for exceptions. The difficulty is that exceptions accumulate.
After a year of small adjustments you have accounts whose limits match no package at all. Nothing is broken, but you have lost the ability to reason about your accounts as groups, and the day you reapply a package to one of them, during an upgrade, say. Every accumulated adjustment silently disappears and a client loses something they were promised.
Two habits prevent it. Record why you changed an account, somewhere you will find it again: your billing system's notes field is ideal. And when the third client needs the same exception, stop modifying accounts and create a package for it. Creating hosting packages deals with that; a package that exists is far easier to maintain than three accounts you have to remember.
Related tasks
Moving a client between plans is a different screen. Upgrading or downgrading client accounts explains it, along with what to check afterwards.
If you are adjusting an account because a client has not paid rather than because they need something, suspension is the appropriate tool and it is reversible: see suspending or unsuspending client accounts.