A few fields and a Submit button look like a small website feature. Yet the form might simply send an email, or it might start a case that several people handle over many days.
Before comparing prices, describe both ends: what the user does and what happens to their submission inside your organisation.
Follow the complete scenario
Take a consultation request. Someone selects a topic, enters their details, attaches a document and submits it. Who receives the request? Does someone allocate an appointment? Can the user correct information or check progress?
Add the less convenient situations: missing information, an unsupported file, an interrupted connection and a second click on Submit. Agree the expected behaviour rather than leaving those decisions until development.
Separate the elements that affect scope
- Fields and validation rules, including dependencies between answers.
- Attachments: types, limits and how staff access them later.
- Draft saving and returning to an unfinished submission.
- Confirmations and messages to users and staff.
- Sending information to an administration area or another system.
For each item, decide whether the first release needs it. A simple contact form does not necessarily need the workflow of a complex application service. Conversely, removing a required step may just move the work onto staff.
Include what happens after submission
A working form does not solve the problem if nobody responds. Assign a process owner, cover for absences and a way to notice stalled requests. Agree the data collected with the responsible people in your organisation.
For pricing, send an example successful submission and several failure cases. Include the expected result for staff. This gives suppliers a clearer basis for their estimates and provides concrete scenarios to check during acceptance.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database