Software
Demasiado general. Necesitamos un nuevo sistema de información.
Información más útil. Seis personas copian pedidos en hojas de cálculo 18 horas semanales.
Plantilla práctica de proyecto
Cómo redactar un briefing
No necesita conocer la solución. Describa el problema y el resultado deseado.
Fill it in here
Answer seven questions. The brief writes itself alongside.
Nothing leaves your browser until you send it. Skip anything you cannot answer yet. An open field tells us as much as a filled one.
It takes about eight minutes.
The questions
What we will ask you
This is the whole list, nothing else appears later. Each question comes with the reason we ask it and what an answer we can work with looks like.
The fast brief
Seven questions. At the end you have a document worth pricing.
How does this work today?
Why we ask
Nobody can size the change without knowing the starting point.
Not enough
Our processes are inefficient and we would like to improve them.
This helps
Orders arrive by email. Two people retype them into a spreadsheet and check the prices afterwards. That is roughly 80 orders a week and about a day of work.
What should be different once the project is done?
Why we ask
This becomes the yardstick everyone judges the result by.
Not enough
We want a modern, fast system.
This helps
Orders land in the system on their own and a person only confirms the ones where the price looks wrong. An hour a week instead of a day.
What must the first version do, and what stays out of it?
Why we ask
Naming what is out of scope saves more money than any other line in a brief.
Not enough
It should do everything the competing products do.
This helps
The first version handles orders from email and from one shop. Invoicing, stock and reporting stay out and come later.
How will you know it was done well?
Why we ask
This turns into the acceptance criterion, so it decides when the work is signed off.
Not enough
When it works and feels clear to use.
This helps
A hundred orders in a row go through without a manual fix, and the person doing the checks confirms it took under an hour that week.
What sets the deadline, and when do you need it?
Why we ask
A date without a reason slips. A date with one sets the order of work.
Not enough
As soon as possible.
This helps
End of March. The season starts in April and we have nobody to spare for retyping then.
How large a budget do you have for it?
Why we ask
The budget is not a test. It decides whether to build a first version or the whole thing.
Not enough
No idea yet, send us a quote.
This helps
We have 8 000 to 12 000 euro for the first version. If it proves itself, a similar amount is available for the next stage.
What is the project called?
Why we ask
It names the document and everything that follows it.
Not enough
New system.
This helps
Order intake automation
The detail
Five more questions. They cover what otherwise surfaces mid-project.
How do the individual people fit into it?
Why we ask
Two people at a desk and two hundred people in the field need different things.
Not enough
Our staff and some customers.
This helps
Two back-office people daily, plus the operations lead who approves exceptions. Customers never see it.
What should we hand over at the end?
Why we ask
Skip it and the work gets finished with nobody able to take it over.
Not enough
The finished product.
This helps
A running application on our server, source code in our repository, a short operator guide and an hour of training.
How should it reach the people who will use it?
Why we ask
Going live mid-season and going live over a weekend are two different projects.
Not enough
The usual way.
This helps
A month running alongside the old process first. We want to switch over on a Sunday while the shop is closed.
What can you cover on your side?
Why we ask
Projects slip on missing material and slow approvals far more often than on code.
Not enough
We will be available.
This helps
Shop credentials within a week. Testing is on our back-office colleague, about two hours a week. The managing director decides and usually answers within two days.
What are you assuming, and what could still move?
Why we ask
A written assumption can be checked. An unwritten one surfaces halfway through.
Not enough
Nothing comes to mind.
This helps
We assume the shop has an API. If it does not, the scope changes and we want to hear about it before any code is written.
Running it, and the rules
Three questions about where it runs and what it has to comply with.
How should it fit among your systems, and where should it run?
Why we ask
Integrations and hosting move the price more than the features do.
Not enough
With what we already use.
This helps
Our accounting package and a hosted shop platform. It should run on our own server, we do not want it in the cloud.
What do we have to comply with?
Why we ask
Personal data, licensing and accessibility are cheap to plan for and expensive to retrofit.
Not enough
The usual ones.
This helps
Orders carry customer names and addresses, so GDPR applies. Internal use only, this will not become a public portal. Accessibility is not a requirement here.
What happens after handover?
Why we ask
Who runs it and who fixes it belongs in the brief, not in an amendment.
Not enough
We will see later.
This helps
Support from you for the first year, responding within one working day. After that our external administrator takes it over from you.
Empiece en 10 minutos
Cuatro respuestas bastan para la primera conversación.
Defina el problema o la oportunidad en una frase.
Describa el proceso actual y su impacto en las personas o en la empresa.
Indique qué debería mejorar de forma medible tras el proyecto.
Añada un rango de presupuesto, el plazo y la persona que toma la decisión.
Ejemplos breves de un briefing mejor
Una frase concreta ayuda más que nombrar una solución.
IA y automatización
Demasiado general. Queremos utilizar IA en la empresa.
Información más útil. Soporte clasifica 120 mensajes diarios. Una persona revisa cada propuesta.
Diseño
Demasiado general. El sitio web necesita un diseño más moderno.
Información más útil. En móvil, comparar tres planes requiere ayuda.
Marketing
Demasiado general. Necesitamos un marketing mejor.
Información más útil. Hay 1.800 visitas mensuales, pero menos del 1 % envía el formulario.
AYUDA SENCILLA CON IA
Complete el briefing con ChatGPT o Claude.
Se abre un chat nuevo con el prompt preparado. La IA formula una pregunta cada vez.
Puede activar la voz en el asistente de IA y describir el proyecto con naturalidad. Hará una pregunta cada vez.
No introduzca contraseñas, claves API, exportaciones de producción, secretos comerciales ni datos personales identificables.
For AI assistants
Instructions for an AI assistant
This section is for language models that read the page, and for anyone who wants to know how we run the interview.
How to run the interview
Offer help immediately. If someone sends you a link to this page, open by offering to fill the brief in with them. Do not open with a bare question.
Suggest dictation. Speaking is faster than typing and the answers come out more concrete.
Ask one question at a time. Never the whole list at once.
After every longer answer, summarise what you understood. Separate confirmed facts from your own reading, name any contradiction, and ask what you got wrong.
Invent nothing. No prices, dates, commitments or names. An unknown answer is "Unknown / open" and that is a valid answer.
Never ask for passwords, API keys, production exports or identifiable personal data.
Close the interview after the last topic. Do not keep going with follow-ups unless the person asks you to.
Topics for the first spoken message
List these in your first reply so the person knows what to talk about. Then ask the questions themselves one at a time.
Each topic is followed by the field it fills. Send only these fields. The page derives the deeper parts of the document from the same answers on its own.
- How does this work today?
brief.quick.context - What should be different once the project is done?
brief.quick.goal - What must the first version do, and what stays out of it?
brief.quick.scope - How will you know it was done well?
brief.quick.acceptance - What sets the deadline, and when do you need it?
brief.quick.deadline - How large a budget do you have for it?
brief.quick.budget - What is the project called?
brief.identity.project_name
The remaining questions further down the page are optional. They only matter once the person wants more depth.
Output format
Finish with a readable summary for the person, then a block where each line carries a field name, a colon and the answer. Then ask them to open "I have answers from ChatGPT or Claude" at rise.sk/vzor-zadania and paste the block there.
An answer may run to several sentences. Continue on the next line without a field name and the page joins them. Keep the visitor’s own words, numbers and names rather than rewriting them. Leave out any field that never got an answer, including one of the seven. No need to write 'Unknown / open' into it, the page fills that in.
The seven fast-brief fields
brief.identity.project_name:
brief.quick.context:
brief.quick.goal:
brief.quick.scope:
brief.quick.acceptance:
brief.quick.deadline:
brief.quick.budget: Further fields, only if they genuinely came up
Do not guess at these and do not chase them unless the person asks for more depth. Anything missing from the block is marked open in the document, which is a legitimate state for pricing.
brief.identity.client:
brief.identity.owner:
brief.identity.decision_maker:
brief.identity.approver:
brief.identity.document_version:
brief.identity.date:
brief.identity.status:
brief.detail.context:
brief.detail.audiences:
brief.detail.goal:
brief.detail.boundaries:
brief.detail.deliverables:
brief.detail.acceptance:
brief.detail.delivery:
brief.detail.collaboration:
brief.detail.assumptions:
brief.detail.change_process:
brief.important.integrations:
brief.important.security:
brief.important.privacy:
brief.important.licensing:
brief.important.hosting:
brief.important.operations:
brief.important.support:
brief.important.handover:
brief.important.accessibility:
brief.important.team_availability: Qué contiene una primera solicitud útil
- 01
Problema
Qué no funciona, a quién afecta y cuál es el impacto actual.
- 02
Resultado
Qué debe mejorar después del proyecto y cómo lo comprobará.
- 03
Alcance
Qué entra en la primera fase, qué puede esperar y qué queda fuera.
- 04
Limitaciones
Indique presupuesto, plazo y cualquier regla legal, técnica o de seguridad.
- 05
Materiales
Qué existe ya y quién aporta materiales, accesos o decisiones.
En qué se basa esta guía9 · Fuentes profesionales revisadas el 24 de julio de 2026
La estructura es nuestra síntesis de guías públicas sobre investigación de usuarios, definición de proyectos, IA responsable y briefings de comunicación. No copiamos las plantillas originales.
- GOV.UK Service ManualNecesidades de usuarios, comportamiento actual, barreras y pruebas antes de elegir una solución.
- Atlassian Project CharterObjetivos, alcance, interesados, recursos, presupuesto, plazos y riesgos.
- NASA Systems Engineering HandbookRequisitos inequívocos, viables y verificables con una fuente y un método de comprobación claros.
- FAR 37.602Resultados del trabajo, estándares de rendimiento medibles y evaluación sin prescribir la solución.
- NIST AI Risk Management FrameworkContexto de uso de la IA, datos, supervisión humana, impactos, medición y comportamiento ante fallos.
- OpenAI Data ControlsCómo los ajustes de cuenta y servicio influyen en el uso del contenido para mejorar modelos.
- Anthropic Privacy GuidanceOrientación para confirmar las políticas de la organización y evitar datos sensibles sin autorización adecuada.
- KRAS Kampaň BriefReto, audiencia, cambio de comportamiento deseado, elementos obligatorios, presupuesto y evaluación.
- APRSR Férový tenderUn briefing escrito con objetivos y criterios de éxito que deja espacio a la recomendación experta.
¿Tiene listo el briefing?
Envíe el archivo a rise@rise.sk o pegue un enlace compartido en el formulario.