Skip to main content
PermitAssure — Permits Made Simple
EN FR
Request a Demo
Applicant Experience & Communication Practical Guide

Designing a Better Permit-Submission Experience

Most failed submissions are a service-design failure before they are an applicant failure.

Editorial owner
PermitAssure Editorial Team
Published
3 Aug 2026
Last reviewed
3 Aug 2026
Reading time
9 minutes
Audience
Government & AHJs, Developers & Builders
Three construction professionals in hard hats reviewing documents together on site.
Applicants range from national developers to homeowners; one interface serves both. Photo: licensed stock imagery (iStock); licence confirmation pending.

Executive summary

A permit service is used by professionals who file weekly and by residents who will file once. Designing for only one of them produces either an opaque form or a system that professional users fight.

This article walks the applicant journey, identifies the points where submissions fail, and sets out design choices that reduce failure without transferring risk into technical review.

Why experience is an operational concern

Every avoidable deficiency consumes departmental capacity twice and delays the applicant. Submission experience is therefore not a customer-service nicety; it is the cheapest available capacity intervention.

Accessibility is a requirement rather than an enhancement. WCAG 2.2 provides the standard, and its quick-reference material maps success criteria to practical techniques [1][2].

The applicant journey and its failure points

Permit applicant journey and where submissions failFive stages: understand requirements, prepare package, submit, respond to deficiencies, receive permit. Failure points: unclear or scattered requirements; requirements discovered late; upload and validation friction; notices that cannot be answered in one pass; unclear status and next steps.Applicant journey with failure pointsUnderstandFind requirements for thisprojectPrepareDrawings, forms, studies,declarationsSubmitUpload, validate, payRespondAddress deficienciesReceivePermit and conditionsFailure point at each stage: unclear requirements, late discovery, upload friction, unanswerable notices, unclear status
Original PermitAssure diagram. Text description: the applicant journey runs from understanding requirements through preparing a package, submitting, responding to deficiencies and receiving the permit. Each stage has a characteristic failure point: unclear or scattered requirements; requirements discovered too late; upload and validation friction; notices that cannot be answered in one pass; and unclear status or next steps.
Table 1 — Design choices by journey stage.
StageDesign choiceEffect
UnderstandOne requirement list per permit type, with examplesFewer omissions and fewer pre-application calls
PrepareDownloadable checklist matching the intake gate exactlyApplicant can self-check before filing
SubmitImmediate validation with specific, plain-language messagesFailures corrected in minutes, not weeks
RespondNotices stating requirement, evidence, location and actionComplete responses in one pass
ReceiveConditions and next steps in plain languageFewer post-issuance questions and inspection surprises

Implications for authorities having jurisdiction

Design for the once-in-a-lifetime applicant and provide efficiency features for the frequent filer: saved profiles, bulk upload, consistent naming conventions. The two needs are compatible if the defaults favour clarity.

Test with real applicants, including someone using assistive technology and someone filing a first residential permit. Both will find defects that internal review will not.

Implications for applicants and professionals

Professional applicants can standardise internally against the municipal checklist, which converts a recurring cost into a one-time setup. Where several municipalities are involved, the differences between their checklists are worth documenting once.

Risks, limitations and safeguards

  • Front-loading requirements can exclude less-resourced applicants; provide guidance and a human contact route.
  • Validation messages that reference internal codes rather than plain language increase support load.
  • Accessibility conformance must be tested, not asserted; automated checks are necessary but not sufficient.
  • A slick interface over an undocumented process hides variation rather than removing it.
  • Never let interface convenience imply an approval outcome; status language must stay neutral.

PermitAssure perspective

PermitAssure derives the applicant-facing checklist from the same configuration that drives the intake gate, so the two cannot diverge. Validation messages state the requirement and the location, and the platform is built to the WCAG 2.2 Level AA criteria where technically feasible.

Five key takeaways

  • Avoidable deficiencies are a capacity problem, so submission experience is operational.
  • The applicant checklist and the intake gate must be the same artefact.
  • Design defaults for the infrequent applicant; add efficiency features for frequent filers.
  • Test with assistive technology and with a first-time residential applicant.
  • Status and validation language must never imply an approval outcome.

References

  1. Web Content Accessibility Guidelines (WCAG) 2.2. W3C. www.w3.org. Accessed 3 August 2026.
  2. How to Meet WCAG 2.2 (Quick Reference). W3C. www.w3.org. Accessed 3 August 2026.
  3. Housing Accelerator Fund Best Practices. Canada Mortgage and Housing Corporation. www.cmhc-schl.gc.ca. Accessed 3 August 2026.
  4. Illustrated User’s Guide: NBC 2020 Part 9, Division B — Housing and Small Buildings. National Research Council Canada. nrc.canada.ca. Accessed 3 August 2026.

Cited statements follow the sources above. Frameworks, diagrams and interpretation in this article are PermitAssure's own.

Related resources

Applicant Experience & CommunicationWriting Clear, Evidence-Based Deficiency NoticesApplicant Experience & CommunicationTransparent Permit Status Without Oversimplifying the Review

Next step

Publish one requirement list per permit type and make the intake gate use exactly that list.

See applicant-facing workflows

PermitAssure provides digital review, workflow and decision-support capabilities. This resource is educational and does not constitute regulatory, legal, architectural or engineering advice. Final interpretations, approvals and regulatory decisions remain the responsibility of the applicable Authority Having Jurisdiction and its authorized professionals.