# Build an event sign-in visitors can complete at the house

A builder event sign-in asks only for information the team will use, says what the visitor gets in return and keeps the house or event that started the conversation on the record. Keep the form short, mark optional context clearly, give visitors a working fallback and send every submission into a CRM you own with a tested follow-up owner.

## What is the sign-in supposed to do?

Define the job before you pick fields. A safety record, an attendance list, a content delivery form and a sales inquiry are four different tools. Merge them without explanation and you get a long form, murky consent and weak data.

At a public builder event the practical job is to connect a visitor with the house, the question and the agreed next step. The form can also record source context when the visitor chooses to share it. Ask your listing agent how representation is recorded at events; the listing agent sets that wording. It should not collect extra personal information because the form software offers more fields.

Use the [Lead attribution stage](/process/lead-attribution/) to connect the event path, the form and the CRM you own. Test that event and house fields stay attached when a submission updates an existing contact.

## Which fields belong on a builder event form?

Start with identity and a usable reply route. Add only the context the promised follow-up needs. If the team will never sort by a field or change its reply because of the answer, cut it.

### Match each field to an operating use

| Field | Why you may need it | Handling note |
| --- | --- | --- |
| Name | Identify the conversation | Keep the format simple |
| Email or phone | Deliver the promised reply | Ask for the route the team can support |
| Event or house | Preserve source context | Fill automatically when possible |
| Main question | Route useful follow-up | Use a short choice plus an open note |
| Lot status | Flag a site-review need | Optional unless essential |
| Represented by an agent | Lets the reply go through your listing agent | Optional; wording set by your listing agent |
| Permission choice | Document the requested communication | Keep separate from attendance where appropriate |

Do not ask a visitor to estimate a construction budget in front of a line of strangers. If project fit needs a deeper conversation, collect enough to arrange it and handle the sensitive details in private.

### Where should sign-in happen during the visit?

Placement depends on the event and the access policy. At an open model, a welcome and a quick orientation can come before the form. At an agent preview, your listing agent decides where sign-in sits. Either way, explain the purpose.

Do not hide the form behind a tiny code on a reflective sign. Give people a clear link, a staff-assisted device where appropriate and an accessible alternative. Test the path on common phone sizes and on the actual connection available at the house.

### Give visitors a plain reason to take part

Tell people what happens next: get the plan page, request a lot-review checklist, receive the installed selection summary, or ask a project question. Do not promise vague "updates" when the team plans a sales sequence.

The [spec home open-house guide](/articles/events-and-showings/open-house-for-spec-homes/) shows where sign-in sits in the full visitor route. The [Parade planning guide](/articles/events-and-showings/parade-of-homes-planning/) covers staffing and daily reconciliation.

## How should the form handle consent and privacy?

Use plain language, and have your responsible reviewer confirm the wording, the data use and any required notices for the channels you chose. Check current channel rules in the official documentation of your form, email and text providers. Check notice and permission wording with your professional adviser before you use the form.

Separate what you need to answer a request from what is optional for ongoing communication. Do not prefill an agreement the visitor cannot see. Show visitors a clear way to stop future messages.

### Keep private context out of public view

Staff should not write sensitive notes on a paper sheet that sits open at the entrance. Device screens should not show earlier submissions. If paper is the fallback, secure completed pages and enter them into the owned system through a documented process.

Review retention, access and export settings in the tools you own. You should be able to pull the records and remove vendor access without losing the history.

## What happens after someone submits?

The confirmation screen states that the record was received and repeats the expected next step. If the visitor asked for a plan or project page, give it to them right away when you can. Do not make someone wait for a generic email to reach information that is already public.

1. Attach the event, the house and any known campaign source to the record.

2. Send the visitor a confirmation that matches the request.

3. Notify the right owner based on the selected question.

4. Route technical matters for review and representation questions to your listing agent.

5. Record the promised next action and the person responsible for it.

6. Test the full path before every event, including the fallback process.

A success message is not proof that staff received the inquiry. Submit a real test record, open the CRM entry, check the source fields and confirm the notification. If a connection breaks, the event team needs a visible fallback.

## How do you improve the sign-in after an event?

Review completion problems and how useful the data was. Ask hosts where visitors hesitated, which questions needed explaining and whether staff kept side lists because the form lacked a field. Compare the submitted records with the replies you promised.

Do not add a field for every unusual conversation. Add or change a field when it supports a repeatable routing decision. Remove fields that stay blank, confuse visitors or never change the follow-up.

We run Claude and Codex agents that summarize approved form feedback, draft revised field labels, build the form page and check routing logic. A person decides what information is appropriate, reviews consent language and verifies every live submission path.

For post-event handling, follow the [Parade follow-up workflow](/articles/events-and-showings/parade-follow-up-plan/). For the wider system of CRM fields and ownership, see the [builder CRM guide](/guides/builder-crm/). The connected hosting and measurement workflows live in the [events and showings library](/articles/events-and-showings/).

## What do builders ask about event sign-in?

### Should sign-in be required at the door?

Choose a builder event sign-in approach that fits the event and the site-access plan. Check entry conditions with the organizer and review communication choices with your responsible adviser before opening.

### Is a QR code enough?

A QR code needs a tested direct link and an alternative sign-in route. Give visitors who cannot use the code staff assistance or a private paper form.

### Should the form ask if a buyer has an agent?

Ask your listing agent how representation is recorded at events. The listing agent sets the wording and answers representation questions. The form records what the visitor chooses to share, so the reply can go through the right agent.

### Who owns event sign-in data?

Keep event sign-in forms, CRM records, exports and access controls in accounts the builder owns. Give outside partners limited access and keep a usable copy of the history.