LatePoint Locations - WordPress Plugin

How to Configure LatePoint Locations for Branch Offices and Service Areas

LatePoint Locations becomes necessary when a standard booking form is no longer enough: the business has multiple branches, offices, studios, rooms, service areas, or on-site service zones, and the customer needs to choose not just a service and time slot, but also where the service will be delivered. This guide does not repeat the plugin's marketing copy. Instead, it walks through a practical implementation plan: what to check before installation, how to connect locations to agents and services, how to display location selection in the booking form, how to verify the setup, and where to look if a branch does not appear in the schedule.

The main value of this add-on is not that the admin panel gets one more directory. What matters more is that the location becomes part of the booking flow. If a customer selects the branch on Sadovaya Street, they should not see a specialist who only works on Nevsky Prospekt, and they should not be able to book a time slot that is busy or unavailable for that specific location. That is why it helps to think of LatePoint Locations setup as working with a chain of data rather than just filling out entries.

The guide below relies on confirmed LatePoint capabilities and documentation: support for multiple locations in the Pro bundle, the ability to show a limited list of locations in booking forms and buttons through attributes, the locations resource list, preselecting a specific location or the any value, installing add-ons through an active license, upgrade behavior from the older product line, and practical issues described in the changelog, documentation, and discussions. Where a source does not directly confirm a detail, the recommendation is presented as a cautious WordPress and LatePoint best practice, not as a hidden product feature.

This guide is a good fit for salon owners, clinics, schools, studios, service businesses, and agencies building a booking site on WordPress. If you only have one office and one specialist, LatePoint Locations may be unnecessary: base LatePoint can already handle bookings, and extra directories should only be added when they reduce customer or admin mistakes.

Where Locations Change the Booking Flow

A booking system includes several different entities: a service answers the question "what the customer gets," an agent answers "who performs the work," a schedule answers "when it is possible," and a location answers "where it happens." As long as a business operates from a single place, the location often feels unimportant. But once there are two or more addresses, a wrong choice quickly becomes a real issue: the customer shows up at the wrong place, the specialist receives an appointment in the wrong branch, or the administrator sees an open slot that is actually only available at a different location.

LatePoint Locations adds a separate filtering layer to that chain. The official page for the older add-on described it briefly: the add-on adds support for multiple locations. In current LatePoint Pro, that idea is explained more fully: the feature list mentions multiple locations with different business hours, services, and agents. That is an important practical detail: a location should not exist separately from the schedule. A good setup does not start with a neat list of branches. It starts by checking which services and specialists are actually available at each location.

Imagine a network of two massage studios. The first offers sports massage, children's massage, and two specialists. The second has only one specialist and only offers classic massage. If you simply add two addresses to the directory, the customer can still end up at a dead end: they choose a branch, then a service, then see no available time, or they choose the wrong staff member. The right setup works differently: first create the locations, then connect services and agents only to the locations where they actually work, and only then let the booking form show the customer a logical combination.

This leads to the first practical conclusion: LatePoint Locations is best implemented after the base LatePoint setup is complete, but before you start publicly promoting the booking page. If you send traffic to the form first and only later add branches, you risk ending up with bookings that were created before location logic was fully configured. On a test site that is not a problem, but for a live business it is better to make a backup first, verify the schedule, and run several test bookings for every address.

Common Use Cases Where the Add-On Truly Helps

LatePoint Locations is especially useful for three types of projects. The first is physical branches: a beauty salon, medical office, dental clinic, yoga studio, training center, repair shop. Here the customer needs to choose a specific address, and the administrator needs to see the workload for each location.

The second group is rooms, halls, and resources inside a single address. Technically these are not separate branches, but for the customer and staff they function as different service locations. For example, a trainer may run personal sessions in Studio A or Studio B, while a massage therapist may work in Room 1 or Room 2. If availability depends on the room, a location helps keep schedules from getting mixed together.

The third group is service zones for on-site visits. This requires caution: the official Locations page confirms support for multiple places, but it does not provide enough information to confidently promise geosearch, routing, or automatic assignment by distance. So for field services, this guide treats locations as predefined service areas that the customer selects manually, not as a full geo-based system that automatically assigns the nearest point.

When It Is Better Not to Add Location Complexity

If all specialists work at one address and the difference between services does not depend on the location, adding an extra selection step may hurt conversion. In that case, it is better to keep one location or use a standard booking form without showing the place. Another borderline case is a business where the branch is always implied by the selected service. For example, "X-ray" is only available in one room, while "consultation" is only available in another. In that case, you can set up separate forms or buttons with limited services and locations so the customer does not have to go through an unnecessary extra choice.

