Adoption Application and Contract Journey

Starting point

The rescue was running application forms that had never been designed for its own process.

One foster form had come from another rescue’s abandoned form export. It still carried that organization’s details, and breed-specific questions about animals this rescue does not take in.

Several controls were configured wrongly. Radio questions defaulted to their first option instead of asking the applicant to choose, and one of those was a criminal-history question that arrived pre-answered “Yes.”

The rest of the set had the same character: duplicated questions, inherited content nobody had reviewed, household information collected in a shape that did not match how households work, and no good way to capture repeated information such as references or existing pets. Conditional logic was inconsistent, so applicants were shown questions that did not apply to them.

Past the form, the process thinned out further. Applications landed in the form system and that was the end of the designed path. There was no review queue, no status, and nowhere to leave a note for the next volunteer.

Approved applicants then entered a contract process that was manual and entirely separate: assembling a document by hand, filling in the applicant and the dog, and sending it on.

So this was never a form-styling problem. The path from first question to signed contract had to be designed as one thing.

The decision

Design the whole journey rather than optimizing one screen.

The application, the volunteer review, the approval decision, and the contract are four stages of one process, and the handoffs between them were where the work was being lost. Each stage needed to hand the next a clear state, and the person applying needed to experience it as a single path rather than as four systems with gaps between them.

The journey

Applying

The major forms were rebuilt around the information the rescue actually needs. Applicants move through a multi-step form rather than one long page, see conditional questions only where they apply, and can add household members, references, and existing pets as repeating entries instead of compressing them into a single free-text box.

Nothing is pre-selected. Every answer is the applicant’s own, which matters most on the questions where a default would be both wrong and serious. Submissions arrive as a structured notification listing every field, so the volunteer reading one is not reconstructing the answers from an email.

Reviewing

Applications are a queue now rather than a pile of notifications. A volunteer can see what is new, what a colleague already has, assign a status, and leave internal notes that stay attached to the application.

Statuses run Pending Review, In Process, Approved, Denied, and Banned.

Contracting

Once an application is approved, a volunteer can issue a contract tied to that applicant and that dog.

The adopter receives a private link to a contract already filled in with the information the rescue holds. No personal information appears in the link itself. It is password protected, expires on a date the rescue sets, and stops working once the contract is completed. Issuing one does not require administrator access.

What changed

Applicants move through one path from first question to signed contract. They are no longer asked questions belonging to another organization, or handed answers they did not choose.

Volunteers can see where every application stands, record why, approve or decline it, and issue the right contract without building a document by hand.

The handoffs that used to happen in somebody’s inbox are states in a process instead, so the answer to “where is this application” no longer depends on which volunteer you ask.