TABLEMASTER

Competitive teardown · Linear TM-151 · PokerAtlas TableCaptain 2

What TableCaptain actually ships.

A feature inventory of the competitor's floor-management desktop app, read frame by frame off six silent screen recordings. Every item below was visible on screen. Nothing is inferred from marketing copy.

ProductTableCaptain 2

VendorOverlay Gaming

Build shown2.0.5 / 2.0.6

Videos6 · 11 min

Frames read270

Compiled31 Aug 2026

Read this first: the footage is old

The app in these videos reports version 2.0.5 and 2.0.6. But the vendor's own back-office screen, visible in video 6, lists client builds all the way to 2.4.1, with build dates through October 2024. So these recordings show a build the competitor had already moved past when the videos were made, and it is now roughly two years stale.

Treat this as a floor, not a ceiling. Anything listed here, they have. Things they have added since will not appear.

How to read the confidence tags

Demonstrated means the screen was opened and operated on camera, so the feature list is reliable. Named only means the item appears in a menu or a label but was never opened, so we know it exists and nothing more.

All six recordings are silent. No narration, no captions. Everything here is read off pixels, so intent and workflow rationale are absent by design.

The core: waitlist and floor

4 modules

This is the product's centre of gravity, and where a head-to-head comparison matters most. It is also the most thoroughly demonstrated part of the footage.

Waitlist board

WaitlistDemonstrated

A horizontally scrolling grid, one column per game. This is the screen a floor person lives in.

One column per game, each headed with stake, variant and flags: $2/5 NLH MM with a MUST MOVE banner, $4/8 LHE with a $40+ qualifier.
Per-column counters in the sub-header: waiting count, transfer count, alert count, and the list of table numbers running that game.
Numbered positions 1 through 18 visible, with a +11 overflow chip when the list runs longer than the screen.
Bulk action rail per column: Multi Select, Select All, Reorder, Page, Arrive, Remove, Top, Bottom, Copy, Clear List.
Named list views in the left rail ("Medium-Rare Steaks", "High Stakes", "Low Stakes"), so a room can slice its games into saved boards.
Clear-whole-list action with a confirm dialog naming the game.
Player search box and an ADD PLAYER entry point above the grid.
Empty state is handled: "There Are No Games Assigned To This View".

Player record

Waitlist › PlayerDemonstrated

The richest screen in the footage, and the one with the most features we should measure ourselves against.

Multi-list enrollment. One player sits on many game lists at once. The panel shows a Waitlists (3) count and every game as a chip. The demo account showed eleven games including Stud, PLO, Mixed and Pai Gow.
Position display as a fraction: 1/1, 1/2, 2/2. Position within the list, across lists.
Live wait timer counting up beside the join time, plus a separate paged-for timer once a player is paged.
Contact method dropdown: In Person, Phone-In, Transfer.
SMS phone field with a country-code picker.
Patron profile card: Name, D.O.B, player Number, Role, Tier, and an Alerts row. Loyalty tiering and staff warnings on the same panel.
Link PokerAtlas button, tying the floor entry to the player's account on their consumer network. This is their structural advantage, not a feature we can copy.
Current and Requested location, each opening a picker with a table grid and a visual seat ring: numbered seats around the dealer position, clicked directly.
Row actions: Page / Unpage, Arrive, Top, Bottom, Remove, Seat.
Page from a named table, so the page dialog takes an optional table and the call names where to go.
Must Move set per player as well as per table.
Free-text note per entry, and an audit footer showing Created, Employee and Client.

Tables view

TablesDemonstrated

The live floor, drawn to scale, doubling as the room's status board.

Two colour modes, toggled: VIEW GAME COLOR and VIEW OCCUPANCY. The same floor read either by what is being dealt or by how full it is.
Active tables counter (10/10) in the header, turning red at capacity.
Open Seats panel: one card per game listing exactly which table numbers have a seat free right now.
Requests rail down the right side, colour chips for every open service request, by table.
Tables render with real geometry, seat positions, the dealer seat marked, stake printed beneath, and an MM badge on must-move tables.

Table operations

Tables › Table detailDemonstrated

Everything a floor person does to one table, from a single screen.

Open / Close table. The open dialog assigns a game and sets paging behaviour in the same step: Page Next Available Patrons versus Do Not Page Waitlist Patrons.
Move Table, Change Assigned Game, Lobby All, Award All.
Service request bar as first-class buttons: Chips, Drinks, Massage, Security. These raise the coloured chips seen in the Requests rail.
Must Move toggle with confirm, and View History per table.
Seat-level selection: click a chair, act on that seat.
Dealer shown on the table (the demo sat at "No Dealer").
Audit strip along the bottom: Opened, Running, Employee, Client, Last Modified.
Every destructive action is behind a named confirm dialog that states the consequence.