LatePoint Locations should not be installed just to create SEO branch pages. LatePoint documentation confirms the resource list and shortcodes, but it does not justify promising separate indexable pages for every address through this add-on alone. If the site needs landing pages like "service + city" or "branch + service," those are better built as standard WordPress pages, with the LatePoint form embedded afterward using the appropriate restrictions through attributes.

What to Check Before Installation

Before adding LatePoint Locations, separate three things: whether base LatePoint is ready, whether Pro features are available, and whether your branch data is complete and reliable. A problem at any of these levels will later look the same: the customer cannot see the location, cannot pick a time slot, or sees a form without the expected step.

First, make sure the main LatePoint plugin is already working on the site. The Getting Started documentation describes the standard path: install the plugin from the WordPress repository or upload the ZIP, activate it, complete the initial setup wizard, add services, business hours, notifications, and the booking form. That is the foundation. Without it, Locations will not produce a useful result. If standard booking does not work before branches are added, fix the base booking flow first.

Next, check the status of Pro Features. The current add-on installation documentation says that add-ons require the Pro Features add-on, an active license in Settings > Premium Features, and access to add-ons through the LatePoint panel. After LatePoint moved to its newer model, separate add-ons from the older product line were merged into Pro Features. The upgrade documentation explicitly lists old add-ons that should be deactivated during the transition, and Locations is one of them. If the site was upgraded from the older product line, do not install the old ZIP on top of the new Pro setup without checking the documentation and making a backup first.

The third part of preparation is data. Do not start with the interface. First, create a short table: the branch name customers will see, the internal name for administrators, the address, phone number, which services are available, which agents work there, which days and hours differ from the default schedule, and whether notifications need location-specific wording. Ideally, that table should be reviewed by the administrator, the branch owner, and the person responsible for taking bookings.

Mini Data Map Before Launch

Also check caching separately. The LatePoint WordPress.org page recommends disabling caching on the customer cabinet page. For the booking form itself, it is also worth checking caching, minification, and deferred script loading if, after configuring locations, the form steps stop updating or keep showing outdated options. There is no need to disable all caching across the site right away. First exclude the booking page and the customer cabinet, then clear the plugin cache, CDN cache, and browser cache.

Safe Preparation for a Live Site

For a site with real customers, use a short operating procedure. Create a backup of the database and files, perform the installation on a staging copy or during a low-traffic period, test one booking flow for each branch, and only then open the form to visitors. LatePoint changelogs regularly include fixes related to security, roles, the calendar, visibility, and time-slot availability. That is normal for a complex booking plugin, but it also means updates should not be postponed for months.

Critical check before launch: create a test booking for every "location - service - agent" combination. If even one combination does not produce the expected slots, do not launch the page until you verify the connections and schedule.

Installing the Add-On and Running the First Check

The installation method depends on which LatePoint product line your site is using. For a new setup, follow the current documentation: install the main LatePoint plugin first, then Pro Features, activate the license in Settings > Premium Features, and then install the available add-ons from the LatePoint panel. For older sites that were upgraded from the product line where Locations was a separate add-on, the migration instructions matter: some legacy add-ons were merged into Pro Features and should no longer remain active as separate outdated modules.

In the WordPress admin area, the general path looks like this: Plugins for installing and activating the main plugin, then the LatePoint panel for the initial setup, then Settings and Premium Features to verify Pro access. Exact menu labels may change slightly after interface updates, so do not rely on every button matching word for word. Focus on the intent instead: active base LatePoint, active Pro features, access to add-ons, and no old duplicate installs.

After installation, do not jump straight to the public booking form. First open the LatePoint admin panel and verify that a section or settings related to locations are now available. Then create a minimum test setup: one test location, one service, one agent, and one business-hour interval. If everything is already configured, do not change your real branches right away. Add a temporary test location with a clear name that can easily be removed later, or work on a site copy.

How to Check That the Add-On Is Not Conflicting with an Older Install

LatePoint documentation for the One of the plugins is invalid error points to two common causes: there is no Pro license or it has not been activated, or the plugins directory still contains a folder with the same name or an old version that WordPress reads incorrectly. For an administrator, that is a useful starting point: if the add-on will not install, there is no reason to guess at form settings. Check the license first, then check for an old leftover folder.

On a live site, it is better not to delete folders manually without a backup. If you are not sure, hand that task off to a developer or hosting support. This guide does not cover FTP access or editing plugin files, because that adds unnecessary risk for a standard LatePoint Locations setup. The administrator's job is to make sure WordPress sees the correct plugin set and that LatePoint itself is offering the required Pro features.

Initial Smoke Test After Activation

Right after activation, run a short smoke test. It does not replace full validation, but it quickly shows whether the add-on is connected to the booking logic:

