A Development Brief Checklist for Event and Venue Businesses

Start with the outcome and use only the relevant checklist

Include the current process, the outcome you need and the constraints a supplier must work within before listing features. A development brief is a practical account of what your business does, what its users need to do and what the project needs to take into account. It gives suppliers context to assess a suitable approach rather than asking them to build a predetermined list of screens and functions.

Start with the shared checklist: explain your business model, the people involved, how the process works today and what you want to improve. Describe the normal customer journey, but also note exceptions, handovers between staff or systems, and who is responsible at each stage. These details help suppliers understand the work behind the screens and identify where a proposed solution needs to fit your operation.

Then complete only the workflow modules that apply: event listings, ticketing, conference registration, wedding venue bookings or trade fairs. For example, a venue handling date enquiries may need a different module from a promoter selling tickets; you do not need to include every option. Adapt the checklist to your business, and give the same brief to each supplier you approach. Clear, consistent information makes it easier to compare proposals and see whether each supplier has understood your requirements.

Describe the business, its users and the current process

Give suppliers a clear picture of how the business works before describing individual event journeys. Copy the prompts below into the brief and answer them with your current process in mind; if a step differs by event type or customer, note the difference.

• Business model: Identify whether you operate as a venue, promoter, conference organiser, event-listing operator, trade-fair team or a combination. Briefly describe what you provide and how customers or partners currently engage with you.
• People involved: Name the groups who use or support the service, such as attendees, organisers, exhibitors, venue staff, sales staff and administrators. For each relevant group, say what they need to find, submit, approve, update or manage.
• Current journey: Set out the steps from first discovery or enquiry to booking, payment or confirmation, then any relevant changes and follow-up. Say who takes each step and what information they need at that point. Include offline contact if it forms part of the process.
• Tools and handovers: List the forms, email inboxes, spreadsheets, booking systems and payment providers involved. Explain where information is entered, who receives it next and whether staff have to copy details between tools or chase a response.
• Problems to solve: Describe specific friction rather than broad labels. For example, note where an enquiry waits for an owner, where the same details are entered more than once, or where staff struggle to find the latest booking information. Include how the issue affects the work or customer journey, without assuming the cause.
• People who can clarify the brief: Name the project owner and identify who can answer questions about day-to-day operations, sales, content, existing technology and business priorities. Note any decisions that still need agreement internally.

This gives suppliers a usable starting point: the business context, the people involved and the work the proposed solution may need to support. It also helps them distinguish a process problem from a gap in the current tools.

Map each journey, handover and exception

Once you have chosen the relevant workflow, describe it as a sequence rather than a list of features. This helps a supplier see what the business needs to do, where work passes between people and what the digital service must support.

• Write down the stages in order. Start with the first public or internal action and continue until the business has recorded the final outcome. For example, an enquiry may be received, checked, assigned to a member of staff, followed up and then confirmed or closed.
• Name the person or role at each stage. Note who submits information, who reviews it, who makes a decision and who takes the next action. If work moves between sales, operations and finance, show where each handover happens.
• Record what moves with the task. For each stage, list the information staff need to see, what they add or change, and what the next person or customer receives. Include relevant forms, messages, documents or records, but do not send suppliers unnecessary personal data.
• List the statuses the business needs. Use the words staff use, such as submitted, awaiting review, confirmed, declined, cancelled or changed. Say who can update each status and what should happen next. This makes it easier to spot when a single “complete” status would hide important differences.
• Describe exceptions that change the work. Explain what happens when information is incomplete, a date changes, someone cancels, capacity is reached or a request needs another team’s approval. State who resolves each case, what they need to know and how the customer is kept informed.
• Separate staff decisions from system support. Mark which steps need a person to assess or approve a request, and which actions the service should help with, such as routing a task, recording a change or sending a message. Do not assume every step should be automated.
• Attach examples of the current process. Share relevant forms, email templates, spreadsheet columns or process notes, with unnecessary personal details removed. Point out which parts are still useful and where staff currently have to copy information, chase updates or resolve uncertainty.

For each journey, a simple table or process note can capture: stage, role, information received, action taken, next recipient, status and exception. Suppliers can then ask focused questions about gaps before proposing a solution.

Add the event-listing module if you publish events

If your business publishes event listings, add this module to the brief and describe how a listing gets from its first draft to the visitor. Include only the stages and features your service needs.