Signage and player-facing display

2 modules

A larger subsystem than expected. This is a whole product inside the product, and worth a close look on the marketing side.

Displays

DisplaysDemonstrated

Public waitlist boards for screens on the poker room wall.

Named launchers. A room defines display configurations ("Poker Floor", grouped under "High Stakes") and launches each to its own screen.
Four ways to deploy one board: COPY URL, EXPORT LAUNCH SHORTCUT, EXPORT .BAT FILE, LAUNCH DISPLAY. The .bat export is a Windows-only kiosk convenience.
Boards are plain web pages served from Azure static hosting, so any browser or smart screen can show one.
Board layout: venue logo, a "Register Online @ Here" header with a QR mark, one column per game showing stake, variant, WAITING: N and the queued names, plus a scrolling marquee across the bottom.
The QR-to-register header is a self-service funnel straight off the wall screen.

Marquees

MarqueesDemonstrated

The content engine behind the boards. More sophisticated than a text field.

Typed message records in a managed grid. Each row has a Tag, a Type, a Name and a Value.
Five content types seen: Text, Jackpot, Rotation, Venue, and DynamicString.
Live jackpot templating. A jackpot row binds to real values. An Omaha High Hand entry pulled Prize, LatestHandDisplayName and DisplayName. A "Ferrari Giveaway" promo bound Name, Rules and Prize.
Clock marquee as its own configured item.
Rotation type for cycling messages.
Full grid tooling: New, Edit, Filter, Layouts, Delete, Export, Import, Refresh, with pagination.
A separate String Editor for long-form copy.

Configuration and staff

2 modules

Floor map editor

Administration › Floor MapDemonstrated

The room builds its own floor plan. No vendor setup call needed.

Drag and drop placement on a dotted grid canvas, both directions. Drag a table onto the floor, drag it back off into the tray.
Two table kinds: ADD POKER TABLE and ADD PIT TABLE.
Sections as a second tab beside Floor Map, so the floor divides into named areas.
"Now Editing: Entire Floor" scope indicator.
Canvas controls: Zoom In, Zoom Out, Recenter, plus Remove and Edit on a selected table.
Explicit edit mode with SAVE FLOOR MAP and cancel, so changes are staged, not live.
Tables carry Active / Inactive state and render their seat count and dealer position.

Employees and access control

Employees › User ManagementDemonstrated

A full HR-adjacent staff directory, not just a login table. The grid held hundreds of rows.

Staff directory grid: Employee #, Last Name, First Name, Login, Department, Title, Roles, # Of Roles, Last Edit. Sortable, filterable, with a Change Log.
Role-based access control. Roles seen assigned: System Administrator, System Manager, Tournament Director, WaitList. A separate Roles Management screen defines them.
Two credentials per person: a username and password for the app, plus a separate User ID and Transaction PIN for cage and cashier actions.
Badge workflow: ATTACH BADGE on the record, PRINT CARD to issue it, and a Scan Employee screen to read it.
Photo capture in-app. Take Picture during creation, Take Photo on the record.
Per-employee Audit Trail and Activity tabs, plus a Notes tab.
Guided Create New User wizard across four steps: Profile, Access, Security, Contact.
Full contact record: address, emergency phone, email, shift, department, comments.
Deactivate rather than delete.

Platform and operations

Vendor-side

Video 6 accidentally exposed the vendor's own back office. This is not customer-facing, but it tells us how they are built and how they ship.

Delivery and tenancy

patcadmin · back officeDemonstrated

Installed desktop app, not a browser app. It has a connection-settings step naming a venue endpoint, then a login.
Windows and Mac builds. Every version row in their table carries both a Windows URL and a Mac URL.
Central auto-update. An "Active" checkbox per version decides what clients pull.
Multi-tenant by Venue, with Configurations, Features and Components as separate per-venue controls. That reads as feature flagging per room.
Hosted end to end on Azure: app service back office, blob static hosting for both the client builds and the display boards.
Vendor of record is Overlay Gaming. PokerAtlas is the brand on the glass.

Named in the menus, never opened

22 items

The navigation menu and the Administration submenu were both captured in full. These items exist in the product. The videos never opened them, so we know the name and nothing else. This is the highest-value list for deciding what to investigate next.

CashierCage and chip transactions. Pairs with the Transaction PIN.

Dealer RotationDealer scheduling and push. A whole product area.

TournamentTournament running. Pairs with the Tournament Director role.

Table ManagementIts own top-level section, separate from Tables.

