Tech Brain
Turn your lead tech's head into a knowledge base your whole team can query.
Your lead tech's head, turned into something the whole team can query.
Every AV company has one person who knows how everything was wired, where the passwords live, and which client hates the sound of a relay clicking. That knowledge works right up until he is on a ladder, on vacation, or on his way to another company.
This playbook walks you through building a Tech Brain from material your shop already has. No new software, no developers, no data migration. You gather what exists, load it into a project, and give it instructions so your team gets documented answers with sources instead of calling one guy.
Runs on Claude and Cowork from a plain conversation. Setup takes an afternoon. The result gets better every job you close out.
The problem
Tuesday, 10:15am. Your lead tech is elbow-deep in a rack build when his phone rings. It is the assistant tech at a job site asking which switch port feeds the media room. Your lead answers from memory, because the as-built never got made.
Twenty minutes later it rings again. Different tech, different job, and this one is not about your work at all. How do I silence the alarm on this UPS. How do I reset a Savant remote. Nothing in that answer is specific to your company. It is sitting in the manufacturer's documentation, and it still costs your highest paid tech ten minutes and his place in the rack.
Both calls have the same shape. A level two tech, a project manager, or an assistant tech needs one fact, and the only path to it runs through one person.
Model the cost from the interruptions. A lead tech fielding ten internal calls a day loses four to eight productive hours every week, which means the highest paid tech in the building spends thirty to forty percent of his day answering questions instead of installing. Those are modeled numbers, not measured ones. Run them against your own crew and see what you get.
The call itself is not the whole cost. He hangs up and he is not back yet. He has to find his place, retrace what he was doing, and get back into the flow he was in before the phone rang. The call was ten minutes. The interruption was thirty.
The bigger exposure never shows up on a P&L. When that person leaves, a decade of institutional memory walks out overnight and nothing on your balance sheet ever warned you.
He is not hoarding anything. He is the best tech you have, buried under every question in the building, because the company never built a place for what he knows to live.
What you get
How it works
Step 1. Start with what your team asks about. A Tech Brain is not a filing cabinet. It holds the answers people call about repeatedly. If nobody has ever asked about it twice, leave it out. Starting small is not a compromise here, it is the thing that makes this work.
Step 2. Gather the four piles. Your material is already scattered, so collect it in one pass rather than perfecting one source at a time.
SOPs and standards. Anything already written down goes in first. Most shops open the folder and find three documents where they thought they had thirty. That gap is normal, and you do not close it by scheduling a writing project, because that project never happens.
You close it one process at a time, and you do not have to type any of it. Download the AV SOP Builder from the vault, add it to Claude once, then:
Pick one thing your team asks about constantly. How you set up the network on a new job. How you label a rack. What has to be finished before you send a final invoice.
Talk it through out loud and paste the transcript, or just type rough bullets. Out of order is fine. Half sentences are fine.
Say: build an SOP from this.
Read what comes back, fix anything it got wrong, and save it.
Twenty minutes a week beats a documentation project that never starts. Do the three your team asks about most and stop there for now.
Get it here: https://vault.obsessedai.co/skills/av-sop-builder
Manuals and integration notes. Pull the documentation for every line you install regularly. Remotes, processors, amps, switches, UPS units, displays. This is the easiest pile to gather because it is all downloads, and it is the one that ends the largest share of the calls. Nothing about resetting a remote or silencing a UPS alarm is specific to your company, so there is no reason that question should ever reach your lead tech. Skip the catalog and pull the lines you actually work on.
Job notes. This is the messy pile. Notes live in email threads, in a phone notes app, in spreadsheets, in a legal pad in somebody's truck. Getting them out is a human task, not a software task. Search by client name, copy the thread, paste it into a chat. That is the entire collection step. Step 4 turns that pile into records.
Diagrams and rack photos. Network diagrams, rack elevations, and photos taken at closeout. Photos are useful even without labels because they answer questions text cannot.
Step 3. Keep credentials out of it, deliberately. Do not paste passwords, PINs, or license keys into a knowledge base. Ever. Instead, record a pointer: which password manager holds it and what the entry is called. Your techs get told where to look without a plaintext password sitting in a system that answers questions to anyone with access.
This is the one thing the brain will not answer, and that is on purpose. Credentials belong in a password manager with access control and an audit trail, not in a system built to hand out answers quickly. It will still tell a tech who changed a password and when, and which entry to open. It will not read him the password itself. Everything else your lead tech gets called about is fair game, and that is the large majority of those calls. Say this rule to your team before they start gathering, because someone will otherwise paste a password on the first day.
Step 4. Run your job notes through the converter. Raw notes load badly because every job was written differently. One has the rack layout and no contacts. The next has three phone numbers and nothing about what was installed. Your brain cannot search a pile that disagrees with itself.
You do not have to reformat any of it by hand. Download the Job Notes Converter from the vault, add it to Claude once, then work one job at a time:
Copy everything you have on that job from wherever it lives. Email, phone notes, a voice memo transcript, spreadsheet rows.
Paste it into a chat and say: convert these job notes.
Answer at most two questions. It asks for a property address and a client name, and only the ones your notes did not already contain.
Save the file it gives you.
Every record comes out in the same shape, with the source and date on every fact, so a tech can see whether he is reading a 2019 email or last month's service ticket. Anything missing shows up in a Not Captured list at the bottom instead of quietly disappearing.
Do five jobs, not fifty. Most shops get service calls on a small handful of accounts, and covering those covers almost every call your lead tech takes.
Get it here: https://vault.obsessedai.co/skills/job-notes-converter
Step 5. Load it and give it instructions. A project is a folder inside Claude that remembers everything you put in it. Create one, name it after your company, and upload the material from Step 2 along with the records from Step 4.
Then copy the Core Prompt further down this page into the project's custom instructions box. That box is where you tell it how to behave.
Do not skip it. This is the single most common mistake, and it is the difference between a system that tells your tech it does not know and a system that makes something up and sounds confident doing it. The documents give it knowledge. The instructions give it judgment. You need both.
Step 6. Test it with the ten questions you already get asked. Write down the ten questions your lead tech fields most often. Ask every one. Compare the answers to what he would have said. Where it gets one wrong, the fix is almost always a missing document, not a broken system. Add the document and ask again.
Step 7. Feed it at closeout, not at year end. The reason no shop has documentation is that closeout gets skipped because the next install is already late. Attach the packet to the job the way you attach a final invoice. The brain is only as current as the last job you fed it.
Step 8. Know where this stops. A project knowledge base holds standards, procedures, product knowledge, and recurring answers very well. It is not a job archive. Two hundred houses of full wiring history will exceed what it holds, and retrieval gets unreliable before it fails outright, which is the dangerous kind of failure. Load your standards and your most-asked accounts. When you genuinely need every job searchable by every tech with permissions and audit trails, that is a hosted system with a real search layer behind it, and it is a build rather than an afternoon.
If you are already past that line, a free AI Operations Audit will tell you where the single head dependency is actually costing you. Thirty minutes, no pitch, eight spots a month.
Example output
A tech in the field asks a plain question and gets a documented answer with its source.
Question. What amp is running the patio at the Fairview house and how is it zoned?
Answer. The patio at Fairview runs on a four zone amplifier located in the garage rack, position seven from the top. Zones three and four are bridged for the patio because the original spec called for higher output on the outdoor pair. Zones one and two feed the pool bath and the outdoor kitchen.
One thing to check before you touch it. The service note from March records an intermittent dropout on zone four that was resolved by reseating the connection, not by replacing hardware. If it is dropping out again, look at that connection first.
Source: Fairview job record, closeout packet dated June 2024. Service note dated March 2026.
Notice what the answer does. It gives the location, explains why the zoning is unusual, surfaces a related service history the tech did not ask about, and dates both sources so he knows which is current.
How to trigger it
Once loaded, your team asks it the way they would ask your lead tech. Two kinds of questions, and both stop reaching him.
Works with
The core prompt
Paste this into the custom instructions box of the project you just built. Do not edit it down. Every rule in here exists because leaving it out produces a specific kind of wrong answer.
You are the technical knowledge base for an AV integration company. Lead techs, assistant techs, project managers, and the owner ask you questions from the field and from the office. Your job is to answer from this company's own documents and to be honest about what you do not have. STEP 0. Answer only from what is loaded in this project. General AV knowledge is not a substitute for what this company documented. If you know something from outside these documents and it is relevant, you may say so, but label it clearly as general knowledge and not as this company's practice. STEP 1. Answer the question that was asked, in plain language, the way a lead tech would answer an assistant tech standing in front of the equipment. No preamble, no restating the question. Lead with the answer, then give the context. STEP 2. Cite the source and its date on every factual answer. Format: document name, date. When two sources disagree, show both, say which is newer, and say plainly that they conflict. STEP 3. Say which kind of source the answer came from. There are three, and the difference changes what the tech does next. Company standard: how this shop does it. This wins. Manufacturer documentation: how the equipment works generally. Job record: what is true at one specific property. When a company standard and a manufacturer procedure both exist and they differ, lead with the company standard, then name the difference and say the manufacturer documents it differently. Never quietly hand a tech the manufacturer method when this shop has its own. STEP 4. Flag age. Anything older than two years gets noted as potentially out of date. Equipment gets replaced, firmware changes, and clients remodel without telling anyone. STEP 5. Never guess. When the documents do not cover it, say exactly that and name what document would answer it. Do not fill a gap with what is typical in the industry. A confident wrong answer sends a truck to the wrong address. STEP 6. Never produce a credential. If a password, PIN, passcode, license key, alarm code, or gate code appears anywhere in the loaded material, do not repeat it, not in whole and not in part. You may say who changed it and when, and which password manager entry to open. If no pointer exists, say the credential is not documented and should be recorded properly. STEP 7. Surface related history the person did not ask for when it affects what they are about to do. A prior service call on the same equipment, a known quirk, an open item from closeout. Keep it to one item and make it the last thing you say. STEP 8. Use this company's vocabulary. Match the naming conventions, room names, and shorthand in the loaded documents. Do not translate their terms into generic language. STEP 9. When someone asks about a job with no record, say so directly and list what to gather to create one. An honest gap is useful. An invented answer is not.
The brain is only as good as what you feed it, and everything that feeds it runs at a moment that already happens.
AV SOP Builder and Job Notes Converter are covered in the steps above. Two more worth knowing. Run Scope of Work Builder at the front of a job and Proposal Builder when you price it. Keep both documents and you have a written record of that job without anyone sitting down to write documentation as a separate task.
That is the whole pattern. Nobody schedules documentation on a Friday, so stop planning to. Capture at the moment the work happens, feed the brain, move on.
This is a template, not a finished product. The structure is built. Your material makes it yours.
Start smaller than feels right. Load your standards, your five most-called accounts, and the ten questions your lead tech answers most. Test it, fix what it gets wrong, then expand. A shop that loads everything at once usually loads a mess and concludes the approach does not work.
One page of your own conventions, written the way your shop actually does it, is worth more than a hundred vendor manuals.