Integrated portals, direct bookings and PWAs

01One portal, one place for the data

Look at how a small business that sees customers by appointment works today: a paper diary or one on the phone, a spreadsheet with the contacts, requests arriving on WhatsApp, by email, by phone and from one or two booking platforms, each with its own panel. Every channel holds a piece of the truth; none of them holds all of it.

A scene you may recognize: it is Saturday morning, a customer walks in smiling for her ten o’clock appointment. Too bad that at ten there is already someone else, booked by a colleague over the phone while the first had written on WhatsApp. Nobody really made a mistake: the two diaries simply did not talk to each other.

The result is familiar: the same slot given to two people, the regular customer who is not recognized, the phone number that exists only on the mobile of whoever answered, the afternoon spent copying data from one place to another. And above all: nobody really knows how many customers the business has, how many come back, where they come from.

An integrated portal turns the pattern around. There is a single archive, on your server, from which the website, the bookings, the customers’ private area, the automatic emails and the links to the management system all start. Every channel writes to the same place, every staff member sees the same situation at the same moment.

What changes, in practice

• One record per customer: history of visits, preferences, consents, documents, all in the same place.
• Real availability: if the staff blocks a slot in the management system, the website stops offering it, at the same moment.
• Less repeated work: confirmations, reminders and receipts go out on their own, because the system knows what happened.
• Real numbers: how many new customers, how many come back, which services pay best, which channel they come from.

For all this to hold up you need a suitable foundation: a portal with logins, bookings and scheduled jobs needs a server with reserved resources, as I explain in the chapter on professional web infrastructure.

02Direct bookings: no commissions, your own data

The big booking platforms have one real merit: they bring visibility. But the service has a price, and not only in money. Every booking that goes through an intermediary carries three costs.

1. The commission on every customer, even those who were already yours

The intermediary keeps a percentage of every booking, according to the contract you signed. You pay it on the new customer, and that is fine; but you also pay it on the regular customer who already knew you and simply used the app they had on their phone. With a booking system on your own site, a returning customer costs no commission.

2. The relationship with the customer stays with the intermediary

Whoever books on a platform is first and foremost a customer of the platform. The rules on what data you receive, how you can contact them and what you can offer them are decided by whoever runs the service. With direct bookings, the customer leaves their data with you, with their consent, and you can write to them again: for the next season, for something new, to say thank you.

3. Availability you keep chasing

More booking channels mean more calendars to keep aligned. If the alignment is not immediate, the risk of a double booking appears: two people, the same place, the same time. Your own portal is the only true calendar: any external platforms sync with it, not the other way around.

This is not about abandoning the platforms overnight: for many businesses they remain a useful channel for getting known. It is about turning every customer who arrived from outside into a direct customer for the next time, with a system of your own ready to welcome them.

03Security of the portal and the management systems

A portal that collects names, phone numbers, emails, dates of birth, sometimes documents and preferences, holds personal data. The European General Data Protection Regulation (GDPR), in Article 32, requires those who process it to take technical and organizational measures appropriate to the risk, expressly mentioning encryption, the ability to ensure confidentiality and availability and to restore the data after an incident. This is not bureaucracy: it is the description of well-made software.

Layer 1 · The road: HTTPS on everything

All traffic between the customer’s phone and the server travels encrypted with the HTTPS protocol (TLS): someone on the same public Wi-Fi network can neither read nor modify what passes through. Today the certificate is obtained and renewed automatically; a site without HTTPS is flagged by browsers as “not secure” and, as we will see, cannot even become a PWA. How domain and certificate work I explain in the chapter on domain, DNS and HTTPS.

Layer 2 · The door: who gets in and how

Customers’ passwords are never stored in readable form: only a fingerprint (a hash) is kept, calculated with algorithms designed for the purpose, from which the password cannot be derived. For the staff, who see everyone’s data, two-factor authentication is added. The complete rules are in the chapter on passwords, two-factor authentication and passkeys.

Layer 3 · The code: no commands slipped into the forms

