El estándar abierto para servicios

Cualquier persona puede crear un servicio. Cualquier agente puede coordinarlo.

Servicialo define el lenguaje universal para crear, entregar y verificar servicios — para humanos y para agentes AI.

◆ Estándar abierto◆ Legible por máquinas◆ Diseñado para humanos
01 — Definición

¿Qué es un servicio?

Antes de crear uno, hay que entender qué es realmente.

Un servicio es una promesa de transformación entregada en un momento y lugar específico.

A diferencia de un producto, un servicio no se puede almacenar, revender ni devolver. Se consume en el momento en que se entrega. Eso lo hace fundamentalmente diferente — y es por eso que necesita su propio estándar.

📦
Producto
Se almacena
Se revende
Se devuelve
Se envía
Existe sin el creador
Servicio
Se consume al entregarse
Cada instancia es única
Requiere presencia
Se verifica, no se rastrea
Existe solo en el momento
Experiencia
Se diseña para ser memorable
Involucra los sentidos
Genera conexión emocional
Viajes, gastronomía, eventos
Todo servicio puede serlo
02 — Origen

Todo servicio nace de tres fuentes

No necesitas una idea revolucionaria. Necesitas reconocer qué ya tienes.

🏠
Desde un Activo
Tienes algo que otros necesitan

Un activo es cualquier recurso que posees y que puede generar valor para otros. No necesitas hacer nada nuevo — solo facilitar acceso.

Pregunta clave
¿Qué tienes que otros necesitan temporalmente?
Activo subutilizado + Acceso facilitado = Servicio
Un departamento vacío
Hospedaje temporal
Airbnb nació así
Un auto que usas 4hrs/día
Transporte bajo demanda
Uber nació así
Una cocina comercial
Cocina fantasma para terceros
Equipamiento médico
Arriendo de box clínico por hora
Un terreno
Estacionamiento por hora
Una bodega
Almacenamiento bajo demanda
🎯
Desde una Ventaja
Sabes algo que otros no
⏱️
Desde tu Tiempo
Puedes hacer lo que otros no quieren o no pueden
Dato clave
Los servicios más valiosos combinan dos o tres fuentes. Un kinesiólogo usa su ventaja (certificación + experiencia) aplicada en su tiempo, a veces con un activo (equipamiento especializado). Mientras más fuentes combines, más difícil de replicar y más valioso el servicio.
03 — Anatomía

Las 8 dimensiones de un servicio

Para que un agente AI pueda coordinar un servicio, necesita entender estas 8 dimensiones. Para que un humano pueda diseñar un buen servicio, también.

Qué
La actividad o resultado que se entrega
Sesión de kinesiología / Reparación eléctrica / Consulta legal
Quién entrega
El proveedor del servicio
Kinesiólogo certificado / Electricista SEC / Abogado tributario
Quién recibe
El cliente beneficiario, con pagador separado explícitamente
Paciente (paga FONASA) / Empleado (paga empresa)
Cuándo
Ventana temporal acordada
2026-02-10 de 10:00 a 10:45
Dónde
Ubicación física o virtual
Clínica / Domicilio / Videollamada
Ciclo
Posición actual en los 8 estados del ciclo de vida
Cobrado → próximo: Verificado
Evidencia
Cómo se prueba que ocurrió
Registro GPS + duración + firma del cliente
Cobro
Liquidación financiera con estado independiente del ciclo
$35.000 CLP · cobrado · paquete prepago
04 — Ciclo de vida

8 estados universales

Todo servicio — desde una consulta médica hasta una reparación del hogar — pasa por el mismo ciclo.

Estado 1 de 8
Solicitado
El cliente o su agente AI define qué necesita, cuándo y dónde. El sistema busca proveedores compatibles.
¿Por qué 8 estados?
Menos estados pierden información crítica — sin separar "Entregado" de "Documentado", no puedes distinguir "el proveedor dice que ocurrió" de "la evidencia está registrada". Sin separar "Cobrado" de "Verificado", no puedes saber si el cliente aceptó el resultado. 8 es el mínimo viable para que un agente AI pueda verificar con certeza que un servicio fue solicitado, entregado, documentado, cobrado y verificado.
Flujos de excepción

Cuando las cosas no salen según el plan

Un estándar robusto no solo define el camino feliz. Define qué pasa cuando algo falla.