• Who supplies each listing? State whether staff create listings, organisers submit them, or both. Explain whether organisers need an account or send details another way, and who checks submissions before they appear.
• What information is required? List the fields for each event, such as its title, description, dates and times, venue or location, images, organiser contact details and links. Mark which fields are essential and whether any information changes for different event types.
• What happens at each stage? Set out the relevant steps, such as draft, submitted, reviewed, approved, published, amended, withdrawn or expired. For each, name who acts, who is notified and what information or decision they need.
• How are errors and changes handled? Explain how an organiser can correct a listing, what staff do when details are missing, and who decides whether a disputed or unsuitable submission is changed or removed. Note how changes to dates, venue or availability reach visitors.
• How should visitors find events? Describe the routes people need, such as browsing categories, searching by location or date, filtering results, or opening an event-detail page. Say what visitors should be able to do from that page.
• Where does an external link take them? Identify any ticketing or booking service linked from a listing. Explain what the visitor should understand before leaving your site, and whether they should return to the listing service afterwards.

Use a redacted example listing and a recent amendment or withdrawal to show suppliers how the process works in practice.

Add the ticketing module if you sell or allocate tickets

Use this module if your business sells tickets or manages ticket allocations. Describe the buying journey and the work staff must do around it, so a supplier can see where a website, existing ticketing product or custom system might fit.

• Ticket types and availability: List the ticket categories, allocation rules, capacity limits and any release stages. Explain who sets or changes availability, and what should happen when a category sells out or an allocation needs to be held back.
• Attendee journey: Map how someone chooses tickets, completes checkout and receives confirmation. Include what they can do afterwards, such as request a change or cancellation, and what information they need before arriving.
• Staff workflow: Say who creates ticket allocations, manages guest lists and handles changes, cancellations or refund requests. For each exception, explain who decides what happens, who updates the record and who tells the attendee.
• Entry checks: Describe what staff need to see or do at the door, and how the business expects tickets or attendee details to be checked. Note any fallback process staff use if a ticket cannot be found or checked.
• Systems and handovers: Name any payment provider or ticketing system the project needs to connect to. Explain what information should pass between systems, who handles failed or disputed transactions, and which support requests go to your team, supplier or provider. Ask suppliers to make these responsibilities explicit in their proposal.
• Payment responsibilities: Check with your payment provider or compliance adviser which responsibilities apply to your arrangement and what steps your business needs to take to protect account data.

Include a redacted example of a ticket confirmation, staff allocation or entry list if it helps show the information and handovers involved. Mark any parts of the current process that should remain unchanged, as well as the points you want a supplier to improve.

Add the conference module if you manage delegates and sessions

Use this module if your project includes conference registration, delegate management or session choices. Describe the steps from registration through to arrival, and make clear which parts your existing tools already handle.

• Who registers: Say whether delegates register themselves, an employer or organiser registers a group, or staff enter registrations. Identify any separate routes for speakers, sponsors, staff or invited guests.
• Registration and allocation: List the information and choices needed to complete a registration, such as delegate type, booking details or access requirements. Explain whether places are confirmed immediately, reviewed by staff, allocated by an organiser or placed on a waiting list.
• Changes and exceptions: Describe how staff handle cancellations, substitutions, duplicate registrations, late requests and changes to delegate details. Say who can approve each change and how the delegate is told what has happened.
• Programme choices: If attendees select sessions, workshops or other activities, explain when they make their choices, whether places are limited, and how staff update the programme or resolve clashes and full sessions.
• Staff view: Specify what registration and programme information organisers need before the event and during it. Include the tasks they must complete, such as finding a delegate, checking a booking or answering an attendee query.
• Check-in and attendance: Set out how staff identify attendees on arrival, record attendance and deal with a missing, changed or unrecognised registration. Name the staff roles involved and how information passes from registration staff to on-site teams.
• Systems and handovers: List any registration, email, scheduling or other tools that need to connect. For each, explain what information moves in or out, who maintains it, and which system should be treated as the authoritative record if details differ.
• Scope boundary: Mark which steps must be included in this project and which can remain in an existing product or be handled manually. This helps suppliers propose a proportionate registration journey rather than assuming every conference needs bespoke software.

Add the wedding venue module if you handle date enquiries and bookings

Use this module if your venue handles wedding date enquiries and bookings. Describe the steps from a couple’s first enquiry to a confirmed booking; leave wider wedding-planning features out unless they are part of the project.

