The paper form still exists because it works. Somebody designed it years ago, everybody knows where the boxes are, and the process around it has been sanded smooth by repetition. Then it gets replaced with an electronic version, and for about three weeks everything is worse. Submissions arrive faster than before but nobody knows who is handling them. The attachment that used to be stapled to the front is now an email somewhere else. The person who used to write a note in the margin has nowhere to write it.
The replacement usually fails not because the form was built badly but because only the form was replaced. A paper form is the visible part of a process that also includes a tray it sits in, a person who picks it up, a pencil mark that means it has been looked at, and a filing cabinet. An electronic form that copies only the questions leaves all of that to be reinvented by whoever is on duty.
This is how to do the substitution properly, in the order that causes the least disruption.
Map the process before you touch the questions
Before opening any tool, write down what physically happens to one sheet of paper from the moment it is completed to the moment nobody needs it again. Not what is supposed to happen. What happens.
A typical answer looks like this. It arrives at the front desk or by post. Somebody puts it in a tray. Once a day somebody takes the tray, checks each sheet is complete, and writes a date in the corner. Incomplete ones get a phone call. Complete ones go to whoever handles that category, who writes a decision on the sheet and passes it back. Somebody sends a reply. The sheet goes in a folder by month, and three times a year somebody digs one out because the person who submitted it has asked a question.
Every step in that description is a requirement. The tray is a queue. The date in the corner is a status. The person it gets passed to is an owner. The folder by month is a search index. The pencil note is an internal field that the respondent must never see. If the electronic version has no equivalent for a step, that step will be done in a mailbox or a spreadsheet instead, by hand, forever.
Write the list down and keep it next to you while you build. It is the specification, and it is more useful than any feature comparison.
Sort the fields into three piles
Now look at the form itself. Paper forms accumulate fields the way drawers accumulate cables, and copying all of them across is the most common mistake.
Fields that exist because the form is paper. Date received, initials of the person who checked it, a reference number written in by hand, boxes for an office use only section, a tick to say the identity document was seen. None of these are questions for the respondent. They are the process leaking into the artwork, and in an electronic form they become internal fields or happen automatically.
Fields that exist because paper cannot branch. If you answered yes to question 4, complete section C, otherwise skip to section D. On paper the whole form has to be printed for everybody, so every possible path is visible at once, which is why the sheet is intimidating. Electronically, section C appears only for the people it applies to, and the form gets shorter for everybody.
Fields that are genuinely questions. Name, address, what is being applied for, dates, the attachment. These carry over.
The second pile is where most of the improvement comes from, and it is worth being aggressive. A four page paper form frequently contains about one page of questions that apply to any individual respondent. Dropping the rest is not a simplification of the process, it is the removal of an artefact of printing.
Do this on paper too, with a pen, before building anything. Marking up a photocopy in three colours takes twenty minutes and saves rebuilding the form twice.
Make the validation do the phone calls
The single largest saving is not typing time. It is the follow up.
Count how many of last month's paper submissions needed somebody to go back and ask for something. Missing signature, illegible phone number, date in an ambiguous format, section left blank because the instruction was on the previous page. Each one is a phone call or an email, a wait, and a second handling of the same sheet. In most paper processes this affects somewhere between a fifth and a half of submissions, and every one of them is preventable electronically.
So when building, treat each of those recurring failures as a field specification rather than an instruction. A date that must be in the future is a date field with a constraint, not a note saying please use DD/MM/YYYY. A phone number that must be reachable is a phone field. A section that only applies to one category of respondent is conditional, so it cannot be skipped by accident or filled in by mistake. A required attachment is a file question that blocks submission, not a line saying please attach a copy.
The test for whether the electronic version is actually better is not whether it looks nicer. It is whether the incomplete submission rate goes to near zero in the first month. If it does not, the validation was written as advice instead of as a rule.
Give every response an owner and a status on day one
This is the part that gets left until later and should be decided first, because it determines which tool is suitable.
A paper submission has an owner the moment somebody picks it up off the tray, and a status the moment somebody writes a date on it. Both facts are visible to anybody who walks past the tray. When the form goes electronic, both facts disappear unless the tool models them, and the usual replacement is a spreadsheet with two extra columns that somebody maintains by hand while cross referencing a mailbox.
That arrangement works at twenty submissions a month and produces the two familiar failures at two hundred: the applicant who gets two different answers from two colleagues, and the applicant who gets none because each assumed the other had it.
What to insist on, therefore, before choosing anything:
- Each response is a record with an assignable owner, not a row in an export.
- Each response has a stage that reflects your actual process, not a generic read or unread flag.
- More than one person can be signed in at once without paying per additional plan tier. Several well known form tools set the included user count at one on every individual plan, so check the seat terms and not only the monthly price.
- Internal notes and internal fields exist, and are invisible to the respondent. This is the pencil mark in the margin, and a process that had one will not function without it.
- The history of what happened to a response is kept in one place, including replies sent.
The features list is the right place to check those five against a specific tool, and the use cases page is useful for seeing how the stages differ between an application process and an enquiry, because copying the wrong stage template is a slow mistake to undo.
Decide what still has to be a document
Some paper survives the transition, and pretending otherwise causes a workaround to appear within a fortnight.
A signature that has to be witnessed, a document a third party requires in their own layout, a certificate that gets handed over, a record that must be readable in ten years without access to any system. Those stay as documents. The efficient arrangement is to collect the answers electronically, where they can be validated and tracked, and generate or handle the document afterwards, for the subset of cases that need one. Collecting in a browser and producing a document at the end is a very different thing from emailing a file out and hoping it comes back complete.
Decide where the notification lands, too. On paper the tray was the notification, and it was visible to the whole room. The electronic default is an email to one address, which recreates the single point of failure that the tray never had: if that person is away, the queue is invisible. Sending new arrivals to a shared channel in whatever chat tool the team already uses, or to a shared mailbox that more than one person watches, restores the property the tray had. The notification is not the record, though. It is a prompt to go and look at the list, and a process that works from the notifications rather than from the list will lose submissions the first time somebody archives one.
Also decide what happens to the existing paper archive. In most cases the answer is nothing: leave it where it is, note the date the changeover happened, and do not spend three weeks scanning history that gets consulted twice a year. If the old records do need to be searchable alongside the new ones, most form tools accept a CSV import, which is a far cheaper path than re-entry.
Run both for one cycle, then stop the paper
Do not switch off the paper route on the day the electronic form goes live. Run them together for one full cycle of whatever the process is, whether that is a week, a month or one intake round.
During that cycle, watch three things. How many people still choose paper, and why, because the reason is usually a specific field that is hard to answer on a phone. How many electronic submissions come back incomplete, which tells you whether the validation is doing its job. How long a response sits before somebody takes ownership of it, which tells you whether the queue is visible enough to the people who are supposed to be working from it.
Then remove the paper route deliberately and completely. A process with two intake channels has no single list, which cancels most of the benefit, and the half migrated state is worse than either end. The most common cause of a stalled changeover is a paper form left available for exceptions, which quietly becomes the default again because it is familiar.
The cheapest way to sanity check all of this is to submit two or three responses to the new form yourself and then try to work them, which is what the demo is for. Building the form is the easy half. Handling a response is the half you will do every day.
What to change first
Take last month's paper submissions and count two numbers: how many needed a follow up because something was missing, and how many times somebody had to ask a colleague whether a submission had been dealt with. Those two numbers are the whole business case, and the second one is the one that decides whether you need a form builder or a form tool that gives each response an owner and a status, which is what Halict is for.
Q1. How long does it take to replace a paper form electronically?
Building the form is usually an afternoon. The work that takes longer is deciding the stages, who owns a submission at each stage, and which fields are internal, because those decisions are currently held in people's heads rather than written down. Budget a day for the mapping and an afternoon for the build, and expect one revision after the first week of real submissions.
Q2. Should every field on the paper form be carried across?
No. Paper forms contain fields that exist only because paper cannot branch, such as sections that apply to one category of respondent, and fields that belong to the office rather than the respondent, such as date received and checked by. The first group becomes conditional logic, the second becomes internal fields, and both make the form shorter for the person filling it in.
Q3. What about people who cannot or will not use an electronic form?
Keep one assisted route rather than a parallel paper route. Somebody at a desk completing the electronic form on the respondent's behalf keeps every submission in the same list, which is the point. Leaving the paper form available as an exception tends to restore it as the default, because it is the familiar option.
Q4. Do respondents have to create an account to submit an electronic form?
That depends on the tool, and it materially affects completion rates for public intake. Some features force a sign in, notably file uploads on certain platforms, so check the form from a signed out browser on a phone before publishing it. For internal forms a sign in costs nothing, but for anything public it removes respondents.
Q5. How should the old paper records be handled?
Usually by leaving them alone and recording the changeover date, since historic files are typically consulted a handful of times a year and scanning them is expensive. Where the old records genuinely need to sit alongside the new ones, a CSV import into the form tool is far cheaper than re-entry, and most tools match imported columns to existing questions.