Inasistencia del cliente
Confirmado → Cancelado (no_show)
Cobra penalidad según política, libera horario del proveedor para reasignación. Incrementa contador de inasistencias del cliente.
Inasistencia del proveedor
Confirmado → Reasignación → Agendado
Reasigna proveedor automáticamente, notifica al cliente del cambio. Proveedor original flaggeado.
Cancelación
Cualquier estado pre-entrega → Cancelado
Aplica política de cancelación según tiempo restante antes del servicio.
Disputa de calidad
Entregado → Disputado
Cobro congelado. Se solicita evidencia adicional de ambas partes. Resuelve a: Cobrado → Verificado (proveedor gana) o Cancelado (cliente gana, balance restaurado).
Reagendamiento
Agendado/Confirmado → Reagendando → Agendado
Busca nuevo horario compatible para ambas partes, mantiene el mismo proveedor.
Servicio parcial
En Curso → Parcial
Documenta lo entregado, ajusta cobro proporcionalmente, agenda continuación si es necesario.
05 — Resolución de disputas

Cuando hay desacuerdo

Un mecanismo que no depende de buena voluntad, no requiere un juez centralizado, y que un agente AI puede ejecutar con la misma confianza que un humano.

Flujo de resolución
Cualquier parte puede abrir una disputa dentro del plazo definido. Se congela el cobro automáticamente.
Actor: cliente | proveedor | agente
Contrato de servicio
Antes de que un servicio pase de "Solicitado" a "Agendado", ambas partes aceptan un contrato que define las reglas del juego. Una vez aceptado, ninguna parte puede modificarlo unilateralmente — ni el proveedor, ni el cliente, ni la plataforma.
evidencia_requerida
Qué evidencia debe registrarse para considerar el servicio entregado
check_in + check_out + ficha_clinica_firmada
plazo_disputa
Ventana de tiempo para abrir una disputa después de Entregado
48 horas
política_cancelación
Reglas de penalización por cancelación según tiempo restante
0% si >24h, 50% si 2-24h, 100% si <2h
política_inasistencia
Qué ocurre si una parte no se presenta
Cliente: cobra 100%. Proveedor: reasignación + penalidad
arbitraje
Configuración del arbitraje por pares si aplica
1 árbitro si monto < $50, 3 si >= $50
monto_máximo_disputa
Monto máximo que puede disputarse sin escalamiento externo
$500 USD equivalente
80/20
El 80% de las disputas se resuelven automáticamente comparando evidencia registrada contra el contrato. Sin intervención humana, sin discrecionalidad, sin demora. El 20% restante — evidencia ambigua o contradictoria — escala a árbitros del mismo vertical profesional que votan en 48 horas. El mecanismo de confianza no depende de que alguien elija cumplir: las reglas se ejecutan porque fueron aceptadas antes.
06 — Evidencia por vertical

Qué constituye prueba

Cada vertical define qué evidencia se necesita para que un algoritmo pueda resolver el 80% de las disputas sin intervención humana.

🏥
Salud
4 tipos de evidencia requerida
Registro de entrada
auto
Timestamp GPS del proveedor al llegar
Registro de salida
auto
Timestamp GPS del proveedor al salir
Ficha clínica firmada
manual
Registro clínico firmado por profesional y paciente
Adherencia al plan
manual
Checklist del plan de tratamiento ejecutado
Regla de resolución algorítmica
Si check-in/out existen y ficha clínica está firmada por ambas partes, servicio entregado. Si falta ficha o firma, escalar.
🏠
Hogar
4 tipos de evidencia requerida
⚖️
Legal
3 tipos de evidencia requerida
📚
Educación
3 tipos de evidencia requerida
¿Por qué separar por vertical?
Un kinesiólogo y un electricista entregan servicios radicalmente distintos. Pedirle a ambos la misma evidencia no funciona. Definir evidencia por vertical permite que el algoritmo resuelva disputas automáticamente: si la ficha clínica está firmada, el servicio de salud se entregó. Si las fotos antes-después existen, la reparación del hogar se completó. Sin juicio subjetivo — solo verificación objetiva contra un contrato aceptado por ambas partes.
07 — Principios

Las reglas del estándar

Servicialo se construye sobre 7 principios que aplican a cualquier servicio en cualquier industria.