1. Open LatePoint in the admin area and make sure location settings are available.
2. Create or open a test location with a clear name.
3. Connect it to a service and an agent if the interface requires those relationships.
4. Check the agent or location business hours, especially if branches follow different schedules.
5. Open the booking form page in visitor mode or in a separate browser.
6. Select a service, location, and time, then go all the way to confirmation without making a real payment if payments are enabled on the site.

The short conclusion is simple: if the test location appears in the form, filters the available time, and is saved in the created booking, you can move on to full configuration. If it appears only in the admin area but not in the form, the cause is usually one of these: relationships, restricting shortcode attributes, cache, or incompatible leftovers from the previous installation.

Branch Setup Map: From Directory to Schedule

The most common mistake with multiple branches is treating a location like a decorative field. In LatePoint, it needs to become part of the availability rules. So it is more useful to configure not a "branch page," but a full chain: location, service, agent, business hours, form, notifications, and verification. That order reduces the chance that a customer selects a nice-looking address and then sees no available slots.

Start with names. In the public form, use a short and clear label: "Downtown," "North Branch," "Lenina Office." The full address can be stored in internal notes. Do not overload the location name with the phone number, subway station, and schedule all at once. If the line is too long, customers will have a harder time comparing options, and the mobile form will become harder to read.

Then verify services. If a service is not available everywhere, it should only be connected to the relevant branches. This matters especially for equipment that is not available at every location: a laser machine, training room, photo studio, group class hall, or repair lift. The location should eliminate impossible options before the customer chooses a time slot, not explain the problem only after a failed booking attempt.

The third layer is agents. In LatePoint, an agent is the provider or staff member with their own schedule. For a multi-location business, an agent may work at one branch permanently, rotate between branches depending on the day, or accept on-site bookings in separate service zones. The current LatePoint changelog confirms the evolution of location-specific agent schedules. That means in the current Pro setup, an agent's schedule can be tied to a place. There is no need to rely on old screenshots in this guide: check the current interface on your site and the updated documentation instead.

Product-Specific Mechanic 1: Grouping Locations

The changelog for the older Locations add-on mentions the ability to group locations. In practice, that is useful when the business has many locations and the customer needs a first filter: city, district, facility type, or service area. For example, a school network can group branches by district, and a medical center can group them by city. The limitation is obvious: a group helps customers find a place, but it does not replace correct connections to services and agents.

How to verify the outcome: create a group, add several locations to it, and see how they appear in the resource list or booking form. If a group was deleted or renamed, make sure the locations did not disappear from the index. The Locations changelog includes a fix related to locations not appearing in the index after a category was deleted. That is a good example of why structural changes should always be checked in the public list, not only in the admin area.

Product-Specific Mechanic 2: "any" Location and Automatic Assignment

The booking form documentation confirms the selected_location attribute, which can accept either a location ID or the value any. The older Locations changelog also mentions support for a preselected "any" value for location. This mechanic is not for every site. It is useful when the customer does not care about the place or when you want to shorten the form and let the system pick an available location based on the other restrictions.

The limitation is important: "any" should not hide a meaningful decision if the customer needs to arrive at a specific address. For an online consultation or a service with the same outcome in any room, that can be fine. For a salon, clinic, or repair service that requires a physical visit, it is better to show the location explicitly. Otherwise, the customer may learn the address too late, after the booking has already been created.

Product-Specific Mechanic 3: Filtering the Form by Specific Locations

The official documentation describes the show_locations attribute for [latepoint_book_button] and [latepoint_book_form]. It lets you show only selected locations by ID in a specific form. This is a powerful tool for landing pages. For example, a "Downtown Massage" page can open the form only for the downtown branch, while a general "Book Now" page can show all available locations.

How to verify the outcome: open the page with the restricting shortcode and make sure the form does not show extra branches, then test a direct flow with another service. If the service you need disappears, the problem may not be the form at all. It may simply be that the service is not connected to the chosen location or agent.

Product-Specific Mechanic 4: The Locations Resource List

The shortcode [latepoint_resources items="locations" columns="3"] outputs a list of bookable resources of the locations type. The documentation also lists item_ids, group_ids, button_caption, button styles, and limit. This is not just decorative. The list can work as an intermediate location-selection screen: the customer sees address cards, chooses the appropriate location, and moves on to booking.

There is one practical nuance here. If you only have two branches, the resource list may be easier to use than a long form. If you have many locations, it is better to group them or create separate city pages. But do not promise geosearch unless it is implemented through a separate confirmed tool. In the LatePoint sources that could be verified, what is reliably confirmed is the resource list and filtering by ID or groups.

The Booking Form: How to Control Location Selection

The booking form is where users first encounter the LatePoint Locations logic. This is where you need to decide whether to show the location step to everyone, hide it on specific pages, limit the set of branches, and determine what happens if the customer arrived from a landing page for a specific address.

