A brief template for your registration build partner

Two briefs can describe the same event and get two very different builds. One says “conference registration, three ticket types, client brand attached.” The other names the audiences, the payment rules, the fields legal has signed off, who approves the copy and the date the invitation email goes out. The first gets a quote full of assumptions. The second gets a fixed scope you can take to your client.

The difference is rarely effort. It is knowing which questions the build will hit, and answering them before the build hits them. Below is the brief we would want from any agency handing over an event website and registration, on Cvent, Stova, Swoogo or Whova. Copy it, fill in what you know, and mark what you don’t. A gap you have flagged is a question. A gap nobody noticed is a change request three weeks later.

The template

Paste this into a doc and send it with whatever the client gave you.

EVENT BASICS
- Event name, format (in person / virtual / hybrid), venue and city
- Event dates, and the date registration needs to open
- Expected number of registrants
- Platform and account (whose account, what licence, Flex or Classic if Cvent)

AUDIENCES AND REGISTRATION PATHS
- Every audience: attendee, speaker, sponsor, VIP, staff, guest
- Open, invite-only or approval-based, per audience
- Group registration or guests allowed? Who pays for them?
- Sessions, tracks or activities to choose, with capacities and waitlists

TICKETS, PRICING AND PAYMENTS
- Ticket types and prices, early-bird dates, discount codes
- Currencies, tax and invoicing rules
- Payment gateway and who owns the merchant account
- Refund, cancellation and substitution policy

DATA FIELDS, PRIVACY AND CONSENT
- The fields you need, marked required or optional, and why
- Consent wording signed off by the client's legal or privacy team
- Privacy policy link and data retention rules

BRAND ASSETS AND DESIGN FILES
- Brand guidelines, logo files, fonts and licences
- Key visual, imagery and any campaign creative already approved
- Design files in their source format, if you have them

CONTENT OWNER AND APPROVALS
- Who writes and supplies the copy, and by when
- Who approves design, who approves the live build
- How many review rounds the client expects

INTEGRATIONS
- CRM and marketing automation (Salesforce, Marketo, HubSpot, other)
- Which fields need to reach which system, and who owns that system
- Badge printing, check-in and onsite technology, if in scope

LANGUAGES
- Languages the site and emails need, and who supplies the translations

ACCESSIBILITY
- Any standard the client has committed to
- Accessibility and dietary questions the form needs to ask

LAUNCH DATE AND MILESTONES
- Registration open date, invitation send date, close date
- Fixed internal dates: client review, board sign-off, campaign launch

POST-LAUNCH OWNERSHIP
- Who edits the site and handles registrant queries after launch
- Who owns changes, reporting and the next event in the series

Now, why each part is there.

Event basics and dates

The platform, the account and the registration open date shape everything else. A Cvent Flex build and a Swoogo build answer the same brief in different ways, and an open date four weeks away is a different project from one twelve weeks away. Tell your partner the date on day one. If it is not realistic, you want to hear that before you have promised it to your client, not after.

What goes wrong without it: a scope written for the wrong account or licence, and a timeline nobody tested against the calendar.

Audiences and registration paths

This is the section that decides how complex the build is. A single public attendee path is simple. Attendees, speakers, sponsors and VIPs, each with their own questions, approvals and pricing, is several builds sharing one front door. Conditional logic, approvals and guest flows are all straightforward to build when they are known up front, and awkward to bolt on later.

What goes wrong without it: the sponsor path turns up in week three, the logic gets rebuilt around it, and every path needs testing again.

Tickets, pricing and payments

Payments carry the most dependencies on people outside the project. The merchant account usually belongs to the client’s finance team, tax rules may need someone to sign them off, and the refund policy has to exist before the confirmation email can describe it. None of that is hard. All of it takes calendar time you do not control.

What goes wrong without it: a finished build waiting on a gateway credential, with the open date getting closer.

Data fields, privacy and consent

Every field is a small reason for someone to abandon the form, so the list should be short and each field should have a reason. Consent wording is the part that most often arrives late, because it sits with a legal or privacy team who were not on the kickoff call. Ask for it early and ask who signs it off.

What goes wrong without it: fields added one at a time after launch, and consent copy rewritten on a live form.

Brand assets and design files

We design around your client’s brand, so the guidelines are where the work starts, not a logo dropped onto a platform theme. Send the full guidelines, font files and licences, and any creative the client has already approved. If your studio has already drawn a key visual or a campaign look, send the source files so the site carries the same identity rather than an approximation of it.

What goes wrong without it: a design built from a compressed logo and a screenshot, then redone when the real assets arrive.

Content owner and approvals

Copy is the most common thing a build waits on. Name the person who writes it, the person who approves the design, and the person who signs off the live build. On our side, the design is approved before anything gets built, and nothing reaches your client that you have not seen. That only works if the approvers are known and available when the review lands.

What goes wrong without it: a build that is finished apart from the words, and a review round that waits a week for someone nobody had told.

Integrations

Registration data has to end up somewhere useful. If it is going to Salesforce, Marketo or HubSpot, the brief needs the fields that matter, the system they go to, and the name of whoever owns that system on the client side. The same goes for badges and check-in if they are in scope. Integrations fail quietly when they are retrofitted, so they belong in the original scope. Our Salesforce integration guide covers what that mapping looks like.

What goes wrong without it: leads stuck in the event platform, and a sales team asking where they went.

Languages

Every extra language multiplies the pages, the emails and the testing. Say which languages are needed and who supplies the translations, because translation is usually the last input to arrive and the one that holds up launch.

What goes wrong without it: an English build that has to be re-checked page by page when the translations land.

Accessibility

If your client has committed to an accessibility standard, the build needs to know before design starts, because contrast, type sizes and form structure are design decisions. Separately, list the accessibility and dietary questions the form must ask, so attendees can tell the organiser what they need.

What goes wrong without it: a design approved, then reworked, because the brand colours fail contrast on buttons and form labels.

Launch date and milestones

The registration open date is rarely the only fixed date. There is usually a client review, an internal sign-off, an invitation send date and a campaign launch around it. Put all of them in the brief. A typical event website and registration build runs four to six weeks from brief to live, depending on how much the client has settled. The milestones tell your partner where the slack is, and where there isn’t any.

What goes wrong without it: a launch date that is met, while the invitation email that should have gone out the same morning is still waiting.

Post-launch ownership

Someone will need to edit the site after launch, answer registrant queries and pull the numbers. Decide who that is before the build starts, because it changes what the handover needs to include. We build inside your client’s account, document what we built, and leave templates and notes so the next edit keeps the design intact. More on that in handover and training.

What goes wrong without it: the first post-launch change made in a hurry by someone who has never seen the build, and the brand drifting back to the platform’s defaults.

A brief does not need every answer. It needs every question, with a name next to the ones still open.

What happens after you send it

We start with a twenty-minute call, no deck. You tell us what the client sent you and what platform they are on, and we tell you honestly whether it is a fit. Then we agree a fixed scope and price before any work starts, so you know the number before you take it to your client. You work with one named person, the one doing the design and the build. The full sequence is on how it works, and once the build is moving, the pre-event launch checklist picks up from here.

The bottom line

The brief is where the scope gets decided. A complete one gets you a fixed price and a build that matches what your client approved. A thin one gets you assumptions. Have a brief, a logo or a deck from a client? Send it over and we will tell you what we would do with it.

Need this built properly for a client? Eventengin designs and builds event websites and registration, white-label, for agencies. Talk to us.