Principio 01
Todo servicio tiene un ciclo
No importa si es un masaje o una auditoría. Los 8 estados son universales.
Principio 02
La entrega debe ser verificable
Si no puedes probar que el servicio ocurrió, no ocurrió. Servicialo define qué constituye evidencia válida para que humanos y agentes AI puedan confiar en ella.
Principio 03
El pagador no siempre es el cliente
En salud paga la aseguradora. En corporativo paga la empresa. En educación paga el apoderado. El estándar separa explícitamente al cliente del pagador.
Principio 04
Las excepciones son la regla
Inasistencias, cancelaciones, reagendamientos, disputas. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan.
Principio 05
Un servicio es un producto
Tiene nombre, precio, duración, requisitos y resultado esperado. Definido así, cualquier agente AI puede descubrirlo y coordinarlo.
Principio 06
Los agentes AI son ciudadanos de primera clase
El estándar está diseñado para que un agente AI pueda solicitar, verificar y cerrar un servicio con la misma confianza que un humano.
Principio 07
Cobrar no es lo mismo que pagar
Un cobro se aplica a la cuenta del cliente cuando el servicio es entregado y documentado — siempre 1:1 con una sesión. El pago es el movimiento de dinero, que puede ocurrir antes (paquete prepago), después (reembolso) o en lote (factura mensual). Son eventos independientes.
08 — Módulos

Arquitectura por capas

Adopta solo lo que necesitas. Core cubre el ciclo completo de un servicio. Los módulos agregan capacidades para operaciones más complejas.

Servicialo Core
estable
Todo lo que necesitas para modelar un servicio profesional de principio a fin. Ciclo de vida completo, las 8 dimensiones del servicio, flujos de excepción, prueba de entrega y cobro.
Para quién
Cualquier plataforma que coordine servicios profesionales — desde una clínica de kinesiología hasta un marketplace de limpieza.
Incluye
  • Ciclo de vida (8 estados universales)
  • 8 dimensiones del servicio
  • Flujos de excepción (cancelación, inasistencia, reagendamiento, disputa)
  • Prueba de entrega con evidencia por vertical
  • Cobro con separación explícita de cargo vs pago
  • Protocolo MCP para agentes AI (23 herramientas)
Servicialo/Finanzas
en diseño
Distribución de pagos entre las partes involucradas. Define cómo se reparte el ingreso entre profesional, organización e infraestructura — con reglas claras de liquidación.
Para quién
Plataformas que intermedian pagos entre clientes y profesionales, o que cobran comisiones y arriendo de infraestructura.
Incluye
  • Distribución de pagos a tres destinatarios
  • Tipos: porcentaje | monto_fijo | mixto
  • Momentos de liquidación: por_sesión | mensual | al_cierre
  • Concepto de infraestructura (box, equipamiento, sala)
Servicialo/Disputas
en diseño
Resolución formal de disputas con arbitraje algorítmico y por pares. Define el flujo completo desde apertura hasta resolución final, con evidencia válida por vertical.
Para quién
Plataformas con volumen suficiente para justificar arbitraje estructurado — o donde el monto por servicio hace que las disputas sean económicamente relevantes.
Incluye
  • Flujo de disputa estructurado
  • Resolución algorítmica (~80% de los casos)
  • Arbitraje por pares del mismo vertical
  • Evidencia válida definida por vertical
Un implementador puede ser Servicialo Core certified sin adoptar los módulos opcionales. Los módulos están diseñados para agregarse de forma independiente según la complejidad de tu operación.
09 — El estándar

Protocolo de Entrega de Servicios

Cualquiera puede implementarlo.

Protocolo de Entrega de Servicios v0.3
# ── SERVICIALO v0.3 ──────────────────
# Las 8 dimensiones de un servicio
 
servicio:
id: texto
tipo: texto
vertical: texto
nombre: texto
duración_minutos: entero
 
proveedor:
id: texto
credenciales: texto[]
puntaje_confianza: número
organización_id: texto
 
cliente:
id: texto
pagador_id: texto
 
agenda:
solicitado_en: fecha_hora
agendado_para: fecha_hora
duración_esperada: minutos
 
ubicación:
tipo: presencial | virtual | domicilio
dirección: texto
sala: texto
coordenadas:
lat: número
lng: número
 
ciclo_de_vida:
estado_actual: enum[8]
transiciones: transición[]
excepciones: excepción[]
 
prueba_de_entrega:
entrada: fecha_hora
salida: fecha_hora
duración_real: minutos
evidencia: evidencia[]
 
cobro:
monto:
valor: número
moneda: texto
pagador: referencia
estado: pendiente | cobrado | facturado | pagado | disputado
cobrado_en: fecha_hora
pago_id: referencia
documento_tributario: ref
 
# ── MÓDULO: Servicialo/Finanzas (en diseño) ──
 
distribución:
profesional:
tipo: porcentaje | monto_fijo | mixto
valor: número
liquidación: por_sesión | mensual
organización:
tipo: porcentaje | monto_fijo
valor: número
infraestructura:
tipo: monto_fijo | porcentaje
valor: número
concepto: box | equipamiento | sala
 