Every field the customer fills in, from the name to the message, is a point from which someone can try to send instructions to the database: this is SQL injection. The first defense recommended by OWASP is parameterized queries, in which the value typed by the user always remains data and never becomes part of the command. On top of this come the validation of every incoming piece of data, the protection of forms against automated submissions and limits on repeated attempts.

Layer 4 · The archive: less data, fewer permissions, off-site copies

• Minimization: you collect only the data you really need. What you do not have cannot be stolen from you.
• Least privilege: the program accesses the database with a user that can do only what is needed, not with the administrator.
• Encryption of sensitive data even when it is at rest on the disk.
• Automatic backups that leave the server, tested with a real restore: the method is in the chapter on business backup.

Above all of this come the obligations toward people: a clear privacy notice, separate consents for marketing, the right to request one’s own data or have it deleted. I return to them in the chapter on GDPR and cookies for a small business website.

04PWAs: the app that installs from the browser

For years there was only one road to having “an app”: develop it twice, once for iPhone and once for Android, publish it on the stores, wait for approvals, ask customers to download it. A PWA (Progressive Web App) changes the rules: it is your website, built so that it can be installed on the phone like an app, with its own icon, its own full-screen window and, when needed, the ability to work without a network.

What a site needs to become a PWA

According to Mozilla’s documentation (MDN), to be installable a web app needs two things:

• a manifest, a small file that declares the name, the icons (at least 192 and 512 pixels for Chromium-based browsers), the start page and the display mode;
• to be served over HTTPS, that is, over an encrypted connection.

To these is almost always added a service worker: a script that works behind the scenes, keeps a copy of the pages and of useful data, and lets the app open even when there is no network. It is not mandatory for installation, but it is what makes a PWA truly useful in the real world: the customer who opens their booking on the subway, the waiter who checks the menu in a room with no signal.

PWA and native app compared

For the vast majority of the services of a small or medium business (booking, checking a menu, seeing one’s appointments, receiving a reminder, showing a loyalty card) a PWA does everything that is needed, at a fraction of the cost and with far fewer steps. A native app remains the right choice when deep access to the hardware is needed or when being in the store is itself a goal.

05The truth about iPhone and Android

Honesty is needed here, because many presentations of PWAs skip it: the experience is not identical on the two systems, and a serious project takes this into account from day one.

On Android: the browser offers it by itself

On Chromium-based browsers, such as Chrome and Samsung Internet, when a site meets the requirements of a PWA the browser can offer installation with a prompt or with the “Install app” item in the menu. With Chrome the installed app appears among the phone’s other apps, with its own icon. The site can also show its own “Install” button at the right moment, for example after the first booking.

On iPhone and iPad: it is added by hand

On iOS and iPadOS there is no automatic installation prompt. The customer has to do it themselves, in four gestures:

This is why a well-made PWA recognizes the iPhone and shows, at the right moment, a small box with these steps illustrated. It is a design detail that makes the difference between a PWA nobody installs and one that ends up on the screens of many customers.

Notifications on iPhone: only after installation

Since version 16.4 of iOS and iPadOS web apps can also receive push notifications, but under two precise conditions, described by Apple itself on the WebKit blog:

• the web app must have been added to the Home Screen: from an ordinary Safari tab notifications cannot be turned on;
• permission is requested only after a user gesture, for example a tap on a “Notify me” button.

A practical rule follows: notifications are a reward for those who install, not the reason to install. The service must be useful even without them.

06The QR in the window: from the sidewalk to the customer’s phone

And here we come to the strategy that joins the physical world to the digital one, and costs very little: a QR code displayed in the window of the shop, the studio or the restaurant, which takes passers-by straight into your PWA. It is the shortest bridge there is between someone walking past your door and a customer who finds you again every time they open their phone.

It works because today phone cameras read QR codes on their own, with no app to download: you point, the link appears, you tap. It works even when you are closed: the window is at work at ten in the evening and on Sunday morning.

Step 1 · The QR leads to an address of your own that will not change

