Zoom and Teams meeting controls on one flick — a radial menu layout

Every meeting on a Mac has the same small problem. You are full-screen in Zoom or Teams. Someone says your name. You need to unmute, and the controls are either hidden behind a mouse-wiggle to surface the chrome, or behind a key combo you have to remember — Cmd+Shift+A in Zoom, Cmd+Shift+M in Teams. Two clients, two combos, and that is just for mute. Camera, raise hand, share, leave — every control has its own combo, and they do not match between apps.

The fix most people reach for is "memorize one set." That works until you switch apps. The fix this post is about is different: wrap each meeting control in a one-step Apple Shortcut, wire each Shortcut to a Swik wedge, and forget the key combos entirely. You hold the trigger, flick toward "mute," release. The wedge does not care which client is in front.

To be clear up front: Swik does not have a built-in Zoom or Teams integration. There is no plugin, no API hook, no special "meeting mode" button. What it does have is a "Run Shortcut" wedge action and a couple of context features. The integration is something you build in five minutes using Apple Shortcuts as the bridge.

Why a radial menu fits meeting chrome specifically

Meeting controls have a few things in common. There are five or six of them, they are all toggles or one-shot actions, and you reach for them under mild stress — someone is waiting, the screen is full, and you do not want to fumble. That is exactly the shape of task radial menus were designed for.

The chrome solution is the worst of both worlds. You move the mouse to surface the toolbar, then your eyes hunt for the right icon, then you click. The keyboard solution is faster but requires recall: which app am I in, and what is its mute combo? A radial menu collapses both to a single direction. North is mute. East is camera. South is leave. Your hand learns the layout in a day, and the layout works whether you are on Zoom, Teams, or Google Meet because the wedge does the translation.

The current state of meeting shortcuts

It is worth grounding this in what the apps actually expose today. Zoom on macOS uses Cmd+Shift+A to toggle mute, Cmd+Shift+V to start or stop video, and Option+Y to raise or lower your hand. Microsoft Teams on macOS uses Cmd+Shift+M for mute, Cmd+Shift+O for camera, and Cmd+Shift+K for raise hand. None of them line up.

Neither client publishes a stable URL scheme or a public AppleScript dictionary for in-meeting controls. Community workarounds exist — short AppleScripts that target the menu bar items via System Events, for example — but the official, supported path is the global keyboard shortcut. That is what the Apple Shortcut wrappers in this guide will fire.

Step one: build the meeting Shortcuts

Open Shortcuts.app and create a new Shortcut for each control you care about. The simplest version uses one action: Run AppleScript, which sends a key command to the frontmost app. A "Mute Zoom" Shortcut looks like this:

tell application "System Events"
  tell process "zoom.us"
    keystroke "a" using {command down, shift down}
  end tell
end tell

Save it as Mute Zoom. Repeat for each control: Camera Zoom sends Cmd+Shift+V, Raise Hand Zoom sends Option+Y, and so on. Make a parallel set for Teams targeting "Microsoft Teams" with its own combos.

If you only ever use one client, stop here — you have six Shortcuts and you are ready to wire them to wedges. If you switch between clients, do one more step.

Step two: one Shortcut, both clients

This is where Apple Shortcuts earns its keep. Build a single Mute Meeting Shortcut that checks which app is frontmost and routes accordingly. Use a Get Name of Frontmost App action followed by an If block: if it is zoom.us, run the Zoom mute AppleScript; if it is Microsoft Teams, run the Teams one; otherwise do nothing.

You now have one Shortcut per concept — Mute, Camera, Raise Hand, Share, Leave — instead of two per concept per app. Wire each concept to a single wedge. The wedge does not need to know which client you are in. The Shortcut figures it out.

This pattern extends to any new meeting client you add later. Add a Google Meet branch, an in-browser Zoom branch, a Webex branch — the wedge stays the same, the Shortcut grows.

Step three: wire the Shortcuts to Swik wedges

In Swik, create a new profile called Meeting. For each wedge, choose Run Shortcut as the action and type the exact name of the Shortcut you built. Names are case-sensitive and must match exactly, so Mute Meeting is not the same as mute meeting.

A six-wedge meeting layout does the job for most calls:

Six wedges leave plenty of angular room for clean flicks. If you use a particular client heavily, drop the cross-app routing and have Mute Zoom on a wedge directly — it is one fewer Shortcut step and a hair faster.

Step four (optional): auto-load the meeting profile

Swik profiles can switch automatically based on Wi-Fi network, connected display, or time of day. None of those map cleanly to "I am in a meeting," but they are usable proxies.

The cleanest workaround is time-of-day. If your standing meetings cluster in a known block — say weekday mornings 9:00 to 11:00 — set the Meeting profile to auto-load during that window and your everyday layout outside it. You will not always be in a meeting at 9:30, but nothing about the layout breaks if you trigger Swik between calls; the wedges just do not do anything until you next join.

If you have an external monitor you only plug in for calls, the display trigger is even better. Plug in, profile flips. Unplug, it flips back. This is one of the few cases where Swik's context profiles do most of the work for you.

What Swik cannot do today is detect "Zoom is in a meeting" as a trigger. There is no public hook for it, and adding one would mean polling private state in a third-party app. The pragmatic answer is: keep the Meeting profile one wedge away in your everyday menu, or use a time block.

A few things to know

System Events needs Accessibility permission. The first time you run an AppleScript that sends keystrokes, macOS will prompt you to grant Accessibility access to Shortcuts.app (or to whichever app is hosting the script). Approve it once in System Settings → Privacy & Security → Accessibility. Without this, the keystrokes silently fail.

The frontmost-app check matters. If you flick "Mute" while Slack is in front, the AppleScript will send Cmd+Shift+A to Slack, which selects all messages in the active channel. The If block in step two prevents this — without it, mute fires into whatever app you happen to be looking at.

Browser-based meetings are different. Zoom and Teams in a browser tab use different shortcut conventions (often the web app's own combos, which differ from the desktop client). If you live in browser meetings, build a third branch in your Mute Meeting Shortcut that matches your browser's bundle identifier and sends the web shortcut.

Reactions, recording, and other niche controls work too. Anything Zoom or Teams binds to a global keyboard shortcut can be wrapped in a Shortcut and put on a wedge. Recording in Zoom is Cmd+Shift+R; spotlight a participant is Cmd+Shift+T. The pattern is the same — build a Shortcut, name it, wire it.

Why this is worth the setup

The end result is a small thing that compounds. You stop moving the mouse to surface meeting chrome. You stop flinching at the wrong combo. You stop apologizing for the "sorry, I was muted" beat that every other call has. You hold the trigger, flick north, and the meeting does what you wanted it to do, in either client, full-screen or not.

Five to ten Shortcuts and twenty minutes of setup. The wedges live in their own profile, out of the way of your everyday layout, until the moment you need them. Then they are exactly where your hand learned to put them.