Generic point-of-sale software was built for restaurants and retail. It assumes a customer walks in, picks an item, pays, and leaves. Snooker and billiards venues are nothing like that. Sessions can run for two hours. Frame counts change mid-game. Credit tabs roll for weeks. Tournaments need brackets and prize-pool maths. None of this fits a Square or a Petpooja screen, and the workarounds are where most clubs leak money. This is how we'd evaluate software if we were buying it today.
Why generic POS systems fail at billiards
The mismatch is structural, not cosmetic:
- Sessions, not transactions. A billiards bill is assembled over time: frames played, food ordered, credit settled. Generic POS treats every "item" as instant. You end up with one customer creating eight cart entries during a single session -- and reconciling them at checkout is a daily fight.
- Table-level state. Your inventory is rooms, not products. Generic POS has no concept of "Table 3 is currently in use by Rohan's party, started 8:14pm, 4 frames played, on credit."
- Credit ledger. Most generic POS systems do not carry a per-customer balance. You can't track who owes what across visits. Clubs that try to manage credit in restaurant POS end up with a separate notebook anyway.
- Tournaments. Brackets, seeding, match scoring, prize pools -- generic POS has no concept of any of this.
The criteria that actually matter
1. Table / court as a first-class object
Each table or court in your venue needs its own page in the software -- pricing, current session, history, maintenance status. Without this, your daily reports can't answer the obvious question: which table is making you money?
2. Both pricing models, on the same shop
Per-frame for snooker, per-hour for pool, slot-based booking for badminton or pickleball. The right software handles all three without forcing your shop into two separate systems with two separate cashbooks. (Strikee does this -- see the features page.)
3. A real credit ledger
Per-customer credit balance, credit limit, payment history, and settlement tracking. Plus: when a customer pays off ₹500 of credit, that ₹500 should automatically appear in your daily revenue -- not sit in some "adjustment" ledger you reconcile monthly.
4. Cashbook discipline
The cashbook is the spine of any venue. It needs daily summaries, per-payment-method breakdowns (cash / UPI / card / credit), and a clear net total. Bonus points if it respects a sane "business day" boundary (Strikee uses 5am IST → following 5am IST, so a Saturday-night-into-Sunday-morning rush rolls up to Saturday's number -- not Sunday's).
5. Tournaments built in
If you run any tournaments at all, you need software that handles the bracket as a native concept -- not a Google Sheet linked from the manager's phone. That means knockout and round-robin generators, match scoring with auto-advance, prize-pool tracking, and ideally a public bracket page you can share on WhatsApp.
6. Multi-user roles
Owner, manager, marker, cashier. Each role sees what it needs, nothing more. A staff member should not be able to delete a credit balance. An owner should be able to see daily P&L without digging through ten screens.
7. Works on a phone
Your floor staff don't sit at a counter. The interface needs to work on a 5-inch screen in a marker's back pocket, with one hand, in dim lighting. Desktop-only software is a non-starter.
8. Owns your data, doesn't take a cut
Avoid software that takes a percentage of your customer payments. Your customers should pay you directly (cash, UPI, card to your own terminal). The software's job is to track what came in -- not sit in the payment flow and slice a fee.
Quick comparison
Below is a high-level view of how the options stack up for a typical Indian snooker / pool / multi-sport venue. Specifics differ by plan and region -- verify with the vendor before signing.
| Capability | Generic POS | Restaurant POS | Strikee | |---|---|---|---| | Table as first-class object | ❌ | Partial (as table number only) | ✓ | | Per-frame + per-hour pricing | ❌ | ❌ | ✓ | | Slot-based court bookings | ❌ | ❌ | ✓ | | Per-customer credit ledger | ❌ | Partial | ✓ | | Tournament brackets | ❌ | ❌ | ✓ | | Public tournament pages | ❌ | ❌ | ✓ | | Mobile-first interface | Varies | Varies | ✓ | | Takes % of customer payments | Often yes | Often yes | No |
How to test before you commit
Whatever software you evaluate, run it through these five drills:
- Start three concurrent table sessions, record per-frame play, take a partial cash payment, partial credit. Can the software produce one clean bill?
- Settle a customer's credit two weeks later. Does the ₹500 settlement show up correctly in today's daily revenue?
- Run a mini 8-player tournament. Can you generate the bracket, score matches, and produce a winner -- without spreadsheets?
- Close out a Saturday night that crossed midnight. Does the cashbook treat it as one business day?
- Pull up "revenue by table this month" on a phone screen in under 10 seconds.
Why we ended up building Strikee
We tried every option above before building our own. Each one treated billiards as a special case of restaurant or retail software. None of them got the credit ledger right. None of them could run a tournament. All of them assumed someone would close the day on a desktop, not from the floor.
Strikee was built from the first day around the idea that snooker / pool / multi-sport venues are fundamentally session-based, and that the cashbook is the centre of gravity. If that resonates, the free trial takes about 20 minutes to set up.