Short answer: try modeling the number's customer instead of the customer's number.
A big part of domain modeling is digging into the domain language to discover entities that might not be obvious.
TelephoneNumber is probably an entity in your domain - it's a thing that has a life cycle. You acquire the rights to it from your supplier, you assign those rights to a customer, perhaps you reassign those rights to a different customer when the first is done with it? Maybe you release it back to the supplier, and so on.
The relationship between the customer and the phone number may also be an entity - again, we can model when that relationship begins, and when it ends, and perhaps other interesting events as well.
(One cheat is to think about a relational data model - if you have a table, you likely have an entity).
Having identified your entities, you can then start thinking about where the aggregate boundaries belong. It sounds like you have something like a "pool" that keeps track of how many numbers are available, and decides when we should be ordering more. So your modeling question is largely about whether the number assignment belongs with the customer, or with the pool, or standing alone on its own, or if everything belongs in one single aggregate.
Any of those can be the right answer, depending on how much risk is introduced by various data races, and how much benefit you can accrue by distributing the work.
But given that you don't appear to have discovered this on your own, I would suggest that you start with the idea of modeling a pool of numbers, and treat the assignment of numbers as something that happens within the pool "aggregate" to start with. It may not, in the end, be the best answer for your circumstances, but working that part of the problem is my best guess at getting you unstuck from your current condition.
I'm trying to bring these both into the same transaction, but I also have an inkling that that's not the best solution here.
When everything happens within a single relational database, you can be a bit sloppy about how you draw your aggregate boundaries. But when you start thinking about having more than one database... well, the fact of the matter is that transactions across multiple databases suck, so you want to align your domain model and your data model so that you don't ever need to make a change in more than one database at a time.