LatePoint provides several ways to embed booking on a page: a direct form, a button that opens a modal window, WordPress blocks, and elements for supported page builders. The documentation confirms [latepoint_book_form] for a direct form, [latepoint_book_button] for a button, as well as blocks and widgets. For Locations, what matters most is not the embedding method itself but the attributes that restrict the available data.

Example of a basic branch restriction:

[latepoint_book_form show_locations="1,3" show_services="2,5"]

This works well for a page that should show only two locations and only the services that are actually available there. The documentation says that location, agent, and service IDs can be found in the URL of the corresponding entity's edit page in the admin area. Before publishing, double-check those IDs: a one-digit mistake often looks to the customer like "the form is empty" or "no available time."

Example of a button with a preselected location:

[latepoint_book_button selected_location="1" show_services="2,3" source_id="center-landing"]

Here, selected_location shortens the customer's path: they land on a specific branch page, click the button, and do not have to choose the location again. source_id is useful for source tracking because the documentation says the source ID can be found in the booking edit form in the admin area. Do not turn source_id into a channel for secrets or personal data. It should remain a short, safe identifier for a page or campaign.

When to Use a Direct Form and When to Use a Button

A direct form works best on a "Book Now" page where the user is already ready to choose a service, location, and time. It reduces clicks and makes the workflow obvious. A button works better inside location cards, long service descriptions, and branch pages, where you first need to explain the conditions and only then open the booking flow.

If you display a location list through [latepoint_resources items="locations"], the button inside each card can lead to booking with the right context. The resource documentation allows you to change the button caption and styles through attributes. But there is no need to overload the shortcode with dozens of presentation parameters if the design can be handled cleanly through theme styles. The simpler the shortcode, the easier it will be to maintain after updates.

How to Avoid Breaking Time Availability with Restrictions

The restrictions show_locations, show_services, show_agents, and show_service_categories work as filters. If they intersect incorrectly, the form may show nothing at all. For example, the page is limited to location 1, the service is only available at location 2, and the agent only works at location 3. From the system's perspective, that is not an error. It is simply an impossible combination that you created.

That is why every shortcode change should be tested not just for whether the form appears, but whether the user can actually get all the way to an available time slot. A successful check is not "the form loaded." It is "the customer can choose a location, service, agent, date, time, and receive the correct confirmation." If payments are enabled, also run a test using the payment gateway's safe mode, or temporarily use a no-payment flow if your configuration supports one.

Practical Example: A Two-Branch Studio Network

Let us look at a concrete example. Suppose a beauty studio has two branches: "Downtown" and "North." At "Downtown," haircut, coloring, and treatments are available, and two stylists work there. At "North," haircut and treatments are available, and only one stylist works there. The goal is for the customer to see both branches on the main page, while the "North Branch" page should immediately show only the available services and that specific location.

Goal

Create two working booking entry points. The first is a shared "Book Now" page where the customer chooses a branch. The second is a "North Branch" page where the location is already preselected and the service list does not offer the unavailable coloring option. In the admin area, the administrator should see bookings with the location attached and immediately understand which branch the customer will visit.

Preparation

The site should already have LatePoint installed and activated, the basic wizard completed, and services and agents created. Pro features should be available. Before configuration, create a mapping table:

• "Downtown": haircut, coloring, treatment; stylist Anna, stylist Oleg.
• "North": haircut, treatment; stylist Oleg.
• Coloring should not be shown for "North."
• Oleg works in "Downtown" on some days and in "North" on other days.

If your current LatePoint interface allows a location-specific schedule for the agent, use it. If your site does not have that setting, you need to verify the Pro Features version and the documentation, and for now avoid promising customers automatic schedule separation by address.

Configuration Steps

1. Create two locations with short public names and clear internal data.
2. Open the services and verify which locations are allowed for each service.
3. Open the agent profiles and verify where each agent sees customers.
4. Configure the agent's business hours with branches in mind if your version supports that feature.
5. On the main page, insert a normal form or button without a hard selected_location, but with the needed set of services.
6. On the "North Branch" page, use selected_location with the North location ID and show_services only for the available services.
7. Open the page in visitor mode and complete the booking flow through confirmation.

For the branch page, the shortcode might look like this:

[latepoint_book_form selected_location="2" show_services="1,3" source_id="north-location-page"]

This is just a structural example, not a ready-to-use set of IDs for your site. The real values must come from your admin area. If you copy the example without replacing the IDs, the form will almost certainly point to the wrong place.

Verification

Do not test this in a single pass. Test it as a matrix. On the main page, choose "Downtown" and make sure all three services are available, then choose "North" and make sure coloring disappears or is no longer offered. Next, check Oleg on different days. If he appears available in both branches at the same time even though he should rotate, the problem is likely in the agent schedule or in the absence of a location-specific schedule.