The QR code is printed: once it is in the window, you will not change it again. This is why it must contain an address on your own domain, designed to last, such as yoursite.com/window, which the server then redirects to the right page. If tomorrow you change your offer, you change the destination on the server, not the sticker. Never a QR that points to a third-party service that may shut down or ask for a subscription to keep working. Why the domain must be registered in your name I explain in the chapter on who really owns your website.

Step 2 · A reason to scan it

Nobody scans a little black square out of curiosity. Next to the QR you need a sentence that says what you get, right away: “Book your table even when we are closed”, “Today’s menu on your phone”, “Book your next visit in ten seconds”, “Your loyalty card always with you”. One concrete promise, just one.

Step 3 · The QR must actually be readable

• At eye level, where the gaze naturally falls, not down low among the credit card stickers.
• Large enough to be scanned from the sidewalk: before printing it, try it yourself with two different phones from the distance at which passers-by will stand.
• Sharp contrast: dark on light, with a white margin around it, away from reflections and dirty glass.
• Lit in the evening too, when the window works on its own.

Step 4 · The landing page does one thing only

Whoever scans the QR is standing on the sidewalk, with little patience. The page that opens must load in an instant and keep the window’s promise, with a single main button. Right below, the box for installing the app: with the “Install” button on Android and the illustrated instructions on iPhone, recognized automatically.

Step 5 · The reason to keep it

Installing the app is a small commitment, and people make it only if it is worth it. The reasons that work are practical: booking without phoning, seeing one’s appointments, getting a reminder the day before, collecting points, being the first to hear about what is new. The more useful the PWA is, the longer it stays on the phone.

Step 6 · Measure, without profiling anyone

Add a parameter to the QR’s address that indicates where the visit comes from, for example ?from=window. That way you know how many visits come from the street compared with the website or social media, without collecting personal data. If you use analytics tools that set cookies, the rules in the chapter on GDPR and cookies apply.

The savings compared with a traditional app

• No publishing costs in the stores and no review to wait for.
• A single build, which is also your website and your booking page.
• No search in the store: the customer does not have to find your app among a thousand with similar names.
• A sticker instead of an advertising campaign: the cheapest channel there is for a business with a door on the street.

The QR in the window works even better together with the other tools of neighborhood retail, such as the flyer in the local area: I bring them together in the chapter on how to move from online to a physical shop.

07Website, portal and PWA: an ecosystem that belongs to you

Let us put the pieces together. A website that gets found, a portal that keeps customers and bookings in one place, a PWA that sits on customers’ Home screens, a QR in the window that brings passers-by inside. Each piece strengthens the others, and they all belong to your business: domain, data, relationship with customers, rules.

This is a substantial difference from what happens on platforms and social media, where visibility, contacts and even the existence of the page depend on decisions made elsewhere. This is why this owned ecosystem, website plus PWA, is the only real digital asset for finding customers without depending on social media: social media remain useful for getting noticed, but home is somewhere else. I talk about it in the next chapter: your website as an asset and social media as a megaphone.

Frequently asked questions

Sources

1. MDN Web Docs, “Making PWAs installable”: manifest, icons, HTTPS and the role of the service worker.
2. web.dev (Google), “Learn PWA: Installation”: installation on Android and manual adding on iOS and iPadOS.
3. WebKit (Apple), “Web Push for Web Apps on iOS and iPadOS”: push notifications from iOS 16.4 for web apps added to the Home Screen.
4. Apple Developer, “What’s included”: the developer program at 99 USD per membership year.
5. Play Console Help, developer account registration (in Italian): the 25 USD registration fee.
6. OWASP, “SQL Injection Prevention Cheat Sheet”: parameterized queries as the first defense.
7. Regulation (EU) 2016/679 (GDPR), Article 32 (in Italian): security of processing, encryption and restoring data.

Chapter updated October 2026. The features of PWAs depend on the browser and the operating system version and may change: the information on iPhone and Android comes from the official documentation of Apple, Google and Mozilla listed above.