At Tuff Shed, the sale lived in Salesforce. The permit did not.
The customer record could tell us who bought the building, what they ordered, and which sales office owned the relationship. It could not tell us which government office actually controlled the property, whether zoning and building review were handled by the same desk, what the site plan had to show, or why a reviewer had returned the last version.
That information lived everywhere else.
The same handoffs still shape the local processes described in our residential permit guides. The difference is whether each project has to rediscover them from scratch.
Some of it was in Excel. Some was in a shared spreadsheet somebody had built for a specific district. Some was on a municipal website, except the form we needed was three clicks below a department page that had not been updated in years. The parcel answer lived in GIS. The latest correction lived in an email. The drawing markup lived on somebody's desktop. The explanation for a strange local requirement lived in the memory of the person who had called that village six months earlier.
Our permit operation absorbed up to two hundred permit lookups in a week. Only three to five complete submissions could make it out in a day. The gap between those numbers is the story: answering "does this need a permit?" and producing a file another human could actually review are completely different jobs.
The old permit workflow was a chain of systemsThe old permit workflow was a chain of systems
Calling it a workflow makes it sound more coordinated than it was. It was a sequence of handoffs, and every handoff gave the project another place to disappear.
1. The sale entered the CRM1. The sale entered the CRM
Salesforce was the commercial source of truth. Customer, address, product, price, sales representative, notes.
That was necessary information, but a sales record is not a permit record. The job still needed parcel context, the reviewing authority having jurisdiction, project classification, zoning district, forms, drawings, supporting documents, fees, submission channel, and inspection sequence.
The first operational move was copying information out of the CRM into the place the permit team actually worked.
2. The permit joined a spreadsheet queue2. The permit joined a spreadsheet queue
Excel and shared spreadsheets gave the team something Salesforce did not: one row per permit, with columns for status, municipality, missing items, last touch, and notes.
The spreadsheet worked until the work became more complicated than a row.
"Waiting on customer" could mean waiting on a survey, a signed authorization, a color selection that changed the elevation, or a decision about moving the building outside a setback. "Submitted" could mean uploaded to a portal, emailed to zoning, mailed to a township, or sitting in an online draft that had never passed payment.
The status looked visible. The actual blocker remained buried in notes, files, or someone's inbox.
3. Somebody figured out who issued the permit3. Somebody figured out who issued the permit
The mailing address was not enough. A customer could write a village name while the parcel sat outside village limits. A township could handle zoning while a county or contracted inspector handled building. Health could own septic. Public works could own the driveway.
This was the first high-consequence research step because choosing the wrong office contaminated everything after it: wrong form, wrong fee, wrong code assumptions, wrong submission channel.
On a familiar jurisdiction the answer took minutes. On an unfamiliar address it could take days of calls and callbacks before the routing was defensible.
4. The team assembled the local source set4. The team assembled the local source set
Every department organized its information differently.
- Application on the building page
- Accessory-structure handout on the zoning page
- Fee schedule in the annual budget PDF
- Setbacks inside the zoning ordinance
- Contractor-registration form under licensing
- Inspection request instructions in a portal help article
The work was not merely finding a PDF. It was deciding which document controlled, whether it was current, and whether the project described in it matched the structure we were selling.
The useful source list had to be rebuilt for every new jurisdiction because the knowledge rarely survived the project in a reusable form.
5. GIS answered the property questions the forms could not5. GIS answered the property questions the forms could not
Municipal and county GIS systems filled the gap between the street address and the ordinance. Parcel boundary. Incorporated status. Zoning district. Floodplain. Sometimes utilities, soils, or aerial history.
GIS was powerful and inconsistent. Every viewer used different layers, labels, search behavior, and export tools. A tax parcel line was not automatically survey-grade. A zoning layer could be stale. An aerial image could show a building without proving that it was permitted.
The map supplied clues. Somebody still had to understand what those clues changed in the permit path.
6. Missing history became a records request6. Missing history became a records request
When the current website and customer documents could not answer the question, the next stop was the department's records archive.
Sometimes a staff member could email an old permit or scan while we were on the phone. Sometimes the project required a formal public-record or FOIA request and a wait for the response. Old approved plans, septic records, property history, and prior permit files could determine whether the new work was routine or whether it exposed an older unresolved condition.
The request then became another inbox thread to monitor, with its own reference number and response window.
7. Forms and drawings were built into a packet7. Forms and drawings were built into a packet
Downloading the application was the easy part. The customer and project data still had to be entered, signatures collected, contractor information verified, and every supporting document matched to the same scope.
The site plan often started with a plat of survey, then added the proposed structure, setbacks, dimensions, easements, driveway, and other property constraints. Elevations and other construction drawings had to agree with the application and site-plan footprint.
When those drawings were prepared or marked up by hand, every dimension became a coordination point. A garage shown as 24 by 26 on one sheet and 24 by 24 on another was enough to stop intake before the reviewer reached the structure.
8. Submission moved the project into another system8. Submission moved the project into another system
There was no standard filing lane.
One department wanted paper copies. Another accepted email. Another used Accela, OpenGov, Cloudpermit, or its own portal. Some required the owner to create the account. Some required the contractor. Some separated the zoning permit from building review. Some would not open the building file until health or engineering signed off.
The spreadsheet gained another status. The actual project moved into a system the spreadsheet could not observe automatically.
9. Email became the status dashboard9. Email became the status dashboard
Approval notices, invoices, intake rejections, reviewer questions, records responses, and inspection instructions arrived in email.
Monitoring meant searching by address, permit number, customer name, and municipality because different offices used different subjects. A message forwarded to one teammate but not another could leave the spreadsheet saying "under review" after the reviewer had already asked for a correction.
The system depended on the right person reading the right thread and translating it back into the tracker.
10. Corrections restarted the coordination work10. Corrections restarted the coordination work
Plan review comments rarely changed only one document.
If zoning corrected the garage location, the site plan changed, the application dimensions might change, the elevations might change, the price or product configuration might change, and the customer had to approve the new placement. If the reviewer requested engineering, the drawing set and schedule changed.
A proper resubmittal required a point-by-point response and one coordinated revision set. A rushed response that changed only the marked page created another correction cycle.
That is how a permit that looked almost finished could consume another week of internal work before it went back into the municipal queue.
The bottleneck was not any one toolThe bottleneck was not any one tool
Salesforce did its job. Excel did its job. GIS did its job. Email did its job. The municipal portal did exactly what it was designed to do.
The bottleneck lived between them.
Each system held one piece of the truth, and a permit technician had to act as the integration layer:
| Operational question | Where the answer usually lived |
|---|---|
| Who is the customer and what did they buy? | CRM |
| Which projects are in the queue? | Spreadsheet |
| Who controls the address? | Boundary, parcel, and department research |
| What rules apply? | Ordinance, handout, forms, staff confirmation |
| Where can it sit? | Survey, GIS, zoning, site plan |
| What will be built? | Product details and construction drawings |
| What is missing? | Checklist, notes, inbox, reviewer comments |
| What did we submit? | Portal, email, paper file |
| What happens next? | The person who last touched the project |
The permit department's most experienced person became the human API between every column in that table. When that person was out, overloaded, or left the company, throughput fell because the process knowledge went with them.
What the Permitech workflow changesWhat the Permitech workflow changes
Permitech does not try to turn Salesforce into a zoning database or replace the municipal portal. It gives the permit work its own operating layer.
The address and project become the shared starting pointThe address and project become the shared starting point
Instead of copying a sale into a blank row and then deciding what research to perform, the project begins with structured address, property, scope, and applicant information.
The first job is still the homeowner's plain-language question: does this project need a permit? Behind that answer, the workflow resolves the responsible authority and the approval lanes that may apply.
Requirements stay attached to their sourcesRequirements stay attached to their sources
The useful output is not a paragraph saying "check with your municipality." It is a set of project requirements tied to the official page, form, ordinance, fee schedule, or department guidance that supports each answer.
When a permit technician verifies the research, the next project can reuse the jurisdiction knowledge instead of repeating the original scavenger hunt.
Documents become obligations, not attachmentsDocuments become obligations, not attachments
A file upload by itself does not explain why the file exists, who owns it, whether it is current, or which reviewer comment it answers.
The permit workspace connects the application, survey, site plan, drawings, contractor records, supporting approvals, and missing items to the project. The PDF permit package gives a self-filing customer an organized record. Site-plan support and managed filing are separate paths when the project needs more than the self-service package.
Status becomes an action, owner, and sourceStatus becomes an action, owner, and source
"Under review" is not an operational status unless the team also knows:
- Which office has the file
- When it entered the queue
- What the office calls the record
- Who owns the follow-up
- What event changes the next step
The same standard applies to corrections. Every comment needs an owner, an answer, an affected document, and a resubmission record.
Local knowledge becomes reusableLocal knowledge becomes reusable
This is the compounding part.
The first project in a municipality may still require calls, GIS research, forms, code review, and human verification. The second project should not start from a blank browser. The resolved authority, source catalog, filing path, requirements, and known failure points become an asset the operation can use again.
Old workflow versus permit operating layerOld workflow versus permit operating layer
| Work | Old contractor workflow | Permitech workflow |
|---|---|---|
| Customer and job | Salesforce record | CRM remains the commercial record; structured permit project begins from the same facts |
| Permit queue | Spreadsheet row and notes | Project workspace with owner, next action, documents, and status |
| Authority | Staff search and calls | Address-based authority resolution with human verification when needed |
| Requirements | Municipal tabs, PDFs, notes | Requirements organized with official-source evidence |
| Property context | Separate GIS session | Parcel and GIS signals connected to the permit research |
| Documents | Shared drive, inbox, desktop | Required-document list tied to the project and review stage |
| Site plan | Hand markup or separate drafting step | Required early, coordinated with property basis and local acceptance |
| Submission | Portal, email, mail, or counter | Same official channel, with the path and record tracked in the project |
| Corrections | Email thread and manual spreadsheet update | Comment, owner, affected document, revision, and resubmittal tracked together |
| Approval | Inbox notice | Issuance moves the project into inspection and closeout work |
The point is not that every municipal process becomes automatic. The point is that the contractor's side becomes legible.
The tools that still belongThe tools that still belong
Salesforce or another CRM still owns the relationship. Leads, opportunities, proposals, contracts, sales activity, and account history belong there.
Design software still owns design. A manufacturer, designer, architect, engineer, or trade professional remains responsible for the drawings their scope requires.
Municipal portals still own official submission. The authority decides what it accepts and where the legal record lives.
Email still carries communication. The difference is that a reviewer message should create a project action instead of remaining the only copy of the decision.
People still own judgment and accountability. A human verifies unclear sources, calls the department, makes design decisions, signs applications, responds to reviewers, and takes responsibility for the work.
Permitech sits between those systems. It is the permit intelligence and compliance layer that keeps the address, authority, requirements, evidence, documents, filing work, and project status from separating.
The five-question test for a contractor permit operationThe five-question test for a contractor permit operation
Open any active permit and ask:
- Can somebody who did not work on it yesterday name the exact next action?
- Can they show which office owns that action and why?
- Can they find the current application, site plan, drawings, and reviewer comments without searching an inbox?
- Can they explain what changed between the original submission and the current version?
- Will the next project in the same municipality reuse what this project taught the company?
If the answer to any of those is no, the operation still depends on a person carrying context between systems.
That was the old job. Permitech was built so it does not have to remain the new one.