• Enquiry: What can a couple ask about, and which details does your team need to assess the request? Note how enquiries arrive, who reviews them and where they are recorded.
• Availability: Explain how staff check a requested date and what they tell the couple. If you use date holds, specify who can create one, how it can be changed or released, and what action confirms the date.
• Quote: List the information staff need to prepare a quote, who prepares and approves it, how it is sent, and how the venue records the couple’s response or decision.
• Booking and handover: Set out what must happen for a booking to become confirmed. Identify who passes information from sales to venue operations, what information moves with it, and what status each team needs to see.
• Exceptions: Describe what staff do when the requested date is unavailable, an enquiry needs follow-up, the couple changes their requirements, or details change before confirmation. Say who owns each follow-up and how its outcome is recorded.
• Scope boundary: State whether the project covers venue enquiries, availability, quotes and booking status only, or needs to connect with other systems. Name any existing tools and the handovers they support. Include broader wedding-planning functions only if your venue actually needs them.

Use the prompts that match your process. A supplier can then assess whether the workflow belongs in a website, an existing product or a purpose-built system.

Add the trade-fair module if you manage stands and visitor registration

If you manage a trade fair, describe exhibitor bookings and visitor registration as separate journeys, even if they share information or tools. This helps suppliers scope what each user needs to do and where staff must step in.

• Exhibitor interest: How does an exhibitor first enquire or apply? Record what they submit, who reviews it, how incomplete applications are followed up and what happens if the application is declined or needs approval.
• Stand selection and booking: Explain whether exhibitors choose a stand, request one or receive an allocation. Describe how staff check availability, manage stand status, confirm a booking and record any later changes or cancellations.
• Exhibitor information and communication: List the details staff need from exhibitors and what exhibitors need in return, such as booking status, stand details or next steps. Note who sends each communication and what triggers it.
• Visitor registration: Map how visitors find registration, what information they provide, what confirmation they receive and how staff handle incomplete registrations or changes before the event.
• Staff roles and handovers: Identify who manages exhibitor enquiries, approves applications, updates stand availability and supports visitor registration. Describe when work passes between teams and what status or information the next person needs.
• Shared information: Specify what, if anything, needs to pass between exhibitor management, visitor registration and event staff. For example, say whether staff need a shared view of event details or separate records, and which system should be treated as the source of truth.
• Current tools and exceptions: Name the systems, spreadsheets, exports or manual handovers involved. Give examples of unusual cases suppliers should account for, such as a booking change after confirmation or an unavailable stand, and explain how staff resolve them.

Do not assume these journeys belong in one system. Tell suppliers which parts must connect and which can remain in existing tools, so they can compare a focused website or integration with a broader build.

Record content, data, integrations and operating constraints

Give suppliers a clear inventory of the information, systems and operating conditions the project must work with. This helps them assess what can stay in existing tools, what needs to connect, and what needs further investigation before the scope is agreed.

• Content and information: List the material the website or system needs, such as event details, venue information, schedules, exhibitor records or booking information. For each item, say who owns it, who keeps it up to date, who approves changes and where it currently lives. Note whether content or records need to be moved from spreadsheets, a website or another system, and flag anything that needs checking before it can be reused.
• Integrations and handovers: Name the systems the project must work with, such as a booking, ticketing, payment, customer relationship or email platform, where relevant. Describe the information that should pass between each system, which way it should move and at what point in the journey. For example, explain whether a booking enquiry should be sent to a staff member for review, or whether confirmed registration details need to reach another system. Ask suppliers to identify any dependencies or decisions they need from the existing provider.
• Roles and access: List the people who will use the system, including internal staff and any external users such as exhibitors or event submitters. Describe what each role needs to view, add, edit, approve or report on. Include who can change important records and who handles corrections when information is incomplete or incorrect.
• Mobile use and accessibility: Explain where and how people will use the service, including whether staff need to update information away from a desk or visitors need to complete a journey on a mobile device. Ask suppliers how their proposed approach will support mobile use and accessibility, and how they will establish which accessibility requirements apply to your organisation and project. Check how the requirements apply with an appropriate adviser.
• Personal information: Identify what personal information each journey may collect, how your business expects to use it, and which staff or systems need to handle it. State who will check the requirements that apply and ask appropriate advisers or providers to confirm responsibilities. Treat this as a scoping prompt, not a conclusion about what the business is required to do.
• Operating constraints: Record existing supplier commitments or tools that cannot readily be changed, internal approval routes, and who can provide information or make decisions. Note event dates that affect planning, busy periods when staff input may be limited, and what ongoing support the business expects after launch. If a constraint is uncertain, mark it for discussion rather than assuming a supplier can work around it.