After creating a test booking, open it in the admin area and confirm that the location was saved. This is especially important if you use exports, notifications, or external automations. The older Locations add-on changelog mentions the addition of location data to webhook calls and a location column in CSV export. So for sites where data flows into a CRM, spreadsheets, or reports, do not just test the form. Also verify downstream processes: export, webhook, and administrator notifications.

A Commonly Missed Detail

If a customer lands on a specific branch page from an ad, they expect to see that exact branch. But if you hide the location step using selected_location, make sure the address still appears near the form in plain page text. Do not make the customer guess where they booked based only on the confirmation email. This is not a LatePoint setting. It is basic UX practice for a multi-location business.

What the Result Should Look Like in Admin, Export, and Automations

After configuring LatePoint Locations, public location selection is only part of the job. The administrator also needs to understand how the location moves through the internal system: booking, calendar, export, notifications, roles, and external processes. The older Locations changelog contains several entries that clearly show the evolution of that logic: showing bookings from "All Locations" in the admin area, a location column in CSV export, location data in webhook calls, and support for roles and processes.

These points help define the right verification process. If the business tracks operations by branch, one successful booking is not enough. You need to open the appointments list, the calendar, the booking record, the export, and any automation that is in use. The location should be visible everywhere the administrator makes operational decisions: who will see the customer, where the customer should go, which branch is busy, and where the notification should be sent.

Checking the Calendar and Booking List

Check the filters in the calendar and the appointments list. If the interface allows selecting a specific location or "All Locations," compare both modes. In all-locations mode, the administrator should see the full workload. In single-location mode, they should see only the relevant bookings. If the filter exists but the results look wrong, start by checking your test bookings. Older bookings may have been created before the location setup and may not contain the required field.

Do not delete real bookings just to keep the test clean. It is better to create a few new test bookings with obviously fake customer names, verify the filter, and then cancel or delete those bookings through the standard workflow. LatePoint changelogs have included fixes related to deleting services and bookings, so any action involving real data should be handled carefully.

Notifications and Customer-Facing Text

The official Notifications page confirms that LatePoint can send confirmations, reminders, and updates through multiple channels, and that templates support variables such as the customer name, service, date, and price. For locations, the important thing is to check whether your template includes an available variable for the place or another way to insert the address. Do not invent a placeholder. If the documentation for your version does not show the exact location token, check the variable list in the template interface.

At a minimum, the email or SMS to the customer should include the service, date, time, address or a clear location name, plus a way to cancel or reschedule if that option is enabled. If the location is missing from the notification, the customer may book correctly but still show up at the wrong place. That is especially risky for salon chains and clinics.

Webhooks and External Processes

If the site sends bookings to a CRM, Google Sheets, Zapier, Make, n8n, or a custom system, inspect the payload. The Locations changelog confirms that location data was added to webhook calls, but the exact fields may depend on the version and current LatePoint architecture. So the correct test looks like this: create a test booking for each branch, catch the webhook in a test receiver, verify that the location arrives as a separate field or usable structure, and only then build the automation around it.

The boundary of responsibility matters here. LatePoint is responsible for creating the booking and passing data within its supported capabilities. The external service is responsible for processing the payload. If the CRM does not recognize the location, do not rush to change LatePoint. First compare the actual payload with the external workflow settings.

Compatibility with the Theme, Cache, Roles, and Updates

LatePoint runs inside WordPress, so the outcome depends not only on the add-on itself. The form is affected by the theme, page builder, cache, script optimization, user permissions, payment add-ons, and other Pro features. With Locations, this is especially noticeable: if the location step does not update dynamically, the customer may see an outdated list or an empty calendar.

Theme-related issues are usually visual: the form is too narrow, the location list gets cut off, the button is hard to see, or the modal conflicts with the header z-index. Start by testing the form on a standard page without complicated builder sections. If it works there but breaks inside a landing page, the issue is probably the container, lazy loading, JavaScript optimization, or theme styles.

Be precise with caching. Exclude the booking page, the customer cabinet page, and, if needed, pages with booking buttons. If a CDN is in use, clear it after making changes to the form and scripts. After a LatePoint update, the official migration documentation recommends clearing cached assets and browser cache because old CSS and JS may interfere with the updated admin area and booking form.

Roles and Access for Branch Administrators

On the Pricing page, the LatePoint Pro feature list includes Access Roles & Permissions and Dashboard for Agents. For a multi-location business, this is not just a nice extra. If a staff member should only see their own branch, check how roles are configured and which permitted actions are available. The Locations changelog mentions support for roles and processes, but the exact permissions matrix depends on the current Pro Features version and your configuration.