# ── MÓDULO: Servicialo/Disputas (en diseño) ──
 
resolución:
estado: ninguna | en_revisión | en_arbitraje | resuelta
evidencia_evaluada: evaluación[]
resultado: a_favor_proveedor | a_favor_cliente | ambiguo
arbitraje:
árbitros: referencia[]
votos: voto[]
resolución_final: referencia
resuelta_en: fecha_hora
🔨
Construir
Implementadores
Implementa el estándar en tu plataforma. La especificación y el programa de certificación están en GitHub.
Ver especificación en GitHub
🎯
Ofrecer
Proveedores
Ofrece servicios en un formato que agentes AI entienden y pueden coordinar.
🤖
Conectar
Agentes AI
Descubre, agenda y verifica servicios con un protocolo estandarizado.
10 — Por qué Servicialo

Un idioma común para agentes

El problema
Sin un protocolo estándar, cada plataforma de servicios habla su propio idioma. Un agente AI que quiere operar un negocio de servicios necesita una integración custom para cada uno.
Servicialo es el idioma común. Si una plataforma lo implementa, cualquier agente puede operar ese negocio sin integración adicional.
Modo descubrimiento
El agente puede ver
Buscar organizaciones, consultar disponibilidad, listar servicios. Sin credenciales. 4 herramientas públicas.
Modo autenticado
El agente puede actuar
Agendar, verificar entrega, cobrar, cerrar el ciclo completo. Con credenciales. 20 herramientas en 6 fases.
La diferencia entre un agente que informa y un agente que opera.
11 — Servidor MCP

Hecho para agentes

Servicialo expone sus herramientas como un servidor MCP, permitiendo que agentes de IA descubran y coordinen servicios profesionales de forma nativa.

Diseñado para developers que construyen agentes AI sobre negocios de servicios profesionales en LATAM. Si tu agente necesita agendar, verificar entrega o cobrar un servicio — sin importar la plataforma — este es el protocolo.
No es para usuarios finales de plataformas Servicialo-compatible — esas plataformas gestionan la conexión internamente.
Flujo del agente
Seis fases del ciclo de vida del servicio — 23 herramientas
1
DescubrimientoQué hay disponible
registry.* · check_availability · services.list
2
EntenderDimensiones y reglas del servicio
service.get · contract.get
3
ComprometerIdentidad del cliente y booking
clients.get_or_create · scheduling.book · confirm
4
Ciclo de vidaEstado y transiciones
lifecycle.get_state · transition · reschedule · cancel
5
Verificar entregaEvidencia de que ocurrió
delivery.checkin · checkout · record_evidence
6
CerrarDocumentación y cobro
documentation.create · payments.*
Un agente bien diseñado sigue este orden: Descubrir → Entender → Comprometer → Gestionar → Verificar → Cerrar. Cada fase tiene sus tools. El estándar garantiza que cualquier agente pueda completar el ciclo completo con cualquier implementación compatible.
Modo descubrimiento
Sin credenciales — 4 herramientas públicas
// Sin credenciales — modo descubrimiento
npx -y @servicialo/mcp-server
registry.searchBuscar organizaciones por vertical y ubicación
registry.get_organizationDetalle público de una organización
scheduling.check_availabilityConsultar horarios disponibles
services.listCatálogo público de servicios
Modo autenticado
npm →
Con credenciales — 23 herramientas totales
// Configuración en Claude Desktop
{
"mcpServers": {
"servicialo": {
"command": "npx",
"args": ["-y", "@servicialo/mcp-server"],
"env": {
"SERVICIALO_API_KEY": "tu_api_key",
"SERVICIALO_ORG_ID": "tu_org_id"
}
}
}
}
Las credenciales las obtiene cada organización desde la plataforma Servicialo-compatible que utilice.
service.get8 dimensiones del servicio
contract.getContrato pre-acordado
clients.get_or_createBuscar o crear cliente
scheduling.bookAgendar → Solicitado
scheduling.confirmConfirmar → Confirmado
lifecycle.get_stateEstado + transiciones
lifecycle.transitionEjecutar transición
scheduling.rescheduleReagendar (excepción)
scheduling.cancelCancelar con política
delivery.checkinCheck-in → En Curso
delivery.checkoutCheck-out → Entregado
delivery.record_evidenceEvidencia por vertical
documentation.createRegistro del servicio
payments.create_saleCrear venta/cargo
payments.record_paymentRegistrar pago
payments.get_statusEstado de pago
Implementaciones compatibles
Cualquier plataforma que implemente la especificación Servicialo puede conectarse a este servidor MCP.
Ver lista en GitHub →