A behind-the-scenes look at the humble website submission form.
Website submissions forms have been around for a long, long time. From the simple “Contact Us” form used to send a short message, to the fancier forms used for registering for events or submitting multi-page applications, forms are a great way to allow web visitors to provide you with information. Forms are comprised of different types of input fields (text, numbers, dates, etc.) and a button to submit the data; they may include required fields or special fields like a file-picker to allow for uploading attachments.
The basic technology for creating and displaying a front-end form is uncomplicated; however, what makes today’s forms so powerful is what happens on the backend, in your CRM or AMS database where the information sent via the form is stored. Depending on your platform, you’ll have different options for crafting forms that connect to fields in your database.
But before throwing a form together and plopping it onto a page on your website you need to consider two things:
(a) what information do you want to capture?
(b) how do you plan to use the information once you have it in your system?
What information do you want to capture?
Think about the different ways visitors engage with your organization using your website. Examples might include:
- Subscribing to your newsletter
- Making an online donation
- Signing up or renewing a membership
- Registering for an event
- Applying for a class or workshop
- Registering to volunteer
Each of these activities requires a different set of data from the visitor. For a newsletter sign-up form all you really need is an email address, though you may opt to capture a name, too. Contact data is the simplest type of data to store because it comprises the foundation of your AMS or CRM system, so a captured email address is likely stored right in your main database.
Beyond that, things can get trickier. With an online donation form, you may want to capture more than the donor’s contact details; you will also want to record the amount of the donation and the date it was made. If you’re a membership organization, you may offer multiple levels of membership, for example, student, lifetime, etc., and will need to track a sign-up date so you’ll know whether their membership has lapsed.
Where is all that different data stored? Knowing where your form needs to send the submitted data is your first step.
Outlining the fields you want to appear on your form will give you an opportunity to see how and where your AMS/CRM stores data. Determine whether your system already has the fields you need; if not, you may need to create new fields to capture whatever custom data is relevant to your use case.
How do you plan to use the data you’ve collected?
Depending upon your use case, your form may collect more than just contact data. You may have data around visitors’ donations, event attendance, membership status — plus any custom data that’s been defined in your AMS. Once you have this data, you can report on and analyze it in many ways, but it’s helpful to start thinking about what you’ll want to use it for even before designing your form.
- Will it inform your programming and planning?
- Will you segment contacts based on their responses?
- How might you want to follow-up and engage with contacts?
Having a clear picture of the end goal will go a long way to getting all the pieces in place so that your website form collects the correct data and stores it in its proper place in your database.