Portafolio / Contratación pública y venta empresarial
Un comprador público no compra promesas. Compra expediente.
WE PRO INC contesta teléfonos, cubre mesas de despacho y sostiene programas administrativos detrás de primes adjudicados y grandes empresas. El sitio anterior lo contaba como un servicio de recepción de llamadas. Quien evalúa proveedores en un proceso de compra pública no busca eso: busca si estás registrado, con qué códigos, desde cuándo y quién responde a las tres de la mañana. Reescribimos el sitio para que conteste esas preguntas antes que ninguna otra.
01El encargo
El problema no era el servicio. Era la legibilidad.
WE PRO INC —que opera como WeAnswer— llevaba años haciendo el trabajo: turnos de noche, despacho, atención bilingüe, programas administrativos. Lo que no tenía era una forma de demostrarlo a alguien que no lo conocía. Su sitio hablaba el idioma del marketing de servicios: rápido, amable, disponible. El comprador al que quería llegar no habla ese idioma.
Un administrador de subcontratos, un oficial de contratación o el equipo de compras de un prime adjudicado evalúan con una lista distinta: si el proveedor está registrado y activo, bajo qué códigos puede recibir adjudicación, si ya ha trabajado dentro del marco de un prime, si la documentación existe antes de firmar y si la cobertura aguanta un festivo a las tres de la mañana. El encargo fue construir el sitio que contesta esa lista.
Lo que el sitio tenía que resolver
- 01Hacer verificable la empresa, no solo simpática
- 02Separar al prime del comprador de empresa
- 03Poner la credencial antes que la promesa
- 04Publicar los códigos con los que puede recibir adjudicación
- 05Convertir sin pedir una llamada a ciegas
- 06Distinguir un briefing de una cotización desde el primer clic
Nuestro rol
Posicionamiento y arquitectura de contenido, sistema visual, desarrollo del front en React sobre Vite y Tailwind, formularios con validación accesible y capa antispam, endpoint en PHP con registro de solicitudes y entrega al CRM, y despliegue automatizado desde GitHub Actions al hosting del cliente.
02La regla
Lo que decidió el orden de toda la página.
La credencial va antes que la promesa.
El titular no dice que contestamos rápido. Dice registrado, documentado y listo para contestar. A su derecha, antes de cualquier scroll, va la ficha del proveedor: registro en SAM.gov activo, UEI TN6ZDJGJNQJ5, cobertura 24 / 7 / 365 y las dos sedes. Es la información que un comprador copiaría para verificarla por su cuenta, y por eso está donde puede copiarla.
Esa inversión —dato duro arriba, argumento después— gobierna las seis secciones de la página. Cada bloque termina en algo que se puede contrastar fuera del sitio: un registro, un código, una cifra de cobertura. Nada pide que le crean.
RegistradoDocumentadoDisponible
03Las vías de entrada
Cuatro compradores distintos, cuatro entradas.
Un catálogo de servicios obliga al visitante a traducir su problema al vocabulario del proveedor. La página hace lo contrario: se presenta por la situación desde la que se llega, y solo después nombra el servicio que le corresponde.
El prime que necesita un subcontratista.
Tiene un vehículo adjudicado y le falta un socio registrado y con documentación lista para responder por el teléfono, el despacho y el alcance administrativo. Conserva la relación con el cliente; nosotros cargamos la operación y el papeleo.
El sector público con continuidad que sostener.
Centralitas y mesas de despacho que no pueden quedarse sin cubrir. Aquí el argumento no es el precio: es la redundancia entre dos sedes y el objetivo de respuesta.
La empresa multi-sede.
Volumen, horarios y escalado en varias ubicaciones a la vez. Entra por RFQ, no por briefing, y el formulario lo sabe: pregunta volumen, plazo y alcance operativo.
Quien explora agentes de voz con IA.
Automatización con personas detrás. Se presenta como una capacidad más del mismo proveedor, no como un producto aparte — que es exactamente como lo compra un comprador que ya tiene bastante con integrar un vendor nuevo.
04La ficha
Las cifras que el sitio publica para que se comprueben.
Ninguna de estas cifras es una promesa de rendimiento: son parámetros del servicio y datos de registro, publicados para que un comprador los verifique antes de escribir. Están tomadas de la página en producción.
- TN6ZDJGJNQJ5
- UEI en SAM.gov
- 4
- códigos NAICS registrados
- 24 / 7 / 365
- cobertura declarada
- < 20 s
- objetivo de respuesta
- EN / ES / TL
- idiomas de atención
- 2
- sedes operativas
05La clasificación
Los códigos con los que puede recibir adjudicación.
El NAICS no es una etiqueta de sector: es el código bajo el que una entidad puede aparecer en una búsqueda de proveedores y recibir una adjudicación. Publicarlos con su descripción oficial ahorra el correo en el que alguien pregunta si aplica.
- 561421
- Telephone Answering Services
- 561210
- Facilities Support Services
- 541611
- Administrative Management and General Consulting Services
- 561422
- Telemarketing and Call Center Operations
06La página
Seis secciones que se leen como un expediente.
El titular, la ficha de proveedor y las dos rutas de conversión. El sello dorado con el UEI TN6ZDJGJNQJ5 es lo único que usa el oro en todo el sitio: se reserva para la credencial.
Las cuatro situaciones desde las que llega un comprador, abiertas de una en una. Quien se reconoce en una no tiene que leer las otras tres.
Registro, experiencia en subcontratación y documentación, cada uno con la cifra que lo sostiene: dos sedes operativas, cobertura continua y entrega semanal sostenida.
Los 4 códigos con su descripción oficial y, debajo, entidad, UEI y sede. Es la tabla que un administrador de subcontratos copia y pega en su expediente.
Un formulario, dos modos. 8 campos visibles, casillas de alcance antes de escribir y la promesa de lo que llega después: un capability statement y una agenda propuesta, antes de la llamada.
07La conversión
El formulario pregunta lo que pregunta un contracting officer.
Un formulario de contacto genérico pide nombre, correo y mensaje, y deja el trabajo de calificar para la primera llamada. Este pide organismo o vehículo de contratación, plazo, rol de quien escribe y el alcance que necesita cubrir, marcado en casillas antes de redactar nada. Son 8 campos visibles, y cada uno existe porque su respuesta cambia quién debería devolver la llamada.
Los dos modos —Capability briefing y RFQ / subcontract— comparten formulario y cambian lo que se pide y lo que se promete. Quien viene de un prime pide un briefing y recibe un capability statement con una agenda antes de la reunión. Quien viene de una empresa manda una cotización con volumen y plazo. La misma pieza, dos conversaciones distintas.
La defensa contra el ruido empieza en el propio HTML: hay un noveno campo, `company_website`, que ningún visitante ve ni ningún lector de pantalla anuncia. Un bot lo rellena; una persona no puede. El resto de las comprobaciones ocurre en el servidor y no se detalla aquí a propósito — publicar el reverso de un filtro antispam es publicar el manual para saltárselo.
Lo que no se publica
Credenciales, endpoints internos y la configuración del servidor viven fuera del repositorio y fuera de este caso. La integración con el CRM se resuelve del lado del servidor, con claves que nunca entran en el código versionado.
08El recorrido
De un envío a una oportunidad calificada.
Lo que pasa entre que alguien pulsa el botón y el equipo de contratos tiene una oportunidad en el CRM. El orden importa: la solicitud se guarda antes de intentar entregarla.
Formulario
Briefing o RFQEndpoint
ValidaciónRegistro
Solicitud guardadaCorreo
Mesa de contratosCRM
Oportunidad
- 01
Se marca el alcance
El visitante elige modo y casillas antes de escribir. Cuando el mensaje llega, ya viene clasificado.
- 02
Se filtra el ruido
El señuelo del HTML y las comprobaciones del servidor descartan lo automático antes de que consuma un minuto de nadie.
- 03
Se guarda antes de entregar
La solicitud se escribe en el registro del servidor antes de intentar el correo. Si el buzón falla, la oportunidad no se pierde — que es el fallo que arruina un formulario de captación.
- 04
Se acusa recibo
El visitante recibe un código de referencia. Deja de ser un envío al vacío y pasa a ser algo por lo que puede preguntar.
- 05
Se entrega
El correo llega a la mesa de contratos y la oportunidad entra al CRM, donde se le da seguimiento como a cualquier otra.
El diagrama es el camino que recorre una solicitud. Cuántas lo recorren es dato del cliente y no se publica aquí.
09El sistema visual
Sala de operaciones, no centro de llamadas.
La categoría entera se ilustra con auriculares y sonrisas. Ese registro trabaja en contra cuando el lector es un comprador público: promete amabilidad donde se está evaluando fiabilidad. El sistema apunta al otro lado.
Casi negro, verde de estado, oro de credencial.
Un fondo #07120B con temperatura verde, el #74CC48 reservado a la acción y al estado —lo que está activo, lo que está cubierto— y el oro #C9A94A usado una sola vez por pantalla, siempre sobre una credencial. Un acento que aparece en todas partes deja de significar algo.
Sora titula, Poppins lee, la monoespaciada mide.
El dato operativo —UEI, códigos, objetivos de cobertura, etiquetas de sección— va siempre en monoespaciada. Es el registro en el que se escribe un expediente, y separa de un vistazo lo que es afirmación de lo que es dato.
Rejilla editorial y paneles compactos.
Reglas finas, tarjetas, tablas y fotografía en duotono contenido. La página se parece a un tablero de operación y no a un folleto, que es la promesa que el servicio tiene que sostener después.
10La entrega
Lo que se construyó y lo que falta.
El sitio en producción son 6 secciones sobre un front en React compilado con Vite, con el sistema de diseño centralizado en tokens de Tailwind, un endpoint propio en PHP para las solicitudes y despliegue automatizado: cada push a la rama principal construye, publica y comprueba que el sitio sigue respondiendo.
Lo que queda por hacer se dice igual de claro, porque un caso que solo cuenta la mitad buena no sirve para decidir nada. No hay analítica ni seguimiento de errores instrumentado. No hay monitor de disponibilidad más allá de la comprobación del despliegue. Las imágenes se sirven en JPEG, sin canal automático a WebP o AVIF. Las tipografías se cargan desde Google Fonts en lugar de servirse desde el propio dominio. Y el registro de solicitudes necesita una política formal de retención, acceso y copia a medida que crezca el volumen.
Ninguna de esas cosas es un defecto escondido: son el siguiente tramo de trabajo sobre una base que ya cumple lo que se le pidió — presentar la empresa a un comprador público, dejarse verificar y recoger la conversación cuando llega.
Entregado
- 01Posicionamiento y arquitectura de contenido
- 02Sistema visual y tokens de diseño
- 03Front en React sobre Vite y Tailwind
- 04Ficha de proveedor y tabla NAICS verificables
- 05Formulario de doble modo con validación accesible
- 06Capa antispam y endpoint de solicitudes
- 07Registro de solicitudes previo a la entrega
- 08Entrega al CRM desde el servidor
- 09Despliegue automatizado con comprobación posterior
11El valor
Lo que cambia cuando un proveedor se deja comprobar.
Dejar de pedir confianza y empezar a dar pruebas.
El sitio no afirma ser el mejor proveedor de atención telefónica. Publica su número de registro, sus códigos, su cobertura y sus sedes, y deja que quien evalúa haga lo que iba a hacer de todos modos: comprobarlo.
Esa es la diferencia entre un folleto y un expediente. Un folleto pide una llamada para explicarse. Un expediente deja que el comprador avance solo hasta el punto en que la llamada ya vale la pena.
VerificableClasificadoOperativo
beleafdesign
¿Tu sitio resiste una evaluación de proveedor?
Si vendes a empresas grandes o al sector público, tu web se lee con una lista de comprobación en la mano. Podemos revisar qué contesta hoy y qué tendría que contestar antes del primer correo.
Hablemos de tu proyecto