Business guides

Compare two ways of doing it, before choosing

Each comparison sets out how the two approaches work day to day, what changes for your team and when the simpler one is enough. The bigger option is not always the better one.

Discuss your project Ask the adviser about your case

A PDF menu or an editable web menu
What to compare	PDF menu	Editable web menu
How it is updated	Someone edits the design file, exports a new PDF and replaces the old one. The QR code can stay the same if it always points to one fixed address.	Dishes and prices are changed in place, on the page or in an editing screen, and the change shows at the same address straight away.
Reading on a phone	The page is laid out like print, so guests often zoom and scroll sideways. A large file can be slow to open on mobile data.	Text fits the width of the screen and reads at a normal size. Sections and photos can be arranged for a phone.
Search and sharing	Search engines can read some PDFs, but each update is a new file, and one dish or section is hard to link to.	The menu is ordinary text on a page search engines read, and a section can be linked to directly.
Accessibility	Often hard for screen readers unless the PDF is carefully tagged. Text that is part of an image cannot be read aloud.	Real text and headings work with screen readers and larger text settings, when the page is built for it.
Who can change it	Whoever holds the design file. The business needs that file, or the designer, to make a change.	The people given access to the page or editing screen. Who that is should be agreed at the start.

When the simpler option is enough: A PDF is enough when the menu rarely changes, you already have a well-designed file, and guests mostly read it at the table.
What changes for your team: An editable menu needs someone to own the updates: prices, dishes that sell out, seasonal changes. It removes re-exporting files, but adds a small routine.
What O2 would check first: Whether the website you have can carry a menu page, who will keep the prices current, and whether the menu is needed in Thai and English. With a website you already have, O2's first step is to check whether a menu page can be added to it and opened from a QR code. Reading a menu does not need an ordering system.

A QR menu or QR table ordering
What to compare	QR menu (read only)	QR table ordering
What guests can do	Read the menu on their phone, then order with staff as they do today.	Choose dishes and options and send the order from the table.
Knowing the table	One QR code can serve every table.	Each table's code identifies the table, so staff know where each order goes.
Where the order goes	Nothing is sent. Staff take the order.	The order reaches a staff screen, where it is accepted and its status kept up to date.
Work for the team	Service stays as it is. Someone keeps the menu current.	Someone watches for new orders and requests during service, and marks dishes that sell out.
Payment	Unchanged.	A separate decision. Ordering can work with payment at the counter as today.

When the simpler option is enough: If guests are happy to order with staff, and the problem is an outdated or hard-to-read menu, a QR menu is enough.
What changes for your team: Ordering adds a workflow the team must run during service: accepting orders, updating their status and keeping sold-out dishes off.
What O2 would check first: How orders reach the kitchen today, whether another system must receive them, and who would watch the staff screen at busy times. In O2's QR table ordering, payment at the table is included only where the scope includes it.

A booking request or a confirmed booking

A booking request or a confirmed booking
What to compare	Booking request	Confirmed booking
What the customer sends	A preferred day and time. The business replies to confirm or suggest another.	A slot chosen from what is free. It is booked at once.
Where availability comes from	Staff keep it, in a book, a calendar or their head. Nothing has to be connected.	The system must know the real availability of people, rooms or tables at all times.
Capacity	Staff decide case by case.	Rules decide: slot length, gaps between bookings, how many at once.
Changes and cancellations	Handled in conversation with staff.	Follow rules the business sets, and staff can still step in.
What can go wrong	A slow reply can lose the customer.	Availability that is wrong leads to double bookings.

When the simpler option is enough: A request is enough when bookings are few, each needs a person's judgement, or availability lives somewhere that cannot be connected.
What changes for your team: Confirmed booking moves the work from replying to keeping availability right: schedules, days off and resources must be kept current.
What O2 would check first: Where availability lives today, which calendar or system must stay the source, and which bookings always need a person to approve. In O2's online booking, whether a booking is confirmed at once or reviewed by staff is decided in scoping.

The screens a product comes with, or a dashboard across systems

The screens a product comes with, or a dashboard across systems
What to compare	A product's own staff screens	A dashboard across systems
What it is for	Running one system: its menu, products, bookings or orders.	One view of work spread across several systems: bookings, orders, enquiries and staff tasks.
Where the data comes from	The system's own records.	The systems it is connected to. Each source has to be checked before it can be shown.
How current it is	Always current for that system.	As current as each connection allows.
Who uses it	The people who update and run that system.	Owners and managers who need the overall picture.
What it takes	It comes with the product.	Work scoped for each source and each view.

When the simpler option is enough: If you mainly need to update a menu, products or bookings in one system, the screens that system comes with are enough.
What changes for your team: A dashboard is only as useful as the decisions made from it. Someone has to own the numbers it shows and act on them.
What O2 would check first: Which systems hold the numbers you look at, whether each can be read, and which decisions the view should help with. O2's business dashboard gives one view across the systems it is connected to. Each source is confirmed in scoping.

Fixed LINE replies or an AI assistant

Fixed LINE replies or an AI assistant
What to compare	Fixed replies	AI assistant for LINE
How answers are written	You write each reply in advance, using LINE's own auto-reply and keyword tools.	Answers are composed from information you approve.
Different wordings	Only a message that matches a keyword or rule gets its reply. Anything else gets a default message.	Different ways of asking the same question can be answered, in Thai and English.
Risk of a wrong answer	Wrong only if the written reply is wrong or the wrong keyword fires.	Can be wrong. Answering only from approved information, handing unsure chats to staff and reviewing conversations limit that.
Handing over to staff	Staff read the chats as they do today.	The chat is handed to staff with what was said so far.
Keeping it right	Replies are edited by hand when something changes.	The approved information is kept current, and the conversations are reviewed.

When the simpler option is enough: If customers ask a handful of questions in predictable words, LINE's own auto-replies may be enough.
What changes for your team: An assistant takes the repeated questions, not the team's judgement: someone approves what it may say and picks up the chats it hands over.
What O2 would check first: What customers ask most, how often, which questions must always go to a person, and who on your team approves the answers. O2's AI assistant for LINE is a monthly service. It is a new product: no client is using it yet.

Not sure which side you are on?

Tell us how the work runs today. We will say plainly whether the simpler option is enough.

Discuss your project Help me choose