Where possible, attach a redacted sample of the relevant content or record structure. Do not include personal information merely to illustrate a workflow; describe the fields and process instead, and agree separately how any examples should be shared.

Separate must-haves from later options and define success

Prioritise the requirements so suppliers can distinguish what the first release must do from what could wait. For each item, record why it matters, who needs it and how you will check that it has been delivered.

• Essential for the initial project: Include requirements that are necessary for a customer to complete a key journey or for staff to carry out a core task. Explain the consequence if the requirement is missing. For example, if staff need to review a booking enquiry before confirming a date, say what information they need to see and what action they must be able to take.
• Preferred if practical: List improvements that would make the service easier or more useful, but are not a condition of handling the core process. Note any trade-off you would accept if including them affects the approach.
• Possible later phase: Record ideas that may be valuable but do not need to be included initially. This keeps future options visible without making them part of the immediate scope.

For each essential requirement, state what can remain manual at first. A team might, for instance, continue to review a submitted request outside the system rather than expecting automatic approval. Be clear about who will do that work, what information they need and how the result gets back to the customer or colleague.

Describe the intended business outcomes in practical terms, such as making an enquiry process clearer, helping visitors find relevant events or reducing repeated administration. Treat these as aims, not promised results. Then agree acceptance measures that can be checked against the brief, rather than relying on a general judgement that the work feels complete.

• Can a person complete a named journey using the agreed steps and information?
• Can a staff member carry out an agreed task, such as reviewing a submission or updating event details?
• Do the right people receive the information needed for the next handover?
• Are stated exceptions handled as agreed, or clearly referred to a person?

Ask suppliers to identify their assumptions, exclusions and dependencies in their proposal. This could include decisions the business still needs to make, information or access the supplier needs, and work that sits outside the proposed scope. Resolve unclear ownership early; otherwise, content, approvals or decisions can delay progress or leave a requirement uncovered.

Include who will prepare and approve content, who will make business decisions during the work, and who will manage the service afterwards. Ask what maintenance or support is available and what responsibilities remain with your organisation. Suppliers can then explain what they are proposing, what they have not included and what they need from you before work proceeds.

Choose the simplest suitable approach and ask suppliers for clear proposals

Choose an approach based on the workflows and gaps in your brief, not on an assumption that the answer must be custom software. A standard platform may be suitable if its existing process fits how your business works and the remaining differences can be handled through configuration or a change to internal processes. Ask suppliers to identify where that fit is strong and where staff would need to work differently.

A smaller website project may be enough if the main need is to explain your offer, publish event information or route enquiries. Your existing systems can continue to handle bookings, delegate records or other operational work. Be clear about which system remains responsible for each task, so the website does not create an extra step or leave staff unsure where to update information.

If your current systems cover the core workflow but information does not pass cleanly between them, ask whether an integration could address the gap. Describe what information needs to move, from which system to which, when it should move and who needs to act if it does not. This gives suppliers a specific problem to assess without assuming that a new platform is needed.

Custom software may be worth exploring when an important journey, handover or exception is not adequately supported by available products. Set out what the existing approach cannot handle and the operational consequence. A supplier should be able to explain why a tailored build is appropriate, as well as what could instead be configured, simplified or kept in an existing tool.

To compare proposals fairly, give each supplier the same priorities, workflow descriptions and constraints. Ask them to explain:

• how their recommended approach supports the journeys you described, including exceptions and handovers;
• which requirements are included, which are excluded and which depend on another system, supplier or decision;
• what assumptions they have made, and what they need from your team;
• how content, information and existing systems would be handled; and
• who would be responsible for operating and maintaining the solution after launch.

Compare the reasoning and fit, not just the number of features listed. A proposal that covers every requested feature may still leave a critical handover unclear. If suppliers interpret a requirement differently, resolve that point before comparing their approaches. You can also ask them to separate the proposed first release from later options, so the essential workflow is not obscured by additions.

If you would like DevAgency to consider your project, use Request a project quote and describe the business, the workflow you need to improve and the approach you are considering. The checklist gives you a starting point for explaining what matters without deciding in advance that custom software is the answer.