Никита Сизов

Уверены, что не наоборот? Не сервер к кассам подключается, а кассы к серверу?
Если всё же кассы к серверу, надо настроить dst-nat на Микротике:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=***белый IP-адрес Mikrotik*** src-address=***белый IP-адрес первой кассы*** to-addresses=***внутренний IP-адрес сервера***
и для второй кассы так же.
На кассах нужно настроить адрес сервера = ***белый IP-адрес Mikrotik***
Все запросы от касс будут перенаправляться с Микротик на сервер через dst-nat.

Только вот эта строчка в вашем конфиге меня смущает
/ip address
add address=192.168.0.80 interface=ether1 network=192.168.0.80
но при этом
/ip route
add distance=1 gateway=212.46.253.97
Если вы так спрятали свой реальный IP, тогда ОК. А если нет, то сомневаюсь, что ваш конфиг рабочий.

Для отдельных приложений это будет сделать затруднительно.
Маршрутизация работает на сетевом (3) уровне OSI, а не на прикладном (7).
Но обычно эта проблема решается так:

• в клиенте OpenVPN уберите создание шлюза по умолчанию через удаленную сеть
  
• через route add настройте маршрутизацию на те хосты/подсети в удаленной сети, которые нужны вашим приложениям.
  

Обратить внимание нужно на функционал.
Но если вы ставите задачу таким образом - у вас расплывчатое представление о том, что могут и как используются свитчи. В этом случае для защиты инвестиций я бы посоветовал купить что-нибудь из цисковской серии для малого бизнеса. Функционал у них широкий, а понимание, как его использовать, придет позже.
Например Cisco SG500X-24 и SG500X-48. Они удовлетворяют всем вашим требованиям, но вылезут за рамки бюджета тысяч на 50.
Я бы хорошенько подумал вот над чем:
- реально ли всем пользователям нужен гигабит? и офис-менеджеру? и бухгалтеру? зачем? Не лучше ли взять один свитч Fast Ethernet для большинства пользователей и один Gigabit Ethernet для тех, кому действительно нужен гигабитный канал?
- так ли вам нужен 10Гбит канал до сервера? Я с трудом представляю приложения для малого бизнеса, где это нужно. Если одного гигабита однозначно мало - есть сетевые карты с несколькими портами и статическая агрегация каналов. Прикиньте, это может выйти значительно дешевле.

Любой QoS состоит из двух частей.
1. Отмаркировать интересующий трафик в /ip firewall mangle. Тут вам нужно проанализировать соединения на zoom.us и понять, как именно туда/оттуда передаются данные. Анализировать можно по-всякому - через текущие соединения на том же микротике, через Wireshark, как вам удобнее. Ниже пример, как я маркирую трафик для RTP-соединений с голосовым провайдером:
// маркируем соединения
/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=\
16384-16538 new-connection-mark=VOIP passthrough=no protocol=udp
// маркируем пакеты в этом соединении
add action=mark-packet chain=prerouting comment=VOIP connection-mark=VOIP \
new-packet-mark=VOIP passthrough=no

2. Создать правила приоритета для интересующего трафика. Это делается через очереди:
/queue tree
add name=queue1 parent=wan-interface priority=1 queue=default
add name=queue2 packet-mark=VOIP parent=queue1 priority=2 queue=default
add name=queue3 packet-mark=no-mark parent=queue1 priority=8 queue=default

Ну и еще несколько моментов:

• Надо понимать, что эффективно управлять вы можете только исходящим трафиком. Входящие пакеты находятся в вашей зоне влияния, когда они уже пришли, поэтому с ними не имеет смысла что-либо делать. Если, конечно, нет задержек в локальной сети, что встречается редко.
  
• Голосовая и видеосвязь критична к времени прохождения пакета. А т.к. zoom.us находится, судя по названию, за океаном, каждый пакетик по пути проходит много промежуточных устройств, на каждом из которых возможны задержки, которыми вы управлять никак не можете. Если вы устраиваете конференции с людьми из России - не лучше ли поискать что-то поближе? Если основная аудитория из США, тогда, конечно, придется терпеть.