Very often, there is a trigger for our work. A customer makes an order. Or a co-worker needs us to do some work. Very seldom do we just wake up in the morning and decide to do something. We are often requested by someone else to do work. Organizing the intake of these requests can massively improve our work processes.

As in the Bakery Example in What is a Process?, a customer could make an order through the bakery's website, by calling on the phone, or by coming into the bakery. In any case, the order should be written down by filling in an intake form. The customer should be presented with a menu of possible choices and each choice may have further inputs needed, like the size, flavors, when the cake is needed by.

My own department did not use intake forms. Instead, we relied on email. Someone would email me: "I need help." "What type of help do you need?" "I need a contract." "Okay.... What type of contract do you need?" A back and forth conversation would ensue stretching out for up to weeks. One of us would chase the other asking "Where are we with this?" And in the end, any sign that work got done was stuck in emails. There was no permanent record of work.

An Intake Form solves these issues. It shows your requesters up front what all the options are and what you require from them. If they need to go get something from another department first, they know up front they will have to do this. They can't later just depend on you to go do the work for them. It also organizes the request as an online record that anyone can see. Want to know the progress of the request? Go look at the request and see the latest comments and its status. The record of the work is no longer stuck in emails.

Lots of work in a company requires intake forms to gather the required inputs. Instead of building thousands of systems, we can build only one and then allow for customization.

I would use different types of widgets based on the types of inputs you need to get from your requesters.

Checkboxes. Checkboxes allow your requester to check off certain properties that are listed for them. They can select multiple. You can also allow your requester to add custom properties. You can require a minimum number or set a maximum number that can be checked.

Date. When picking a date, you should show your requester a calendar date picker in the language that their browser is set to. So if my browser is set to American English, then 5/1/2022 means 1 May 2022. The same date when shown in British English would show as 1/5/2022 for them. In the back end database of course we will show dates as Year-Month-Date from largest to smallest, but when displaying them to people using your intake form tool, always show dates in their preferred way. The intake form should allow us to put restraints on what date the user can pick. We may want to have a minimum date or a maximum date. We may want to say that the date they pick must be at least two weeks from today. Or at a minimum the first day of the next month. Whatever kind of date you want to get from your user, your system should be able to keep to those requirements. A user should never be given a blank box and allowed to type anything for a date. You will invariably get garbage. And then we are right back to the email conversation going back and forth endlessly.

Dropdown. A dropdown is nice when you only want your user to select one option. And they are not allowed to create their own custom option. Make sure not to give too many options, because nobody wants to read through hundreds of options.

Email address. You should never ask your requester to type in somebody's name because names are not unique. There may be multiple John Smith's in your company, but only one john.smith@company.com. So ask for email addresses instead. If you need the email address of a current employee at your company, then your form should be connected to your company's address book. As a user starts typing, you should give them a drop down menu of the email addresses that match so far. Then allow the requester to select one of the email addresses. In this way, you for sure know that they gave you the email address of a current person at your company.

If instead, you want them to be able to give you even the email address of a past employee, then only make sure that the email address domain matches what you are expecting.

If instead, you are looking for your requester to give you the email address of anyone outside your company with any email address, then at least check that the email matches [something]@[something].[something]. You can't check ahead of time that the email address actually exists, but you can at least check that it is a valid email address.

Files. Often we need a requester to upload and submit files to us. So allow them to do this easily. You might want to only allow them to submit certain file types like PDF or DOCX. You might want to require a minimum number of files or set a maximum.

Multiple Choice. This is one of the most complex parts of the intake form. Because we don't want to overwhelm the requester with a screen of hundreds of options to choose from, instead we give them a blank box where they can start typing. We check what they have typed against a long list in the background and present them with a dropdown list of matches. The classic list is a list of countries. Because there are easily 200 countries, it's best for that list to be maintained in the background in an external list. That list can be maintained by the intake form owner manually just for this form, or it can be maintained in an external list like in a .TXT file, a spreadsheet or a SharePoint list. Maintaining an external file makes it easy so that when there is a change to the list of countries to be made for all your hundreds of intake forms, you can edit the external file once and have the multiple choice options updated across all your forms using that list.

You can also give your requesters the option to create their own custom country name if they want to. Just allow them to type whatever they want and press Enter even if they didn't match with anything on your list.

Number. This is a classic thing that people mess up on. You ask for a number and they type into a text field "I don't know". Well gee, would two weeks of conversation help you to know? You can give a minimum and maximum. When you're asking for an amount of money, you can even set it to allow for two decimal places. We can place a prefix like "$" or a postfix like "%". Get the exact data you need from your requester.

