In this context, a client certificate is really no different from any other certificate; the CA that issue the certificate is responsible for maintaining revocation information for it. Managing revocation information of certificates they issue is a core function of a certificate authority. When you pay for a certificate, this is one of the services you are paying for.
To be specific, every certificate will have either a CRL Distribution Point (for CRLs) and Authority Info Access (for OCSP) X.509 extension that point to the URL where revocation information for that certificate can be found. It is the CA's responsibility to maintain revocation information at those URLs.
Updating and publishing CRLs is mostly automated, but there may be a human in the loop to actually mark your certificate as revoked, or not. depending on how the cert is revoked. For example, if you call an API to request your own cert be revoked, then almost certainly no humans are involved. If there's an ars technica news story about you horribly mis-managing your certificate's private key, then almost certainly some human at the CA will decide to revoke your cert for you ;)
Pulling this in from comments, even though it's a little outside the scope of the original question:
Alternatively, I've seen setups where someone's access to the site is taken away, but their certificate does not need to be revoked (for example, someone changes departments and still needs their client certs for other websites). That would be managed through whatever Roles / Permissions system is built into the website, and doesn't really have anything to do with certificates themselves or CRLs because the cert is still valid as far as the CA is concerned.