Brief de una página: pedir presupuesto a una empresa de desarrollo de software con IA en Palma de Mallorca y Baleares

Ejemplo de brief de una página (relleno) — negocio ilustrativo en las Islas Baleares, no un caso real publicado como métrica:

• Empresa: grupo de restauración con cocina central en Palma de Mallorca, pop-ups de temporada en Ibiza y proveedor de producto fresco en Menorca.
• Objetivo (90 días): unificar pedidos a cocina, mermas y turnos en un solo panel operativo con alertas por sede.
• Sistemas actuales: Excel + WhatsApp + TPV distintos por local; sin CRM único; facturación en cloud aparte.
• Pico temporada: julio–agosto (Ibiza ×2.5 pedidos; Menorca retrasos de ferry 1–2 días).
• Roles: ops HQ Palma, jefe de cocina, encargados de pop-up, contabilidad.
• Métrica de éxito: −40% tiempo de consolidación de pedidos diarios; mermas visibles por isla antes de las 11:00.
• Fuera de alcance (v1): app cliente final, loyalty, marketing automation.
• Presupuesto orientativo / decisión: piloto 8–10 semanas; go/no-go con datos de dos picos de fin de semana.

Si vas a pedir presupuesto a una empresa de desarrollo de software con IA en Palma o en el resto de Baleares, este formato evita el “cuéntame tu idea en una hora” y fuerza decisiones. No sustituye a cómo elegir una empresa de desarrollo de software con IA: lo complementa con un brief que se puede comparar entre proveedores.

Anatomía del brief de una página

Un brief útil para desarrollo de software a medida en Palma no es un novelón ni un PowerPoint de 40 slides. Es un contrato de conversación. Cada bloque tiene un trabajo concreto:

Objetivo. Una frase con horizonte (30/90 días) y resultado de negocio, no “meter IA”. Si no puedes medirlo, el proveedor inventará demos. En temporada balear, amarra el objetivo al pico (Palma HQ, Ibiza pop-up, Menorca suministro), no a un promedio anual mentiroso.

Sistemas actuales. Lista fría: ERP, TPV, Excel, WhatsApp, CRM, APIs. Sin esto, cualquier propuesta de automatización de procesos con IA es ciencia ficción. Indica quién es dueño de cada sistema y si hay export real.

Pico de temporada. Volumen ×2 o ×3, multiidioma, temporeros, ferries. Si omites Ibiza y Menorca, el presupuesto saldrá pensado para febrero en Palma.

Roles. Quién decide, quién usa a diario, quién audita. Un brief sin roles produce software “para todos” que no usa nadie.

Métrica de éxito. Una o dos cifras: tiempo, error, euros, tickets cerrados. Si la métrica es “mejor experiencia”, estás comprando teatro. Cuando el producto pueda ser multi-sede, alinea también con la lógica de comprar, adaptar o construir un SaaS a medida.

Preguntas frecuentes (antes de enviar el brief)

¿Una página no es poco? Es el filtro. Si el proveedor necesita un RFP de 80 páginas para estimarte un piloto, o no entiende pymes baleares o te está vendiendo discovery infinito. Ampliarás después del primer taller.

¿Debo decir el presupuesto? Sí, al menos un rango o techo. Sin techo, recibirás tres propuestas incomparables. El brief no es una subasta a ciegas.

¿Y si aún no sé si quiero agentes IA o solo software? Decláralo. Puedes pedir un mapa humano/agente/híbrido como en el post sobre mapa de tareas para apps con agentes IA, o un plan de automatización tipo plan 30-60-90. El brief debe dejar la puerta abierta sin mezclar v1 con “todo el negocio”.

¿Sirve el mismo brief para tres proveedores? Sí, y es la ventaja: comparas alcance, supuestos y riesgos, no solo precio. Cambia solo el destinatario, no el problema.

Scorecard: cómo evaluar la respuesta del proveedor

Cuando vuelva el presupuesto, puntúa 0/1 en cada ítem. Un buen partner de software con IA en Palma, Ibiza o Menorca debería sumar al menos 7/10:

1. Repite tu métrica de éxito con sus palabras (no inventa otra).
2. Lista supuestos explícitos (datos, APIs, acceso a TPV, idiomas).
3. Separa piloto vs roadmap; no vende “plataforma completa” en v1.
4. Nombra integraciones concretas de tu stack, no “conectamos con todo”.
5. Incluye modelo de mantenimiento fuera de temporada (crítico en Baleares).
6. Explica dónde hay IA real (clasificación, predicción, agente) y dónde hay reglas.
7. Propone criterios de go/no-go medibles tras el piloto.
8. Habla de permisos, logs y GDPR sin que se lo pidas.
9. Asigna roles del lado del cliente (ops, cocina, contabilidad) en el plan de trabajo.
10. Entrega plazo y precio con bandas de riesgo, no un número mágico fijo sin condiciones.

Si fallan 1, 3 o 6, estás ante una demo disfrazada de propuesta. Usa también el filtro de cuándo merece la pena el software a medida antes de firmar.

Caso ilustrativo: cocina central en Palma, pop-ups en Ibiza, proveedor en Menorca

Imaginemos (escenario ilustrativo) un grupo con cocina central en Palma de Mallorca que abastece dos locales fijos y, en verano, tres pop-ups en Ibiza. El pescado y verdura llegan vía un proveedor en Menorca con ventanas de ferry. Hoy los encargados mandan pedidos por WhatsApp a las 22:00; cocina consolida a mano a las 06:30; contabilidad descubre mermas semanas después.

Con el brief de una página, tres proveedores responden distinto. El A promete “app con IA que predice demanda” sin tocar el TPV. El B propone un panel de consolidación + reglas de stock + alerta de ferry, y deja la predicción para fase 2. El C copia el brief y añade un chatbot para comensales. Solo B pasa el scorecard: misma métrica (−40% consolidación), supuestos claros, piloto acotado a cocina+pop-ups, sin loyalty.

En el piloto ilustrativo, ops de Palma valida el panel; Ibiza reporta pedidos antes del corte; Menorca entra como lead time, no como chat. La IA, si aparece, clasifica excepciones (rotura, sustitución), no “decide la carta”. La lección: el brief corto obliga al proveedor a elegir; el briefing eterno premia al que mejor improvisa en reunión.

Qué debe salir de la primera reunión

No firmes nada tras un café. Exige estos entregables numerados —en 48–72 horas, no “cuando podamos”:

1. Brief devuelto anotado: qué entendieron, qué falta, qué descartan en v1.
2. Alcance del piloto en una tabla corta (flujos in / out).
3. Lista de integraciones y accesos necesarios la semana 1.
4. Riesgos top 5 con mitigación (ferry, TPV, temporeros, multiidioma).
5. Calendario tentativo 8–10 semanas con hitos de demo interna.
6. Precio del piloto + supuestos que, si cambian, mueven el precio.
7. Criterios de aceptación del piloto (números, no adjetivos).
8. Siguiente paso único (taller de datos / kickoff / no-go) con fecha.

Si la primera reunión solo produce “os enviamos una propuesta genérica”, no tienes partner: tienes un PDF.

Envía tu brief de una página

Si operas en Palma de Mallorca, Ibiza o Menorca y quieres que Derek Solutions te responda con alcance y supuestos —no con teatro— envíanos tu brief de una página (aunque esté a medias). Lo devolvemos anotado y te decimos si encaja un piloto de software con IA o si antes hace falta ordenar proceso.

Contacto: derek@dereksolutions.com · +34 680 283 973 · dereksolutions.com.