Paragraph. Your form might need some explanation before or in the middle. A paragraph gives the requester something to read without having to give any input back.

Radio buttons. Radio buttons are another way for your requester to select a single option. Like a dropdown, but they can see all the options without clicking anything. Plus radio buttons can have an "Other" option. You can then require your requester to specify what "Other" means in a further text box.

Select buttons. Select buttons are a beautiful set of two or three buttons and the user selects one.

Spreadsheet. Sometimes you need rows and columns of data like a spreadsheet. You can set the columns of data you need. Then let your user add and edit rows of data. You can also allow them to upload an external spreadsheet that fills in the rows and columns. You can set a minimum of number of rows you require before they can submit the form. This absolutely makes it so your requester can't just give you a fuzzy jpeg with unreadable number. This way you get the exact data you need and you minimize the manual work you'll need to do to process their request further.

Text area. Sometimes we can't help but give the requester a text box they can freely type into. You can set the minimum and maximum number of characters you'll allow.

Title. A title is a nice way to let the requester know that a new broad section is beginning. It breaks up the form logically and doesn't require them to give any inputs.

These are all the types of data we need from a requester normally. Because all requests have these same types of widgets, we can make a universal intake form generator that will be flexible enough to take in all kinds of requests. No need to go create hundreds of intake form systems. We can instead make only one.

Each of the above widgets (besides paragraph and title) I would give some common properties. Each should have space where you can write a sentence or two of instructions before it. Then I would have optional help text that appears when the user clicks a question mark after the instructions. The help text would pop up when they click on the question mark.

I would also allow a question to be mandatory or non-mandatory. So if a question is mandatory and the user has not fulfilled the requirements, the user would not be able to submit the form. I would make a solid background behind the first next question that the user still has to fullfill and I would give them specific instructions for what they need to do to fullfill the requirements.

I would also allow any of these widgets to be invisible by default. And that's because we want to allow for logical branching. Like maybe we only want a question to appear if they answered the question before in a certain way. I would also only let a question be mandatory if it is visible. After all, a user can't be expected to fullfill a question's requirements if they can't even see it.

Now that we have some widgets that are invisible and can be made visible, I would have a textbox where the form admin can do some very basic JavaScript to make the form smarter. I would give them a simple example of such JavaScript such as: If the value of X box is "yes", then make Y visible. Otherwise, make Y invisible.

Such JavaScript looks like this:

if($("#x").val()=="yes"){
    $("#y").show()
}else{
    $("#y").hide()
}

In this very simple way, we have just created the working for an intake form system that can take in any requirements.

I would allow for one of three different submission paths:

1. All the data is saved as a new record with a unique ID number and the team owning the form receives an email notification that they have a form to review.
2. I would connect this intake form with a document template library. Perhaps all the inputs were needed to fill in a template. I would automatically fill in the template and email it to the reviewing team for them to review.
3. I would allow for flexibly connecting with any other system. It might be that we have an outside vendor that has a system where we manage our team's work matters. The intake form is just a nice way for us to get all that data, but then it pipes all that data to the other system that takes in the data and creates a matter.

If we go down the first submission path, I would have the system create a unique ID number and save all the data, including the state of the form (all text and help text) when it was submitted. The requester also gets an email telling them the URL where they can see their request.

When reviewing we see the entire form that was submitted, read only. We can click on any files that were uploaded and see them read only.

Below the form I would have a section of email addresses of people who are subscribed to receive notifications when the request is updated. So anybody who wants to be informed as things progress, they can manage their notification preferences themselves. Want your boss to be aware when the status changes? Give them the URL and they can come subscribe. Tired of receiving emails about this request? Come here and unsubscribe yourself. In this way, there is a permanent record of the request that is not stuck in emails. I would also give each person a checkbox that they can be notified only when there is a "status change", not merely a comment.

The next section is where anyone can add a new comment to the request or change its status. When doing either of these, anyone can upload a file to attach. Submitting a comment or a status change emails everyone subscribed appropriately. If nobody on the reviewing team has explicitly "subscribed" I would email the entire team, until a specific team member has subscribed. Then only they would receive notification emails.

Below this I would put a log of everything that has happened with the request. Who submitted it and when. And then every comment and status change along with any files that were attached at the time.

In this way, we have a very simple yet robust way to manage all types of requests. We have a way to get the exact data that we need. And then once submitted we have a record of all work being done and it is clear to everyone where everything stands and we have a permanent record of it that is not stuck in email boxes. No more emails from requesters once a week asking "Where are we with this?" They can simply go look for themselves.

Wanna see this in action and learn how I built this using tools already available to us in Microsoft Office 365? See below.