Personas

A persona is one of the people ema expects to sign in. Not a customer segment and not a sketch of a typical user — a role the product recognises, with its own account, its own view of an event, and its own limits on what it can change.

There are eighteen. The list is short on purpose: it is the set of roles the product actually distinguishes, so if two jobs are on the list, ema treats them differently somewhere.

Why personas are real sign-ins

Every persona signs in the way you do: an email address, a code sent to that address, a session that belongs to that person. That has a consequence worth being explicit about — when a persona books a room, approves an invoice, or publishes a schedule, the record of that action carries their name and address. Not an administrator's.

This is also how our demo events are built. The exhibitor's booth in the demo is booked by the exhibitor. The finance approval was given by the person who holds the finance role, from their own account, after somebody else raised it. Nobody signs in as an administrator and produces the rest by hand.

That distinction is the whole point. An event operator can demonstrate anything if one all-powerful account does every step — the demo proves the screens exist, not that the permissions work. A reviewer who cannot see the author's name, a speaker who can upload a file but cannot move their own session, an approval that a second person has to give: those are only true if two different people are signed in. Personas are what keep that honest.

How to read a page's "Relates to" line

Pages that describe work owned by particular people carry a Relates to line at the very top, listing the personas that work belongs to. Read it as:

When this page describes somebody doing something, this is who is signed in.

It answers two questions quickly. If you are that person, the page is about your own job. If you are not, the page tells you whose job it is — useful when you need to know who to ask, or which of your colleagues needs an account before a step can happen at all.

Pages with no Relates to line are for everybody: sign-in, account settings, the glossary, general reference. Absence means "not role-specific", never "nobody owns this".

Each persona's own page carries the reverse of that line — every page in this site that named them, and every journey they take part in. Journeys are the end-to-end chains of work these personas run, and each of their steps names the persona who owns it; those pages need an operator sign-in to open.

The eighteen personas

They divide into two groups, and the division matters more than it looks. An internal persona works for the organisation running the event and can usually be given wide access. An external persona works for somebody else — a client, an exhibiting company, a hotel, or simply themselves as an attendee — and gets a narrow, self-service view by default.

Internal — 9

Works for the organisation running the events.

• Executive sponsorOwns the commercial relationship and carries the result. Wants to know the bid is worth winning, that the margin survives contact with delivery, and that nothing has been promised the team cannot honour — not the detail of how it gets done.
• Operator adminRuns the operator’s own instance. Decides which organisations exist, who is seated in each, and what a role is allowed to reach, so a new event can be stood up without anybody being handed access nobody chose to give them.
• Project leadAccountable for one event end to end. Lives inside the project — programme, schedule, suppliers, deadlines — and needs to see on any given morning what has slipped and who is waiting on them.
• Project team memberOn the operator’s own delivery team — staff or a contractor working the event without running it. Picks up the tasks and approvals assigned to them, logs the week against the project’s budget lines, and claims their leave and expenses, seeing their piece of the work and none of what they have no business seeing.
• Financial controllerKeeps the books across every event the operator runs. Cares that each order, bill and payment lands on the right budget line and reconciles, and that the margin reported at close is the margin that was actually earned.
• Commercial leadWins the work and sells what an event has to sell — the pipeline behind it, the pricing, the sponsorship and the stand inventory. Wants the quote out quickly, the contract signed, and the sold position to match what the floor plan can actually deliver.
• Marketing managerFills the room and keeps it informed. Runs the public site, plans the campaigns and owns the send calendar, and needs registration numbers and audience segments they can act on without asking anybody for an export.
• IT adminKeeps the tenant working: single sign-on, integrations, API access and the data moving between systems. Measured on nothing breaking, and on being able to say who did what when somebody asks.
• Accommodation coordinatorRuns the room block from the event side. Holds inventory across several hotels, watches the release dates, and needs to know which nights are genuinely selling before a contracted allocation lapses and has to be paid for anyway.

External — 9

Works for a client, exhibitor, supplier, hotel, or attends the event.

• Client contactThe client’s named owner of the event. Wants visibility without having to chase for it: where the budget stands, what has already been decided, and what is still waiting on them.
• Committee memberShapes the scientific content. Sets the call, agrees the review criteria, and has to defend the decisions the programme is built on — so wants a review that is defensible, not merely finished.
• ReviewerScores abstracts against criteria somebody else set. Wants an unambiguous queue, a clear statement of what is being asked, and a way to declare a conflict of interest rather than quietly avoid the submission.
• SpeakerHas agreed to present. Needs to know when and where they are on, what they owe and by when, and to be able to hand it over and get a confirmation without emailing anybody to ask.
• AttendeeComes to the event. Registers, pays, books what they need, and expects the badge, the schedule and the certificate afterwards to be right without opening a support ticket.
• Group coordinatorRegisters other people. Holds a block of places for their organisation, fills them as names firm up, and needs to swap a delegate late without losing the booking or the price it was held at.
• ExhibitorBought a stand and wants a return on it. Confirms the booth, orders services, registers stand staff and works to deadlines somebody else set — from a portal, rather than from an inbox.
• Supplier contactSupplies goods or services against a purchase order. Wants the order to be unambiguous, the delivery recorded when it lands, and the invoice paid on the terms that were agreed.
• Hotel contactThe hotel’s side of the room block. Confirms availability, applies the rates that were negotiated, and needs the rooming list early enough and accurate enough to actually honour it.

Where the list comes from

The eighteen are defined once, in the product itself, and this documentation reads that definition rather than keeping its own copy. Renaming a role or adding one changes these pages; there is no second list to update and no way for a page to describe a persona the product does not have.

If a page names a persona that does not exist, the site fails to build. That is deliberate: a wrong "Relates to" line sends a reader to the wrong colleague, and a reader will act on it.

Where to go next

• Pick your own role from the list above and read its page.
• New to ema entirely? Start with Getting Started with ema.
• Unfamiliar term? The Glossary covers the vocabulary these pages use.