The first number people ask for is the wrong one. How many servers. The useful question is which roles you need, because a messenger that stays inside the organisation is not one box with a bigger disk.
Three shapes, not a catalogue
A single site needs a headquarters cluster: the place messages, files and policy live.
An organisation that cannot stop when that site stops needs a disaster-recovery cluster as well, with a target you chose, not a target copied from a brochure.
An organisation with branches, and with people moving between a weak network and a good one, needs edge nodes so a local call and a local file do not travel to headquarters and back. A small relay in the DMZ exists for one job: telling a phone on the public network to wake up, without letting that phone into the heart of the data centre, and without putting the message in the wake-up.
That is the whole catalogue. The sizing guide says the same thing in a table. It does not print a machine count. A count that has not survived a load test is a guess wearing a typeface.
What to bring to the session
A map of sites, not a vendor comparison. Where the directory lives. Which device tool you already use. How many people are in the branches that have the worst links. Whether a committee pack is in scope now or later.
Designed for 30,000 people is a statement about the shape we test toward. It is not a promise that your traffic looks like the test. Your traffic is the reason the architecture session exists.
What not to buy yet
Do not buy a meeting product that is still marked coming. Do not buy a server quote that cannot name which role the server plays. Do not accept “infinitely scalable”. Things that are infinite do not have a recovery plan.
Book the session when the map of sites is sketched, even roughly. A rough map is more useful than a precise number with no place to put it.