How to Prepare an AV Company for AI
A practical checklist — which projects, documents, and processes to gather first, how to pick the workflows worth automating, and how to run a low-risk first project before you build anything big.
Most AV owners approach AI backwards. They start by asking what the technology can do, get a vague and oversized answer, and either commit to something too big or decide it is not for them yet. The better starting point is the opposite: forget the technology for a moment and ask which repetitive work in your company costs you the most. That question has a concrete answer, and it tells you exactly where to begin.
Preparing for AI is not a strategy exercise. It is a small amount of practical groundwork — gathering the right material, picking the right first workflow, and running one narrow project you can actually measure. Here is what that looks like.
Gather your material first
An assistant is only as useful as what it has read. Before anything gets built, collect the material that describes how your company does its work well. This is the single most important preparation step, and most of it already exists — it is just scattered.
- A handful of your best completed projects — programs, drawings, equipment lists, and documentation that represent how you want work done.
- Your standards — naming conventions, structures, wiring practices, and preferred products, even if they only live in a few people's heads today.
- Resolved service tickets, especially the ones with a real fix written in the notes.
- The internal documentation and device notes your team actually relies on.
- The questions your senior people answer over and over — those point straight at what an assistant should know.
It will be uneven, and that is fine. You are not building a perfect archive; you are gathering enough of your real work that an assistant can learn how your company operates rather than staying generic.
Pick the right first workflow
The temptation is to automate the biggest headache in the company. Resist it. The right first workflow is not the most important one — it is the one most likely to succeed and prove the idea. Look for three qualities:
- It repeats often, so the time saved adds up quickly and you can judge the result across many instances.
- It has a correct-enough starting point, so an assistant can draft it and a person can verify it fast — programming scaffolding and service lookups both fit this well.
- It is low-risk if the first draft is imperfect, because a human reviews everything before it matters.
Notice what is missing from that list: the work that carries real judgment. Do not point a first project at system design, final estimates, or anything a client sees directly. Those depend on the expertise you are trying to free up, not the repetition you are trying to remove. Choosing a low-judgment, high-frequency task is not settling for something small — it is aiming at the exact work where an assistant can help without putting anything important at risk.
The goal of your first project is not to solve your biggest problem. It is to prove — with a small, measurable win — that this actually helps your team.
Run one narrow project and measure it
Once you have the material and the workflow, build an assistant around that single task and nothing else. Keep the scope deliberately narrow. Then measure two things honestly: does it save time, and do the people using it trust its output? Both matter. A tool that saves time but produces work your programmers do not trust will sit unused, and a tool your team likes but that saves nothing is a toy.
Give it to the people who will actually use it and listen to what they say. A senior programmer who tries a scaffolding assistant and keeps it open on the next job is a stronger signal than any demo. If it works, you expand from what works. If it does not, you have learned that cheaply, on one workflow, instead of after a large commitment.
Set the expectation with your team
How you introduce this matters as much as what you build. Your best people will reasonably wonder whether the goal is to replace them. It is not, and the framing should be clear from the start: the assistant takes the repetitive, low-judgment work — the setup, the lookups, the first-draft documentation — so they spend more of their time on design, engineering, and clients. A programmer who has that reassurance will help you make the tool good. One who suspects otherwise will quietly work around it.
Why grounding is the whole point
The reason the material-gathering step comes first is that it is what separates a useful assistant from a novelty. A generic model already knows AV in the abstract, and that generic knowledge is not worth much to you because your competitors have the same access to it. What is yours is your projects, your standards, and your history. Generic AI knows AV. An assistant grounded in your own material learns how your company does AV — and that is the version worth building.
So preparation comes down to a short list: gather the material that shows how you work well, pick one repetitive workflow you can measure, run it small before you build anything big, and be clear with your team about what it is for. Do that and your first project will be low-risk and honest about its results. It is the same principle you will apply to everything after it: automate the repetition, protect the craft.
- You do not need an AI strategy to start — you need one repetitive workflow and the material that describes how you do it well.
- Gather your best projects, standards, and resolved tickets first; that material is what makes an assistant specific to you.
- Pick a workflow that is repetitive, high-volume, and easy to verify for the first project.
- Run one narrow, low-risk project and measure it before committing to anything larger.