A practical approach is to configure locations under the main administrator first, then create a test employee or manager account, log in with it, and verify the visibility of appointments, calendar, customers, and settings. Do not validate roles only visually while logged in as the administrator, because full access hides permission mistakes.

Updates and Security

LatePoint is actively updated. The changelogs on WordPress.org and the developer site show regular fixes, including security, nonce validation, data visibility, the calendar, payments, roles, and Gutenberg blocks. External vulnerability databases also track LatePoint issues and the versions that fixed them. This does not mean the product should not be used. It means something else: for a booking system, updates, backups, and a staging environment are part of normal operations, not a one-time technical detail.

Before updating, review the changelog, make a backup, update the site copy first, and then test all branch workflows. Pay special attention to payment flows, the customer account, manager roles, and external webhook-based processes. If the update changes Pro Features, do not leave old add-ons active "just in case." They may no longer be needed and can create confusion.

A Safe Improvement That Does Not Require Code Changes

Instead of using a PHP snippet for Locations, it is better to rely on confirmed shortcode attributes. They are reversible, they do not require core edits, and they are easy to disable. For example, for a specific branch page, use a preselected location and a limited service set:

[latepoint_book_form selected_location="2" show_services="1,3" hide_summary="no" source_id="north-location-page"]

The basis for this is the LatePoint documentation for form attributes and filtering services, agents, and locations. The insertion point is the content of a WordPress page, a Shortcode block, or the corresponding LatePoint block or widget if it supports the same parameters. Verification means completing a booking as a visitor and confirming that the form only shows the required branch and saves the location in the booking. Rollback means removing the selected_location and show_services attributes or replacing them with the correct IDs. That is safer than hunting for undocumented hooks or editing plugin files.

Branch Pages Without Duplication or Unnecessary Steps

Once a site has multiple locations, it is tempting to create identical pages for every address: the same text, the same form, with only the street name and map changing. That does little for the reader and creates extra maintenance for the administrator. LatePoint Locations works best as a functional part of the page, not as an excuse to multiply weak landing pages. A branch page should answer specific questions: which services are available here, who works there, how to get there, whether there are equipment-related limitations, which business hours differ from the rest of the network, and how to book this specific location.

A useful branch page structure looks like this: a short introduction to the address and its benefit at the top, then a services block, then the team or specialists, then the form with selected_location, and then practical details such as parking, entrance instructions, documents, or visit preparation. Inside the form itself, there is no need to make the customer choose the same branch again if they are already on that branch page. But the place should still be confirmed next to the form in plain text: "Booking is open for the North Branch" or "The form below creates a booking for the Lenina office." That reduces customer uncertainty and lowers the number of clarification calls.

The shared "Book Now" page works differently. There, the user has not yet chosen a location, so it is better to keep the location step visible or show a resource list before the form. If you hide the location using any, explain in the content how the customer will learn the address. For a physical visit, that is almost always a bad idea because the address is part of the decision. For an online service where "location" actually means a team or internal room in the system, any may be justified.

If you have many branches, do not try to solve everything with one long form. Use grouping if it is available in your configuration, or create pages by city and district. The LatePoint resources documentation confirms group_ids for locations, so instead of showing customers the full directory, you can show only the relevant set. For example, a city page can show only the branches in that city, while a city-level service page can also limit the list of services. That keeps the customer journey short and prevents administrators from receiving bookings for the wrong locations.

SEO is secondary here, but it is not meaningless. A strong branch page can rank for address- or district-based searches if it includes real differences: staff composition, available services, transportation details, photos, schedules, and visit conditions. A weak page with nothing but a changed street name does not become useful just because it contains a LatePoint shortcode. The booking form strengthens an already useful page, but it does not replace content about the actual location.

Think through internal links as well. If someone is reading a service page, you can offer a link to "choose a branch for booking." If they are reading a branch page, it makes more sense to show "book this branch." If they are already on the main booking page, do not send them in circles between pages. LatePoint provides the technical selection mechanism, but the site architecture should make that choice calm and obvious.

Operating Procedure for Managers and Administrators

Once the technical setup is complete, day-to-day operations begin. Multi-location booking does not break only because of code or updates. It often breaks because of ordinary operational actions: an administrator adds a new service and forgets to connect it to a branch, a manager changes an agent's schedule only in the general calendar, a staff member deletes a location category, or a marketer copies a shortcode from an old page and leaves the wrong IDs in place. That is why LatePoint Locations needs a short operating procedure that not only developers understand.

The procedure can stay simple. Any service change should go through three checks: which branches offer the service, who performs it, and what time can actually be offered to the customer. Any agent change should go through three different checks: where they work, which services they provide in each location, and whether there are day-specific exceptions. Any WordPress page change should be tested through the full form flow: selected page, selected branch, service, agent, date, time, confirmation, and the resulting booking in the admin area.

