La IA espacial para negocios con múltiples ubicaciones conecta los registros canónicos de sucursales, el inventario o la disponibilidad, los horarios, el área de servicio y el contexto de viaje para que un producto pueda recomendar una ubicación óptima en lugar de la ubicación más cercana. El modelo de lenguaje interpreta intenciones complejas, como un artículo en stock de camino a casa. Los sistemas de ubicación, inventario y rutas siguen siendo la fuente principal de información sobre identidad, stock, horarios y viajes. La IA espacial clasifica las sucursales disponibles y explica el resultado en el mapa.
Las secciones siguientes separan la identidad de la organización de los registros de sucursales y luego abordan la elegibilidad, la clasificación de viajes, el mapeo de Kaleidr, la medición y un programa piloto específico. Para obtener información relacionada, consulte AI Store Locator With Map Chat, Store-Aware Shopping AI y Location Intelligence Customer Experience. Los equipos que ya vinculan conversaciones a un mapa de sucursales existente pueden pasar directamente al mapeo de Kaleidr; los equipos que aún nombran el límite del catálogo deben comenzar con los registros de ubicación canónicos.
Aspectos esenciales de la IA espacial multi-ubicación
- Un ID por lugar: Cada sucursal, propiedad, clínica o punto de servicio necesita un ID de ubicación estable.
- La información permanece en los propietarios: El horario, el inventario, la capacidad y el precio nunca provienen de la invención del modelo.
- La más cercana es la recuperación: No se recomienda ordenar por marcador más cercano.
- La elegibilidad precede a la clasificación: Las ubicaciones cerradas, sin existencias, fuera de área o no autorizadas se eliminan primero del conjunto.
- Medir el lugar: La selección, las direcciones, la recogida y la geografía sin resultados son más importantes que la duración del chat por sí sola.
La IA espacial multisede responde qué sucursal disponible se ajusta mejor a las necesidades del cliente, no solo cuál es la más cercana.
¿Por qué la IA espacial para negocios con múltiples ubicaciones representa un problema arquitectónico distinto?
Una sola tienda suele publicar una ubicación, un registro de horario y una acción. Una empresa con docenas o miles de sucursales tiene una función de producto diferente: el cliente ya conoce la marca y pregunta qué sucursal puede ayudarle en ese preciso momento. Esa respuesta depende de la capacidad de la sucursal, su estado operativo en tiempo real, su horario, su área de servicio, la relación de viaje y las reglas de negocio, no solo de la representación de marcadores.
Actualmente, Kaleidr centra su plataforma en la experiencia del cliente, conectando datos empresariales, información de ubicación y sistemas existentes. Describe una base de conocimiento empresarial basada en la ubicación para respuestas de IA (AI-Powered Map Experiences for Business). La página AI Map Chat for Customer Discovery describe cómo integrar búsquedas y recomendaciones en los mapas que ya gestiona la plataforma, incluyendo el sector minorista como uno de los verticales mencionados. Estas páginas son la base del posicionamiento de Kaleidr. Sin embargo, no demuestran que Kaleidr gestione un registro de inventario, CRM, información horaria o directorio de franquicias.
El artículo sobre el localizador de tiendas mencionado anteriormente describe la herramienta de búsqueda para el cliente: listado, mapa, filtros y chat a través de un directorio. El artículo sobre compras abarca la gestión de SKU e inventario en una tienda específica. Esta guía describe la arquitectura empresarial en torno a estas experiencias: identificadores canónicos, elegibilidad, clasificación y análisis centrados en la ubicación en toda la red. Es importante mantener los tres problemas diferenciados en el producto, incluso cuando un mapa muestre las mismas sucursales.
¿Qué registro de ubicación canónica debe conservar cada sucursal?
Una marca puede ser una sola organización. Sus ubicaciones no son un solo registro. Cada sucursal puede diferir en coordenadas, dirección, horario, servicios, inventario, capacidad del personal, accesibilidad, área de servicio, estado operativo y próxima acción comercial. Los sistemas de listado público ya tratan esta división como operativa: Google actualmente indica a las empresas que no creen más de una página de perfil para cada ubicación, que mantengan nombres y categorías consistentes en todas las ubicaciones y que distingan las tiendas físicas de los negocios con área de servicio (Guidelines for representing your business on Google, 2026). Para cadenas lo suficientemente grandes como para administrar perfiles de forma masiva, Google actualmente documenta los flujos de trabajo para agregar, verificar y administrar de forma masiva para empresas con 10 o más ubicaciones (Bulk location management overview, 2026). Estas páginas de ayuda describen el contrato de listado público de Google. Estas mismas páginas no son un esquema de ubicación de Kaleidr.
Schema.org define actualmente LocalBusiness como un negocio físico o sucursal específica de una organización (LocalBusiness, 2026). branchCode es un código corto que identifica de forma única un lugar de negocios; las organizaciones matrices suelen asignar este código (branchCode, 2026). parentOrganization nombra la organización principal a la que pertenece una sucursal (parentOrganization, 2026). Google Search Central indica a los editores que definan cada ubicación comercial local como un tipo LocalBusiness, que utilicen el subtipo más específico posible y que proporcionen name y address como propiedades obligatorias (Google Search Central, 2026). Estos tipos ilustran la identidad como datos estructurados, y siguen vigentes en Schema.org versión 30.0 (Schema.org Releases, 2026). El mismo vocabulario no es un esquema de catálogo de Kaleidr, y los datos estructurados para la búsqueda pública no reemplazan la elegibilidad de primera parte para la recogida, la reserva o el acceso específico a la cuenta.
La identidad de ubicación estable es lo que permite que los mapas, la IA, las operaciones y el análisis hablen de la misma rama en los flujos de trabajo de IA espacial.
La lista exacta de campos es específica del producto. El contrato principal es un único locationId estable que abarca el sitio web, el mapa, la IA espacial, el inventario, el análisis, el CRM, las reservas y el soporte, con un ID de organización principal asociado en lugar de un sustituto. No utilice la cadena de dirección como identidad. No combine todas las sucursales en un solo pin de marca, ya que el logotipo es compartido. Los datos de la organización, como el nombre de la marca y las marcas de pago, pueden heredarse. Los datos de ubicación, como las coordenadas, el horario y el teléfono local, deben permanecer en la sucursal. Una tercera capa, el estado operativo, contiene el inventario, la capacidad y los cierres temporales con un updatedAt explícito, ya que el stock del día anterior no es un factor de clasificación.
¿Por qué la sucursal más cercana no suele ser suficiente?
Un mapa de ubicaciones cercanas indica qué sucursales se encuentran alrededor de un marcador. Un producto con múltiples ubicaciones indica qué sucursal puede satisfacer la solicitud del cliente en el tiempo restante. Esta distinción es importante porque la tienda más cercana puede estar cerrada, sin existencias, fuera del área de servicio, no ofrecer el servicio requerido o no ser adecuada para una parada ya planificada durante el trayecto. Una sucursal más lejana puede ser la única abierta, autorizada y accesible antes del siguiente compromiso.
La proximidad es una función de recuperación. La recomendación comienza una vez que existen ubicaciones candidatas: el producto debe determinar si el cliente puede llegar a la sucursal, completar la tarea y aún así realizar la siguiente parada. El artículo sobre la experiencia del cliente mencionado anteriormente describe el mismo proceso: Descubrir → Comparar → Actuar. Descubrir recupera las ubicaciones elegibles. Comparar permite consultar horarios, inventario y tiempos de viaje. Actuar implica indicaciones, recogida, reserva o transferencia de una reserva. Clasificar un marcador cerrado o vacío simplemente porque está unos cientos de metros más cerca invierte ese orden.
Primero, se filtran las ubicaciones no utilizables; luego, la IA espacial clasifica las sucursales que sí pueden satisfacer la solicitud.
¿Cómo se deben filtrar las ubicaciones antes de la clasificación?
Las restricciones estrictas son binarias y corresponden a los responsables de la ubicación, el inventario y la ruta antes de la clasificación. Si la sucursal está cerrada, tiene un horario desconocido cuando el producto requiere un horario conocido, no tiene existencias de la variante solicitada, está fuera del área de servicio, le falta un servicio requerido o le falta una autorización, se debe descartar la candidata. Las preferencias flexibles, como la proximidad, el nivel de fidelización o un tiempo de viaje ligeramente menor, clasifican el conjunto restante de sucursales válidas. Una tienda insignia cerrada no debería resultar ganadora por ser más famosa.
El modelo de lenguaje puede convertir una solicitud como «encontrar este artículo en stock en una tienda de camino a casa» en campos verificables: origen, destino, artículo, requisito de estado de apertura, modo de recogida o visita y límite de tiempo de viaje. Estos campos son consultas a los sistemas que ya poseen la información, no valores inventados. La estructura de cualquier ejemplo es ilustrativa. Lo importante es que el lenguaje vago se convierte en información que el cliente puede corregir sin reiniciar la conversación.
La siguiente comparación es ilustrativa, no un resultado medido de Kaleidr ni de un minorista. Úsela solo para mostrar por qué las opciones necesitan las mismas columnas. Los productos reales deberían completar esas columnas con la información actual de horario, inventario y rutas. La solicitud es un artículo específico en stock, recogida hoy y un presupuesto de viaje de 20 minutos desde el trabajo.
| Candidato | Abierto ahora | Inventario | Viaje desde el trabajo | Recogida |
|---|---|---|---|---|
| Sucursal A | No | En stock | 6 min | No |
| Sucursal B | Sí | Sin existencias | 9 min | Sí |
| Sucursal C | Sí | En stock | 12 min | Sí |
| Sucursal D | Sí | En stock | 24 min | Sí |
La sucursal A es la más cercana, pero sigue sin estar disponible porque está cerrada. La sucursal B está abierta y cerca, pero no puede entregar el artículo. La sucursal C está un poco más lejos, tiene existencias, está abierta y se ajusta al presupuesto de viaje, por lo que se recomienda. La sucursal D sigue siendo una opción, pero el proceso es más lento. La elegibilidad es un filtro. La clasificación establece un orden entre las opciones restantes. La explicación justifica la existencia de la lista de opciones.
¿Cómo deberían clasificarse las sucursales según el tiempo de viaje y el contexto de la ruta?
Una recomendación solo es útil cuando el cliente puede llegar a la sucursal y completar la tarea. La cercanía en línea recta no es un criterio válido. Dos tiendas pueden estar a distancias similares del trabajo, mientras que una está a doce minutos en coche durante el trayecto y la otra a veinticuatro minutos de desvío por la ciudad. La clasificación debería evaluar el origen hasta la sucursal, el tiempo de apertura restante y, cuando el cliente indique una siguiente parada, la posibilidad de desviarse a ese destino como un único criterio de viabilidad.
El descubrimiento de rutas y el descubrimiento de múltiples puntos de referencia son la misma tarea con un origen diferente. Para saber qué tienda está de camino a casa, se necesita la ruta, no solo un radio alrededor del trabajo. Para saber qué clínica puedo visitar entre la oficina y el punto de recogida, se necesitan ambos puntos de referencia. No se le pida al modelo de lenguaje que invente esos minutos después de que el cliente ya haya especificado la restricción. Place Ranking API cubre la clasificación de las sucursales elegibles restantes, incluso cuando la siguiente parada ya está en el trayecto.
Las empresas de área de servicio necesitan una comprobación de cobertura, no una ordenación por tienda más cercana. Las mismas directrices de Perfiles de Negocios de Google distinguen entre las empresas que visitan los clientes y las que se desplazan a sus domicilios, y permiten un perfil por ubicación con personal cuando las áreas de servicio y el personal son independientes. La IA espacial propia aún debe preguntar si el origen o el destino del cliente se encuentran dentro de un polígono de cobertura autorizado y si el equipo puede llegar dentro del plazo prometido. Un marcador en la ciudad siguiente puede estar geográficamente cerca y aun así estar fuera del área de servicio.
¿Cómo se integra Kaleidr en una arquitectura con múltiples ubicaciones?
Una implementación de Kaleidr puede adjuntar una capa espacial conversacional a un mapa y una pila de ubicaciones que el anfitrión ya utiliza. Actualmente, Kaleidr documenta Chat como un producto que se superpone a un mapa que el anfitrión ya renderiza, traza lugares resueltos y ajusta la cámara a medida que la conversación resuelve ubicaciones, con detección automática para Mapbox, MapLibre, Google Maps y Leaflet (Chat attach). El contrato de adjuntar confirma que la conversación con reconocimiento de mapas existe en la interfaz pública actual para desarrolladores. La misma documentación no promete un catálogo de inventario nativo, un motor de reservas ni un feed de horarios.
Estos sistemas deben seguir siendo dependencias de implementación explícitas. Kaleidr puede proporcionar la capa espacial conversacional y la coordinación basada en mapas, mientras que la implementación utiliza las fuentes autorizadas de ubicación, inventario y enrutamiento correspondientes. No dé a entender que Kaleidr es el operador de la tienda o el registro de existencias a menos que se documente una integración específica para la implementación. How to Add AI Chat to Mapbox, Google Maps, and MapLibre cubre los pasos de conexión específicos del renderizador. La página Location Intelligence APIs and Map SDK describe actualmente los SDK, la clasificación y el análisis para productos espaciales. Considere la documentación actual para desarrolladores como el contrato de integración; las páginas de marketing describen el caso de uso, no la lista de fuentes de inventario.
Una clave publicable se utiliza para el SDK del navegador; las credenciales del servidor pertenecen a la capa de aplicación. Kaleidr documenta actualmente esta separación e indica que una clave publicable presentada como portadora es rechazada (Auth & scopes). El inventario privado, la elegibilidad específica de la cuenta, las ubicaciones no publicadas y los registros de clientes deben permanecer dentro del límite del servidor. Private Location Data for AI Map Workflows cubre la autorización para el movimiento y los datos comerciales que el host no expone públicamente. La ubicación del dispositivo es un permiso independiente y no debería ser necesaria cuando el trabajo, el hogar, una cita programada o un punto del mapa seleccionado ya indican un origen mejor.
El estado compartido del mapa mantiene la conversación, las tarjetas y la sucursal en un único ID de ubicación canónico. Al seleccionar una sucursal, se debe resaltar el lugar, mostrar la relación de viaje y conservar las restricciones. Al preguntar qué está más cerca, se deben mantener el mismo artículo, horario y reglas de recogida. Al preguntar qué sucede con las ubicaciones que aceptan devoluciones, se debe volver a verificar la elegibilidad en lugar de crear una nueva red. Una segunda lista invisible, solo para asistentes, incumple este contrato.
¿Cómo deben medir las operaciones la búsqueda y la cobertura de lugares?
Los desplazamientos del mapa y las aperturas de chat son diagnósticos. Las métricas de resultados incluyen inicios de consulta, resultados elegibles devueltos, selección de ubicación, direcciones abiertas, recogida o reserva y transferencia de reserva. Las métricas de calidad incluyen tasa de no resultados, tasa de horas obsoletas, tasa de inventario desconocido y fallo en el cálculo de viajes. Las métricas comerciales dependen del anfitrión: recogida completada, visita reservada, reducción de viajes mal dirigidos o menos llamadas de soporte que comienzan con qué tienda tiene el artículo. Conservar un motivo estructurado de no resultado como cerrado ahora, sin existencias, fuera de área, demasiado lejos, horario desconocido o no autorizado, en lugar de una simple bandera de fallo.
La ubicación geográfica de búsqueda debe mantenerse independiente de la ubicación geográfica del dispositivo. Un cliente que se encuentre en una ciudad puede buscar sucursales en otra. La demanda debe atribuirse a la ubicación buscada, no a la ubicación del dispositivo por defecto. Map Engagement and Location Analytics documenta actualmente la interacción con mapas y lugares, la comparación de ubicaciones, los patrones espaciales y la actividad sobre la que pueden actuar los equipos de producto, inventario y crecimiento. Los sistemas anfitriones siguen gestionando el inventario y las reservas. Una empresa con múltiples ubicaciones puede usar este modelo para determinar qué códigos postales generan búsquedas de disponibilidad sin una sucursal disponible, qué franjas horarias de viaje provocan la pérdida del cliente y qué mercados muestran demanda sin cobertura. Estas preguntas son geográficas, no se basan únicamente en las visitas a la página. Spatial Analytics vs. Web Analytics explica por qué las visitas a la página por sí solas no pueden responderlas.
La IA espacial para múltiples ubicaciones adquiere mayor valor cuando la búsqueda de clientes revela dónde se necesita mejorar la cobertura de ubicaciones, el inventario y los datos de las sucursales.
Los nombres de eventos para anfitriones sugeridos en este artículo son recomendaciones editoriales, no nombres de eventos automáticos documentados de Kaleidr Analytics. Registre la intención, el resultado de elegibilidad, el ID de la ubicación seleccionada y la acción del anfitrión que se produce a continuación. No considere la duración del chat como una métrica de éxito para la búsqueda en múltiples ubicaciones. El rendimiento de la ubicación también requiere contexto: una sucursal inactiva en una zona de baja demanda no representa el mismo problema que una sucursal inactiva en una zona de alta demanda que actualmente no arroja resultados elegibles.
¿Cómo debería comenzar un programa piloto para múltiples ubicaciones?
Comience con una tarea de alto valor, como recomendar una ubicación de recogida disponible en el camino del trabajo a casa dentro de una misma área metropolitana. Mantenga el directorio de ubicaciones, los horarios y el inventario en los sistemas que ya los gestionan. Añada la interacción conversacional del mapa al mapa existente. Limite los candidatos a las sucursales autorizadas, requiera el estado de apertura y el stock del artículo solicitado, calcule el tiempo de viaje desde el origen especificado y mida la selección más la acción del anfitrión que se produce a continuación. Amplíe las categorías, las ciudades y los inquilinos de franquicias solo cuando la primera ventana funcione correctamente.
La búsqueda conversacional no reemplaza la calidad del catálogo, la actualización de horarios ni la disciplina de cumplimiento. Los tiempos de viaje siguen siendo estimaciones. La fiabilidad de las declaraciones de existencias depende de la fuente de inventario que las respalda. Integrar un asistente a un mapa existente suele ser más económico que reemplazar el motor de renderizado, pero el proveedor sigue siendo responsable de la autorización, los contratos con los proveedores y la siguiente acción comercial. Implemente por mercado en lugar de en todas las ubicaciones de la marca a la vez, y trate los datos faltantes como desconocidos en lugar de como datos omitidos.
Explore Kaleidr Spatial AI para agregar búsqueda de ubicación conversacional a un mapa existente. Explore Kaleidr Enterprise para integrar SDK y clasificación a la plataforma que ya utiliza. Explore Kaleidr Analytics para medir la interacción con el lugar y la demanda geográfica en torno a ese recorrido. Confirme las páginas públicas actuales antes de considerar cualquier ejemplo de este artículo como un compromiso funcional de producción.
Preguntas frecuentes
¿Qué es la IA espacial para empresas con múltiples ubicaciones?
La IA espacial para negocios con múltiples ubicaciones combina la intención del cliente, los registros canónicos de sucursales, el horario, el inventario o la disponibilidad, el área de servicio, el tiempo de viaje y las reglas de negocio para que un producto pueda recomendar una ubicación que realmente pueda satisfacer la solicitud. La IA espacial interpreta y explica la solicitud; los sistemas de ubicación y comercio siguen siendo la fuente principal de la información.
¿En qué se diferencia de un localizador de tiendas?
Un localizador de tiendas ayuda al cliente a encontrar y consultar ubicaciones en un directorio. La IA espacial para múltiples ubicaciones añade la elegibilidad y la clasificación según el estado operativo, de modo que el producto puede indicar qué sucursal puede ayudar en ese momento, no solo dónde se encuentran los marcadores.
¿Debe cada ubicación comercial tener un ID único?
Sí. Tanto las directrices de listado público como Schema.org tratan a cada sucursal como un lugar independiente. Las búsquedas, los mapas, la IA y los análisis propios necesitan el mismo ID estable para evitar que se desvíen a registros diferentes.
¿Debe el inventario estar dentro del registro de ubicación?
Mantenga la identidad y la geografía en el registro de ubicación. Almacene el stock en tiempo real, la capacidad y los cierres temporales en una capa operativa con la misma ID de ubicación y una marca de tiempo de frescura explícita.
¿Por qué filtrar antes de clasificar?
Clasificar una ubicación que el cliente no puede usar desperdicia la lista de opciones. Las sucursales cerradas, sin existencias, fuera de la zona o no autorizadas deben eliminarse antes de calcular el tiempo de viaje o las preferencias.
¿La sucursal más cercana es siempre la mejor?
No. La sucursal más cercana puede estar cerrada, vacía o fuera de ruta. Clasifique las sucursales restantes según el contexto de viaje y negocio.
¿Puede Kaleidr funcionar con un localizador de tiendas o un mapa de sucursales existente?
Sí. La documentación pública actual de Kaleidr describe cómo iniciar una conversación sobre un mapa que el servidor ya muestra, incluyendo Mapbox, MapLibre, Google Maps y Leaflet. El servidor sigue siendo propietario del catálogo de ubicaciones y de la siguiente acción comercial.
¿Kaleidr reemplaza nuestro sistema de inventario, reservas o CRM?
No. Las páginas públicas actuales de Kaleidr describen el descubrimiento de mapas conversacionales, los SDK, la clasificación y el análisis. El inventario, los precios, las reservas y el CRM permanecen en los sistemas del servidor o del proveedor, a menos que se documente una integración específica.
¿Cómo deberían medir la IA espacial las empresas con múltiples ubicaciones?
Selección de ubicación, indicaciones, recogida y transferencia al anfitrión, además de los motivos de la falta de respuesta y la relación entre la demanda y la cobertura geográfica. El volumen de chats por sí solo es un indicador de éxito poco fiable.
Referencias
- Kaleidr. AI-Powered Map Experiences for Business. Accessed 11 September 2026. https://kaleidr.com/
- Kaleidr. AI Map Chat for Customer Discovery. Accessed 11 September 2026. https://kaleidr.com/ai
- Kaleidr. Map Engagement and Location Analytics. Accessed 11 September 2026. https://kaleidr.com/analytics
- Kaleidr. Location Intelligence APIs and Map SDK. Accessed 11 September 2026. https://kaleidr.com/enterprise
- Kaleidr. Chat attach. Developer documentation. Accessed 11 September 2026. https://docs.kaleidr.com/sdk/chat-attach
- Kaleidr. Auth & scopes. Developer documentation. Accessed 11 September 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
- Google Business Profile Help. Guidelines for representing your business on Google. Accessed 11 September 2026. https://support.google.com/business/answer/3038177
- Google Business Profile Help. Bulk location management overview. Accessed 11 September 2026. https://support.google.com/business/answer/3217744?hl=en
- Schema.org. LocalBusiness. Version 30.0. Accessed 11 September 2026. https://schema.org/LocalBusiness
- Schema.org. branchCode. Version 30.0. Accessed 11 September 2026. https://schema.org/branchCode
- Schema.org. parentOrganization. Version 30.0. Accessed 11 September 2026. https://schema.org/parentOrganization
- Google Search Central. Local business (LocalBusiness) structured data. Last updated 8 September 2026. Accessed 11 September 2026. https://developers.google.com/search/docs/appearance/structured-data/local-business
- Schema.org. Releases. Version 30.0, 19 March 2026. Accessed 11 September 2026. https://schema.org/docs/releases.html
@misc{kaleidr_home_multiloc_2026_09_11,
title = {AI-Powered Map Experiences for Business},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/}
}
@misc{kaleidr_ai_multiloc_2026_09_11,
title = {AI Map Chat for Customer Discovery},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/ai}
}
@misc{kaleidr_analytics_multiloc_2026_09_11,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_enterprise_multiloc_2026_09_11,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
note = {Accessed 11 September 2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_chat_attach_multiloc_2026_09_11,
title = {Chat attach},
author = {{Kaleidr}},
note = {Developer documentation; accessed 11 September 2026},
url = {https://docs.kaleidr.com/sdk/chat-attach}
}
@misc{kaleidr_auth_scopes_multiloc_2026_09_11,
title = {Auth \& scopes},
author = {{Kaleidr}},
note = {Developer documentation; accessed 11 September 2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}
@misc{gbp_representation_multiloc_2026_09_11,
title = {Guidelines for representing your business on Google},
author = {{Google Business Profile Help}},
note = {Accessed 11 September 2026},
url = {https://support.google.com/business/answer/3038177}
}
@misc{gbp_bulk_locations_multiloc_2026_09_11,
title = {Bulk location management overview},
author = {{Google Business Profile Help}},
note = {Accessed 11 September 2026},
url = {https://support.google.com/business/answer/3217744?hl=en}
}
@misc{schema_localbusiness_multiloc_2026_09_11,
title = {LocalBusiness},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/LocalBusiness}
}
@misc{schema_branchcode_multiloc_2026_09_11,
title = {branchCode},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/branchCode}
}
@misc{schema_parentorg_multiloc_2026_09_11,
title = {parentOrganization},
author = {{Schema.org}},
note = {Version 30.0; accessed 11 September 2026},
url = {https://schema.org/parentOrganization}
}
@misc{google_localbusiness_sd_multiloc_2026_09_11,
title = {Local business (LocalBusiness) structured data},
author = {{Google Search Central}},
note = {Last updated 8 September 2026; accessed 11 September 2026},
url = {https://developers.google.com/search/docs/appearance/structured-data/local-business}
}
@misc{schema_releases_multiloc_2026_09_11,
title = {Releases},
author = {{Schema.org}},
note = {Version 30.0, 19 March 2026; accessed 11 September 2026},
url = {https://schema.org/docs/releases.html}
}