To expand on what @jmorahan and @rg305 pointed out, if the certificates cover different domains, there is no limit to how many different certificates you can get. So if one customer comes to you with example1.com and another comes with example2.net, the certificate you get for the first customer doesn't prevent you from also getting a separate certificate for the second customer.
And combining different customers' domains in a single certificate can create some risk for you, in case the certificate has to be revoked (for example, because one of the domains it covers was unexpectedly transferred to someone else), or in case some customers transfer names away without telling you, or in case some customers have unreliable DNS service. In the second two cases, you might have unexpected renewal failures because Let's Encrypt can't validate some of the names in an existing certificate properly for the renewal, even though other names can be validated correctly.
There are CDNs and shared hosting providers that do combine multiple customers' domains in a single certificate, but they usually do a lot of extra programming to try to handle these cases. The Let's Encrypt service makes it easier for you by allowing you to reuse successful authorizations without repeating the proof of control (so if you know which ones succeeded, you know which names you'll be able to request a certificate for), but most of the already-written client applications for Let's Encrypt don't really take advantage of this in a way that's very helpful for a shared hoster.
For example, with Certbot, the entire certificate renewal will just fail if even a single name in the certificate fails to validate. If you just used certbot renew for a certificate covering multiple customers' domain names, that means that one customer could break the renewal for another customer by misconfiguring his or her DNS!
Now, Certbot (for example) has an option called --allow-subset-of-names, which will simply forget about names that fail to validate during certificate issuance, causing them to no longer be part of a certificate. This is good if your priority is to make sure that the certificate gets issued correctly, but it's also not a great option for a shared hoster, because Certbot then permanently forgets that you wanted a certificate for the failed names, even if the failure was temporary. It doesn't store them somewhere to "try again tomorrow" or something.
So if you do combine separate customer names on a single certificate, in order to have reasonably reliable renewal even given the risk that customers who brought their own domain names will unexpectedly misconfigure them or take them away, you would probably need to write your own software to interact with Let's Encrypt that keeps track of exactly which validations have succeeded or failed, and adjusts your certificate coverage to aggregate currently-succeeding renewed names while putting currently-failing names on a list to try again later. I believe that some large entities have effectively done something like this.
Alternatively, if you used a separate certificate per customer, then a renewal failure for one customer's domain would just not affect renewals for other customers' domains at all! So this could be preferable in terms of reliability and convenience for you, even though it involves a larger total number of certificates.
This might not apply if you plan to manage the certificates manually—depending on whether you're expecting to have more like 50 customers or more like 5000 customers.