AnalyticsSits under a "Reports" heading in the waitlist rail.

PromotionsUnder Administration. Likely feeds the jackpot marquees.

DevicesHardware registry: screens, scanners, printers.

Scan ReceiptSuggests printed receipts or tickets somewhere in the flow.

VenuesMulti-property support inside one install.

Game GroupsHow games are bundled into the named list views.

Game MaintenanceDefining the games themselves.

Game TypeVariant taxonomy behind the game definitions.

Config OverridesPer-room deviation from defaults.

DeductionsRake, jackpot drop, or payroll. Unclear which.

Dropdown MaintenanceCustomer-editable picklists across the app.

Audit LogsSystem-wide, on top of the per-record audit trails.

Patron MastersThe player database behind the profile card.

Feature MastersLikely the customer-side view of the feature flags.

SecuritySeparate from Roles Management. Policy, probably.

Roles ManagementDefining the roles seen assigned in video 5.

DiagnosticSupport and troubleshooting tooling.

Waitlist DisplaysA third display surface, distinct from Displays and Marquees.

UI observations

Secondary goal

Worth stealing, and worth avoiding.

Take

The visual seat ring

Every place the app needs a seat, it draws the actual seat ring, numbered chairs around a marked dealer position, and you click the chair. It appears in Seat Player, Current Location and Requested Location, identically each time.

Why it works: a floor person already holds a spatial picture of the table. A dropdown of seat numbers forces a translation step; the ring does not. And re-using one component across three dialogs means it is learned once.

Take

Two readings of one floor

The VIEW GAME COLOR / VIEW OCCUPANCY toggle re-colours the same floor map to answer two different questions without changing screens.

Why it works: "what is running where" and "where is there room" are the two questions a floor person alternates between all shift. One map, two lenses beats two maps.

Take

Decisions bundled into the action that needs them

Opening a table asks for the game and the paging behaviour in the same dialog, as two large labelled choices rather than a checkbox: Page Next Available Patrons or Do Not Page Waitlist Patrons.

Why it works: the setting is presented at the only moment it matters, written as an outcome rather than a toggle state. Nobody has to remember a preference set elsewhere.

Take

Confirm dialogs that name the consequence

Not "Are you sure?" but "This action will make the table unavailable for the selected game", and "the request cannot be reversed and the request will be removed from the queue".

Why it works: on a busy floor the dialog is read at a glance or not at all. Naming the specific consequence is the only thing that makes the pause useful.

Take

Two timers, not one

A player entry carries a wait timer counting from when they joined, and a second timer starting when they were paged.

Why it works: these are different service questions. "How long have they waited" is fairness. "How long since we called them" is whether to give the seat away. One clock cannot answer both.

Take

Audit metadata on every record, in the same place

Table detail, player entry and employee record all end with the same footer strip: Created, Employee, Client, Last Modified.

Why it works: in a regulated room, "who did this and from which terminal" is a question that gets asked. Putting it in a consistent place on every record makes it answerable without a support call.

Leave

The rainbow action bar

The table screen ends in eight buttons in eight different saturated colours, red, blue, purple, magenta, orange, dark red, grey and green, sitting side by side with no grouping.

Why it fails: when everything is coloured, colour stops meaning anything. Destructive Close sits beside routine Drinks at equal weight. Group by kind, and let colour mark only what is destructive or primary.

Leave

Density with no visual hierarchy

The waitlist grid and the employee directory both present as flat spreadsheets: uniform row height, uniform weight, no zebra striping, no grouping, no emphasis on the row that needs attention.

Why it fails: the data is dense enough to need help. Nothing in the grid pulls the eye toward the player who has waited longest or the table that is short.

Leave

Two visual languages in one product

The floor screens are a dark navy custom app. The admin screens are a light, generic enterprise data grid, complete with "Drag a column header here to group by that column" and a Column Chooser.

Why it fails: it reads as a purchased grid component dropped into a custom shell. Crossing from Waitlist into Marquee Admin feels like changing products, which undercuts the polish of the floor screens.

Source footage

6 files

File	Length	Frames	Covers
YT rec 1	0:57	17	Nav menu, Administration menu, Floor Map editor
YT rec 2	1:59	34	Tables floor view, table detail, open/close, requests
YT rec 3	2:33	36	Waitlist grid, player record, seat and location pickers
YT rec 4	1:46	81	Displays, launchers, board layout, Marquee admin
YT rec 5	1:51	40	Employees, user management, roles, security
YT rec 6	1:39	62	Auto-updater, login, vendor back office

TableMaster · Competitive teardown · TM-151 31 August 2026 · Internal 270 frames read at 1600px · build shown 2.0.5 / 2.0.6