LecturePanda Help

Appearance

Running a Live Event or Conference ​

A multi-session conference is the most involved thing you can build in LecturePanda, and almost all of it comes down to one course carrying several credits. This guide covers the shape of that setup, how attendees claim afterwards, and the two configuration mistakes that account for most conference support tickets.

One course, many credits ​

For a conference, build a single course and add one credit per session.

Attendees register once, then choose the sessions they actually attended. Each credit carries its own session times, its own claim code, its own quiz or evaluation, and its own certificate template — so a nursing session and a pharmacy session on the same day can report to different places and hand out different certificates.

Give every credit its Session Start and End Times and LecturePanda assembles the agenda from them automatically.

One course per instance for repeating classes

The opposite advice applies to a class you run repeatedly — twice a month at the same venue, say. Build a separate course for each instance and duplicate it to save time. Reminders fire off the course date, so bundled dates send at the wrong time; the announcement shows a confusing range once one date has passed; and because a learner can't register twice for the same course, attending one date would lock them out of the others.

Session times: back-to-back is fine, overlapping is not ​

Session times are inclusive at the start, exclusive at the end. A 10:00–11:00 session and an 11:00–12:00 session don't overlap, so enter them exactly like that — there's no need to end the first at 10:59.

Credits whose times genuinely overlap can't both be claimed. That's deliberate: nobody attends two concurrent sessions. But it's also the single most common cause of a conference behaving strangely, and it rarely gets reported as a scheduling problem. It shows up as:

  • "The course won't let attendees submit more than one UAN."
  • "Only one credit shows up for attendees — the second one is locked."
  • "It worked for our other seminars, so we had to build a separate course per UAN this time."

Multiple credits on one course is the supported pattern, so if you find yourself splitting a conference into one course per session, check the session times on the credits first. Even a few minutes of accidental overlap locks the second credit. It takes about a minute to spot.

If a credit is still unclaimable after you've ruled out overlaps, check whether it's restricted to a registration type the learner didn't register under, or whether something is listed in its Locked When Any Of These Credits Are Selected field — that setting creates a manual conflict on top of the automatic time-based one.

Verifying attendance ​

Live attendance can't be tracked the way video progress can, so claim codes stand in for it. Set Credit Security on each credit — see Credits for the field itself:

  • Single Code — one code for the session, which the speaker or moderator reads out. The usual choice.
  • Double Code — two codes, one released at the start of the session and one at the end. Attendees enter both. This is the digital equivalent of a sign-in/sign-out sheet, and it's what to use when your accreditor requires proof of full attendance.
  • Multiple Codes — a unique code per attendee, for when codes are handed out individually.

Scanning people in at the door

Separately from claim codes, the Check-in Process on the course's Details tab puts a barcode in each attendee's emails, which staff scan on the Check-In Page as people arrive. Set it to Check-in Required and nobody can claim credit without being scanned in — useful when the venue door is your verification point rather than the session room.

What attendees do afterwards ​

Once the event is over, an attendee's path is:

  1. Register — usually before the event. This consumes one participant from your bank.
  2. Open the confirmation email and click the link, which signs them in with no password.
  3. Select the sessions they attended from the credit list.
  4. Enter the claim code for each session.
  5. Complete the quizzes and evaluations attached to those credits, plus any overall event survey.
  6. Download a certificate for each session successfully claimed.

Steps 3–5 loop over every session, so an attendee typically claims several credits from one registration.

Completion is locked until the event date

Attendees can register and start early, but the final submit step stays locked until the course date arrives — by design, since nobody has attended yet.

This surprises admins rehearsing before launch: the flow appears broken at the last step. It isn't. Note that the test registration still consumed a participant, even though the claim couldn't be finished.

The claim gate is worth designing for. An overall event survey should be set to Everyone, but every session evaluation must be attached to its credit — a session quiz left on Everyone forces the whole audience to complete it and blocks their submission. See Quizzes & Evaluations, which is the most common conference misconfiguration after overlapping times.

Capacity ​

Restrict Seat Count on Registration Security caps registrations, and you can raise, lower or remove the cap at any time. Two ways that helps:

  • Hold the room back. Register your speakers and VIPs while the count is low, then raise it when public registration opens.
  • Expand mid-sale if you move to a bigger venue.

There's no automatic waitlist today. If you sell out and someone cancels, raise the seat count manually to let the next person in.

Time zones ​

Enter session times in the time zone where the event is being held. Learners see them converted to their own local time automatically, so a 2:00 PM Central session reads as 3:00 PM to someone in Eastern time.

You don't need to list multiple time zones on the course — though it's still worth naming the primary one in marketing material that lives outside LecturePanda.

Offering the recordings afterwards ​

When you want to sell the recordings on demand after a live event, duplicate the course and run the on-demand version separately. Don't add recordings to the live course.

The live course is built around assumptions that don't fit on-demand learners:

  • Claim codes were released in the room. There's no sensible way to give recording-watchers a code on the same credit.
  • Video tracking is normally off for live events, so there's no completion gate for someone watching a recording — and switching it on afterwards disrupts people who already claimed.
  • Reminders and event messaging would go to on-demand learners as if they were attending live.
  • Your reporting gets muddled, with two cohorts under one registration list and one set of completion stats.

On the duplicate, drop the code requirement from the credits and turn on the video tracking requirement instead — watching the recording becomes the verification step.

The trade-off is real: an attendee who wants both live credit and the recordings is two registrations, so two participants from your bank. It's usually still the cheaper option once you count the support time that a hybrid course generates.