For a branch manager, a weekly check is useful. It does not need to take long: open the calendar or appointments list, apply the filter for that location, review upcoming bookings, complete one test form in a private window, and make sure the address in the notification is clear. If exports are used, periodically generate a CSV and check the location column. If a webhook is connected, periodically verify that the external spreadsheet or CRM is receiving the correct location.

New branches should be added through a checklist, but the checklist should be practical and verifiable, not formal for its own sake. Name created, group assigned, services connected, agents connected, schedule working, WordPress page published, shortcode contains the correct IDs, notification shows the address, test booking created, test booking canceled or marked as internal. If even one item is skipped, it is better to delay launch. An incomplete location in a booking system is worse than no location at all: the customer sees the option, but cannot book it or ends up booking incorrectly.

For schedule changes, use the rule "future bookings first, schedule second." Before moving an agent from one branch to another, check whether they already have bookings assigned. If they do, decide whether you are moving the customers, leaving old bookings as they are, or contacting them manually. A schedule change does not automatically need to fix older bookings. A booking system stores an already created event. It does not guess the management decision for you.

For a marketer or SEO specialist, a different rule matters: do not copy shortcodes without understanding the IDs. If the "Downtown" branch page was created by copying the "North" page, it is easy to leave selected_location="2" in place instead of the correct value. As a result, all traffic for one branch will create bookings in the other. The simplest protection is to create a test booking after publishing every page and verify the location in the admin area. Not a screenshot of the form, not a visual check, but an actual created booking.

Roles and access are also part of operations. If a branch manager should only have access to their own bookings, verify that after every role change and every Pro Features update. If a manager can see someone else's bookings, the cause may be an incorrect role or a permissions model that is not precise enough in the current configuration. Do not compensate for that by giving full admin access. It is better to leave some operations with the main administrator than to grant extra capabilities to someone who does not need them.

Finally, document changes. For a small site, a simple admin documentation page is enough: who changed the location, what was changed, which pages were affected, and which test booking was created for verification. That helps a month later when you need to understand why the form for one particular branch only shows two services instead of five. LatePoint includes an activity log in the Pro bundle, but internal site decisions are still worth recording in plain human language.

Troubleshooting: The Location Does Not Appear, No Time Slots Are Available, or the Booking Goes to the Wrong Place

Problems with LatePoint Locations often look similar, but their causes are different. So do not start with a reinstall. Follow the path from data to form: the location exists, is connected to a service, is connected to an agent, has available business hours, is not filtered out by the shortcode, is not hidden by cache, and is saved in the booking.

The Location Exists in Admin but Is Not Visible to the Customer

Symptom: the location has been created in the LatePoint panel, but the visitor cannot see it in the booking form. Possible causes: the form is restricted through show_locations, the location is not connected to the selected service, the agent does not work at that location, the location belongs to a group that is not being displayed, or the page is serving an outdated cached version of the form.

Check: open a page without restrictive attributes, then gradually add back show_locations, show_services, and show_agents. If the location appears with no filters, the problem is in the ID intersection. If it does not appear anywhere, verify the add-on status, the relationships, and the visibility of the location itself.

Fix: update the IDs in the shortcode, add the required service and agent connections, and clear the booking page cache. Rolling back the setup makes sense if several changes later you still cannot restore the original working flow. In that case, revert to the previous shortcode and test the base form.

No Available Time After Selecting a Location

Symptom: the customer chooses a branch and service, but the calendar is empty or shows an unavailable message. Newer versions of LatePoint improved the "No Availability" message, but the root cause still needs to be checked. Most often, the agent has no working hours at the selected location, the service is not assigned to that location, the service duration does not fit into the available interval, or all slots are already booked.

Check: create a test service with a short duration, one agent, and one wide business-hour interval. If time slots appear, the problem is in the schedule or in the duration of the real service. If they do not appear, check the agent's general availability, holidays, days off, earliest/latest booking restrictions, and the global time settings.

Fix: align the agent's schedule with the location, reduce conflicting restrictions, and verify buffers and holidays. Do not turn on "any" agent or "any" location as a universal fix if the customer needs a specific place or specialist.

The Booking Is Created, but the Administrator Cannot Clearly See the Correct Branch

Symptom: the customer completed the form, but the location is not obvious in the appointments list, export, or notification. The cause may be a hidden location-selection step, outdated notification templates, incomplete column settings, the manager's role, or an external workflow that does not read location data.

Check: open the booking itself in the admin area under the main administrator account. Then check the calendar, export, and webhook separately. If the field exists in the booking but disappears in the external service, the problem is not the customer's selection. It is in the downstream data handling.

Fix: add the location to the notification template using the available interface variables, configure column visibility, or update the webhook handler. If there is no exact variable in the interface, do not invent one manually. Check the documentation and the list of available placeholders first.

