First, CAPsMAN is a way to make your life easier when provisioning multiple APs and to reduce the requirements on the transport network capabilities. It is not necessary to make roaming possible, nor does it make it easier or faster. The stations (clients) may roam among individually configured APs that use the same SSID with the same ease (or complexity) as among APs centrally configured by CAPsMAN.
Second, I'll try to rephrase @tdw's last post and extend it a bit. With standalone APs, or with CAPsMAN-configured APs with local-forwarding set to yes, you need one VLAN per SSID on the path between the AP and the central router to keep the networks isolated, which means that the transport network must support VLANs. I haven't seen a "dumb" switch which would not handle VLAN-tagged frames (i.e. 1518-byte ones) yet, but better safe than sorry. So if you use local-forwarding=no, the frames from the APs get transported to the CAPsMAN device encapsulated and encrypted in UDP with an internal information of the wireless interface they belong to, so VLAN tagging on transport between the AP and the CAPsMAN device is not necessary, and the eventual conversion of wireless interface (SSID) to VLAN ID, if necessary at all, can be done at the CAPsMAN device. So you can use a dumb switch to connect more APs to the CAPsMAN device if the bandwidth allows.
But maybe the VLANs may be omitted completely - if I got you right, the guest SSID will be L2-transparently connected to the LAN side of the ISP gear, which will provide DHCP etc. to the guests. So on the CAPsMAN you can use a dedicated bridge, let's say br-guest, and make the wireless interfaces with SSID guest member ports of this bridge along with the Ethernet port connected to the ISP gear. And the wireless interfaces with SSID "company" can be made meber ports of another bridge, on which the CAPsMAN device will provide DHCP, routing etc.
Regarding @anav's remark on using Mikrotik cAPs, the point is that recently several competitors provide better throughput on wireless APs than the Mikrotik devices, especially in the 5 GHz band. My private opinion is that this is only worth considering where the uplink bandwidth is so generous that the wireless throughput could become a bottleneck. So neither for a guest WiFi in a restaurant, nor for the mobile terminals used by staff to collect orders and payments, this should be any issue. Leaving aside that you'll have multiple APs and the uplink bandwidth will be shared by all of them. So two APs with 500 Mbit/s (which Mikrotik can easily do on 5 GHz) will consume all the bandwidth of a 1 Gbit/s uplink.
What can be an issue is the roaming speed as the waiters run fast between the hotspots. The roaming is not controlled by the APs but by the terminals, which monitor signal strength and switch over to better signal when available for long enough. But it is critical that forwarding to/from the individual wireless interfaces connected to a bridge is not suppressed, by some flavor of spanning tree protocol running on the bridge, each time the last station unregisters from the wireless interface and that interface thus becomes inactive. So if there is maximum one Ethernet port on the bridge, you can simply set protocol-mode to none on that bridge; if you need the spanning tree protocol to run on the bridge because there is more than one Ethernet, you have to configure the wireless ports as edge ones (and maybe some other settings are necessary too, I've seen something relevant here a few days ago) so that when the wireless port goes up again, the bridge starts forwarding immediately on it and doesn't watch for spanning tree BPDUs for some 15 seconds first.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.