La colección
Cómo nace un servicio: un archivo Markdown validado por Zod. El frontmatter, los campos y la separación contenido/diseño.
Ver la pieza Servicios · La guía
Cómo se crea una página de servicio: del dato a la conversión
La guía exacta de cómo crear una página de servicio profesional en este sitio, pieza por pieza: dónde vive el dato, cómo se comunica el valor, qué incluye, cómo se trabaja, qué se responde y cómo se cierra.
Mientras Módulos documenta las piezas con las que se arma cada página, Niveles documenta los tipos de página por profundidad y la guía de Productos documenta el flujo de crear un producto, esta serie documenta el FLUJO de crear una página de servicio. Son seis decisiones encadenadas, cada una con su propia ficha.
Un servicio bien presentado no enumera tareas: orienta la decisión del cliente. Esta guía documenta cómo construir esa orientación —desde el archivo Markdown hasta el botón de WhatsApp— sobre el mismo sistema, con las mismas piezas, sin código extra.
Concepto
¿Qué es una página de servicio profesional?
Una ficha (L3) que presenta un servicio a fondo: qué resuelve, qué incluye, cómo se trabaja y cómo contratar. No enumera tareas — orienta la decisión del cliente.
Una página de servicio profesional es la que responde cuatro preguntas en orden: ¿esto es lo que necesito? (hero), ¿qué recibo exactamente? (alcance), ¿cómo se trabaja? (proceso) y ¿qué tengo que hacer para contratarlo? (conversión). Si alguna falta, el visitante busca las respuestas en otro sitio —o no las busca y no contrata.
En este sistema, cada servicio vive como un archivo Markdown en una Content Collection. La ficha de detalle se genera sola, validada por Zod y alimentada por el mismo dato que el menú y el schema. Esta guía documenta cada decisión del camino: de la colección al botón de WhatsApp.
La guía
Cómo se crea una página de servicio, pieza por pieza
Las 6 piezas del flujo, cada una como tarjeta: foto, nombre, qué resuelve y sus ideas clave. Entra a cualquiera para verla a fondo, con el mismo molde de las series Módulos, Niveles y Productos.
Crear una página de servicio bien hecha son seis decisiones encadenadas: dónde vive el dato (la colección), cómo se comunica el valor (el copy), qué promete exactamente (el alcance), cómo se trabaja (el proceso), qué se responde antes de contratar (las objeciones) y cómo se cierra la venta (la conversión).
Cada tarjeta abre una de ellas. Es el MISMO card del catálogo —coherencia sobre todo—, porque reusar piezas es justo lo que esta guía enseña. Cada pieza tiene su página con el molde de 10 secciones: qué es, para qué sirve, qué lleva, cómo se ve en móvil, dónde encaja y cómo se construye.
El copy
La propuesta de valor en el hero: cómo comunicar qué resuelve el servicio y para quién en los primeros 5 segundos.
Ver la piezaEl alcance
Qué incluye el servicio: la lista honesta de entregables, la nota de precio transparente y las expectativas claras.
Ver la piezaEl proceso
Los 3 pasos del trabajo: predecible, reproducible y sin incertidumbre para el cliente que aún no firmó nada.
Ver la piezaLas objeciones
El FAQ del servicio: las preguntas reales del cliente, el manejo de objeciones y la cualificación del lead.
Ver la piezaLa conversión
El cierre del servicio: WhatsApp-first, CTAs honestos y el SectionMenu que convierte sin presionar ni saturar.
Ver la piezaPor dentro
Cada pieza, por dentro
El índice te dice qué es cada pieza; aquí la abrimos. Mismo formato para todas: qué resuelve, qué decisiones implica y en qué se fija al construirla.
Es el mismo bloque «a fondo» del catálogo del sitio —información a la izquierda, galería a la derecha, idéntico para cada pieza—. Reusar el patrón es, otra vez, la lección: el sitio se arma con piezas que ya existen.
Aquí está cada pieza del flujo abierta con la misma estructura. Las mismas seis que ves arriba como tarjetas; entra a cualquiera para la versión completa con anatomía, variantes y recetas de código.
La pieza a fondo
La colección
Un servicio en este sitio NO es markup dibujado a mano: es un archivo Markdown en src/content/servicios/. Cada .md es un servicio; su frontmatter (título, descripción, categoría, imagen, pricing, includes, FAQs…) se valida contra un esquema Zod .strict() en build-time, que rechaza campos desconocidos y errores de tipo antes de publicar. La ficha de detalle (/servicios/<slug>) se genera sola a partir de esa colección.
La regla canónica (D1): toda entidad repetible vive en una Content Collection, nunca hardcodeada en un .astro. El servicio es el DATO; el componente es la VISTA. Separar los dos permite que quien escribe el contenido trabaje con texto Markdown y que quien mantiene el diseño toque el componente una sola vez, para todos los servicios. Agregar un servicio = crear un .md; borrarlo = borrarlo.
- Un servicio = un archivo .md en src/content/servicios/ (sin tocar código)
- Zod .strict() valida el frontmatter en build: el error aparece antes de publicar
- Una fuente → card en catálogo + ficha L3 + schema Service + FAQ Page
- Contenido y diseño separados: editar texto ≠ tocar el componente
La pieza a fondo
El copy
El copy del servicio es lo que el visitante lee en los primeros 5 segundos para decidir si esto es para él. El Hero tiene cuatro piezas: badge (contexto de sección), title + accent (la entidad central con la keyword), subtitle (la propuesta de valor directa) y descRight (dos párrafos que amplían sin repetir). El copy no describe el servicio desde adentro —desde el proceso y las herramientas—; lo presenta desde el problema que el cliente vino a resolver.
La regla dura del hero: NO lleva CTAs ni botones de venta. El hero orienta y valida que el visitante llegó al lugar correcto; los CTAs de conversión van al cierre (SectionMenu + CTABanner), donde el visitante ya tomó la decisión. Un hero con botones agresivos presiona antes de informar —sube el rebote sin aumentar las conversiones—.
- Badge → etiqueta de contexto: «Servicio · Consultoría»
- title + accent → la entidad central con la keyword principal del servicio
- subtitle → propuesta de valor en 1 frase directa (qué resuelve, para quién)
- descRight → 2 párrafos complementarios que amplían; CERO CTAs en el hero
La pieza a fondo
El alcance
El alcance honesto es la lista de lo que el cliente va a recibir, escrita antes de que empiece el trabajo. El campo includes[] del frontmatter alimenta la sección «Qué incluye» del L3: cada ítem es un entregable concreto, no una promesa vaga. La lista se complementa con una pricing note opcional que establece el modelo de precio (bajo cotización, rango estimado, desde $X) sin inventar cifras que no aplican a todos los casos.
Por qué importa: el cliente decide contratar cuando entiende qué recibe. Una lista de alcance clara —«Propuesta por escrito con tiempos y costo»— baja la fricción del contacto inicial. El lead llega cualificado porque ya leyó qué incluye y cómo se cotiza. Y la nota de precio honesta evita el descarte de quien asume un precio fuera de rango —o el malentendido de quien asume que es gratis.
- includes[] = lista de entregables concretos, no promesas vagas ni adjetivos
- pricing.note = nota de precio honesta: modelo de cobro sin cifras inventadas
- Alcance por escrito antes de empezar: base del trato claro entre las partes
- Lead cualificado: quien llega ya leyó qué incluye y cómo funciona el precio
La pieza a fondo
El proceso
El proceso de trabajo son los pasos que el cliente va a vivir desde el primer contacto hasta la entrega. Tres pasos es el molde canónico del sistema: Diagnóstico → Propuesta y ejecución → Entrega y seguimiento. El número importa menos que la claridad: el cliente necesita saber qué sigue después de escribir por WhatsApp, para que ese primer clic no le parezca saltar al vacío.
Un proceso documentado también reduce la carga de soporte: las preguntas «¿qué hacen exactamente?», «¿cuánto tarda?» y «¿cómo me mantendrán informado?» se responden en la página antes de que lleguen al chat. Y cuando ocurre un imprevisto en el trabajo real, tener el proceso visible —y haberlo cumplido— es lo que sostiene la confianza del cliente.
- 3 pasos canónicos: Diagnóstico · Ejecución · Entrega (molde reproducible)
- Proceso visible = lead informado: sabe qué sigue antes de escribir por WhatsApp
- Verbos en primera persona plural: «Analizamos», «Ejecutamos», «Entregamos»
- Reduce soporte: las dudas de «¿qué hacen?» se resuelven en la página
La pieza a fondo
Las objeciones
Las FAQs del servicio son las preguntas reales que el cliente tiene antes de contratar —y que, si no se responden en la página, llegan por WhatsApp o, peor, generan abandono. El FAQAccordion las muestra como details/summary nativo (sin JS, accesible), y el esquema FAQPage las emite como datos estructurados para aparecer como resultado desplegable en Google. El campo faqs[] del frontmatter es la fuente única.
Cada FAQ tiene un trabajo: resolver una objeción, aclarar un malentendido o cualificar al cliente. «¿Atienden mi zona?» filtra por geografía. «¿Puedo combinar servicios?» habilita el upsell. «¿Cuánto tarda?» maneja la expectativa. Las FAQs mal escritas responden preguntas que nadie hace —y dejan sin respuesta las que sí importan. Las buenas se redactan desde el cliente, no desde el servicio.
- faqs[] en el frontmatter = fuente única: la página Y el schema FAQPage del mismo dato
- FAQAccordion details/summary nativo: sin JS, accesible, rendimiento máximo
- Cada FAQ = una objeción resuelta o un lead cualificado (no relleno informativo)
- Preguntas desde el cliente: qué pregunta en el chat, no qué queremos explicar
La pieza a fondo
La conversión
La conversión en un catálogo de servicios es WhatsApp-first: el cliente escribe su necesidad, el asesor responde, y ahí se cierra el trato. El CTA principal es siempre waUrl(WA_MESSAGES.servicios) —nunca un wa.me escrito a mano (regla D4)—; eso centraliza el número y el encoding en un solo lugar. El SectionMenu de cierre enlaza a los otros servicios y al contacto, para que quien no está listo tenga otro camino sin desaparecer.
El anti-patrón más común: múltiples CTAs compitiendo en el cierre. Un solo CTA principal («Cotizar este servicio»), un botón secundario («Ver otros servicios») y el WhatsApp flotante de respaldo. Añadir un formulario debajo del WhatsApp, un pop-up al scroll y un chat en vivo al mismo tiempo genera fatiga de decisión: el visitante no sabe a dónde ir y no va a ningún lado. Menos fricción = más contactos.
- waUrl(WA_MESSAGES.servicios): nunca wa.me hardcodeado en componentes ni páginas
- SectionMenu de cierre: otros servicios + catálogo + contacto + CTA WhatsApp
- Un solo CTA principal de conversión por página: cero competencia de botones
- WhatsApp flotante = respaldo siempre visible; el CTA del cierre = la acción principal
Responsive y móvil
La guía, en el teléfono
La rejilla no «se encoge»: se reordena. De varias columnas a una sola, con cards táctiles y el CTA de WhatsApp siempre accesible con el pulgar.
La vitrina (.showcase) está pensada mobile-first: nace en una columna y crece conforme hay ancho. Nunca al revés: el teléfono es el caso base, el más simple y robusto, y el escritorio solo añade columnas.
La conversión WhatsApp-first también se respeta en móvil: el botón tiene área táctil de 44 px, feedback al tap y es el único CTA primario —sin competencia—. Abajo, los tres patrones con su vista en el teléfono y su receta.
E
1 · De varias columnas a una
La vitrina es mobile-first: declara una columna y crece con repeat(…, 1fr) en escritorio. Baja a una columna en el teléfono sin tocar la card.
/* La vitrina de la guía es mobile-first: 1 → 2 → 3.
Arranca en UNA columna en el teléfono y crece con el ancho disponible.
Nunca al revés: el caso base (teléfono) es el más simple y robusto. */
.showcase { display: grid; grid-template-columns: 1fr; gap: var(--sp-5); }
@media (min-width: 640px) { .showcase { grid-template-columns: repeat(2, 1fr); } }
@media (min-width: 1024px) { .showcase { grid-template-columns: repeat(3, 1fr); } }E
DatoCopyAlcance Ver la pieza44px
2 · Cards cómodas de tocar
Toda la card es un único enlace con área táctil de 44 px y feedback al tap. En el teléfono se toca con el dedo —el cursor no existe—, y el área pequeña genera abandono.
/* mobile.css · área táctil mínima de 44 px en toda la card. */
@media (max-width: 1024px) {
a, button, [role="button"] {
-webkit-tap-highlight-color: rgba(91, 61, 245, .15); /* feedback al tap */
}
}
@media (max-width: 768px) {
/* chips de subcategoría con altura tappable */
.ccard__sub { min-height: 44px; display: inline-flex; align-items: center; }
}E
Cotizar por WhatsApp44px
3 · CTA WhatsApp siempre accesible
El CTA principal de conversión tiene área táctil de 44 px, está al alcance del pulgar y se construye siempre con waUrl(): nunca un wa.me hardcodeado. El flotante refuerza sin competir.
/* El CTA de conversión siempre via waUrl(): cero wa.me hardcodeados. */
import { waUrl, WA_MESSAGES } from '@config/site'
// ✓ CORRECTO: número y mensaje centralizados; cambiar uno cambia todos.
<a href={waUrl(WA_MESSAGES.servicios)} target="_blank" rel="noopener">
Cotizar por WhatsApp
</a>
// ✗ INCORRECTO: número hardcodeado → se desactualiza sin avisar.
<a href="https://wa.me/525500000000?text=Hola">Cotizar</a>Preguntas frecuentes sobre la guía
¿En qué se diferencia esta guía de la de Productos?
Productos documenta el FLUJO de crear un producto (colección, categorías, imágenes, precio, ficha, schema). Servicios documenta el FLUJO de crear una página de servicio profesional (colección, copy, alcance, proceso, objeciones, conversión). Misma estructura de 10 secciones, distinto contenido: el servicio no tiene variantes ni carrito; su conversión es WhatsApp-first.
¿Cuántas piezas tiene la guía?
Seis, en orden de flujo: la colección (el dato), el copy (el hero), el alcance (qué incluye), el proceso (cómo se trabaja), las objeciones (FAQ) y la conversión (el cierre). Cada una con su página de detalle y el molde canónico de 10 secciones.
¿Agrego un servicio en el código o en Markdown?
En Markdown: creas un archivo .md en src/content/servicios/ con su frontmatter (título, descripción, categoría, imagen…). La ficha de detalle se genera sola desde la colección. Para que aparezca en el menú y la landing, también añades el servicio al array SERVICES en src/config/site.ts.
¿Puedo tener servicios con precio público y otros «bajo cotización»?
Sí. El campo pricing del frontmatter es completamente opcional. Si lo omites, el sistema usa el modelo «bajo cotización» y el CTA abre WhatsApp con un mensaje pre-armado (waUrl). Si lo incluyes, puedes poner una nota (pricing.note) con el rango o el modelo, sin inventar una cifra fija que no aplique a todos los casos.
¿Los servicios también emiten schema JSON-LD?
Sí. La ficha de detalle (/servicios/