Error During Add-On Installation or Update

Symptom: WordPress reports that one of the plugins is invalid, the add-on will not install, or it disappears after an update. LatePoint documentation points to two basic causes for the invalid plugin error: the Pro license is missing or inactive, or the plugins directory still contains an older folder with the same name.

Check: make sure Pro Features is active, the license is activated in Settings > Premium Features, and the site is not still carrying the old standalone Locations add-on after moving to the new product line. If you do not manage the site's files yourself, pass the task to hosting support or a developer.

Fix: follow the official upgrade instructions. Do not download random archives from unofficial sources, and do not replace folders on a live site without a backup. If an old duplicate must be removed, first make sure LatePoint data will not be deleted with it and that recovery is available.

The Form Works on a Simple Page but Breaks on a Designed Landing Page

Symptom: booking works on a plain page, but inside a builder page the location step freezes, the modal does not open, or the branch list is covered by the header. Possible causes include style conflicts, JavaScript optimization, deferred asset loading, cache, a nonstandard container, or the theme's popup behavior.

Check: create a temporary plain WordPress page with a single LatePoint shortcode. If everything works there, move the form back and disable optimizations one at a time: minification, script combining, deferred loading, and caching for that specific page.

Fix: exclude the booking page from aggressive caching and optimization, check the theme modal z-index, and update LatePoint and the theme on a site copy. Rollback means putting the form back on a plain page until the builder conflict is identified.

How to Use Locations Together with Other LatePoint Features

LatePoint Locations rarely works in isolation. It usually operates together with agents, forms, notifications, roles, the calendar, and sometimes payments. But the combined setup should be designed around boundaries of responsibility. The location defines the place, the agent defines the provider, the service defines what is booked, the schedule defines availability, the notification handles customer communication, and the payment module handles payment.

For example, in a medical clinic, Locations handles the branch, Custom Fields handles extra patient questions, Notifications handles sending the address and reminders, Payments handles the deposit, and Roles handles branch manager access. If something breaks, do not diagnose the entire stack at once. Check the specific boundary: the patient field is not connected to the location, the notification does not show the address, the manager can see someone else's bookings, or the payment went through but the booking was not filtered by branch.

Notification Workflow

After selecting a location, the customer needs a clear confirmation. If the message includes only the date and service, the administrator will still get calls asking, "Where do I need to go?" So after configuring Locations, open the notification templates and check which variables are available. If the interface provides a location or address variable, insert it. If not, use clear wording on the confirmation page and in the manual template, but do not invent a technical placeholder.

The check is simple: create a test booking for each branch, receive the email or SMS as the customer, and compare the wording. A good outcome is one where the customer understands where to go and which service was booked without needing to log in. A bad outcome is an email that looks identical for every branch.

Manager Role Workflow

If different people manage different branches, configure roles carefully. First decide what the manager should see: only appointments for their branch, customers for their branch, schedules for their agents, or also service settings. Then configure the roles and test them using a separate test account. Do not give a manager WordPress administrator rights just because it is faster.

The limitation is important: if the current LatePoint version does not allow the exact separation level you need, do not work around that by editing the database directly. It is better to adjust the internal process or keep part of the management under the main administrator. In a booking system, incorrect permissions are more dangerous than an extra manual step.

Dedicated Branch Page Workflow

For SEO and usability, many sites create separate branch pages with an address, map, photos, team, service list, and booking button. Here, LatePoint Locations acts as a form filter, not a page generator. Use regular WordPress content for the branch description, and embed the form with selected_location or show_locations. That way, you are not dependent on whether the add-on can generate a dedicated location page, and you keep control over the page copy.

If there are many branches, do not create dozens of nearly identical pages. It is better to group them by city or district, and on the page itself provide a locations resource list. Publish a separate page only where it brings unique value: photos, transportation details, team structure, services, hours, or important limitations.

When LatePoint Locations Is the Right Choice

LatePoint Locations is worth using when a business already operates in multiple places, or plans to, and when a wrong address choice can lead to a missed appointment. The add-on is especially useful when services and staff are distributed unevenly across branches: one service is only available at a specific location, an agent works in different places depending on the schedule, managers need to filter bookings, and the customer needs to see the correct address before confirming.

Before launch, verify four things: Pro Features is active, legacy add-ons are not conflicting with the new product line, each location is connected to real services and agents, and the booking form completes the full path through confirmation. If all of that is in place, you can move on to downloading and installing it: download the installation file and test it on a site copy or during a safe maintenance window.

If you only have one address, no staff-based separation, or the branch does not affect time-slot selection, start with basic LatePoint without extra complexity. A good booking system does not need to show the maximum number of settings. It should give the customer a short path to the right booking, and give the administrator clear data without manual cleanup.