Service order template?

[gui_tarzan]

Do you guys with shops use a work order or service order of some type? I'm trying not to re-invent the wheel here. Do you have a written checklist to work from when an amp comes in the shop? I'm not a custom builder nor do I work on a ton of amps like some of you do (I have a day job) but I have been working on several lately and would like to get more organized. I use Open Office but an Excel or Word format would work as well. I just want to make sure I'm not forgetting anything, especially since I seem to be getting the weird, oddball fixes that other people give up on.

Just the other day I "fixed" a Marshall Haze that had a screw floating around on the circuit board and happened to be stuck under a power resistor when I discovered it. The original complaint was that it dropped volume after a short time and this could obviously do that if it touched the right components. The bias was also way off on one tube even though it has all original tubes. It as been operating perfectly since, I've put around 12-14 hours on it since going through it and it works and sounds great.

[km6xz]

If you are doing low volume it makes sense to write up work orders manually on a standard multi-part form such as this one from NEBS
Service Orders, Carbon, Claim Check, Large Format for Your Business

I used that one in 1992 for a couple years and it would out well until I went to a networked database system that added a lot of flexibility but was far more complex to update and modify. If you are doing only a few repairs a week, any office supply house had preprinted workorder or invoice books that are very cheap. If accumulating work, getting in more units before the last one leaves, it is a benefit to buy multi-part forms with separate pages for write up, invoice and hard tag, with a tear off tag with serialized work order number and customer name that can be attached to the customer unit. That is the form style on the link above.
The reason for not going to a computer based system at first is with low volume you gain nothing expect more work inputting data that you might never need. As volume increases, there is real use for collecting and storing the data in electronic searchable form. If you are not a good programmer, having a system written is expensive and there are few off-the-shelf solutions for electronic repair. I have written several systems, and it is not easy to perfect it and have it handle all the functions needed. The last one took 6 months of working on it everyday, and that was after years of refining others so I knew what I needed to accomplish.
We were doing a lot of warranty forms so I wanted the system to automate that tedious process and have the parts database fill in the correct OEM part number when using generics, the labor rate for that company and the invoice number if there was one of the original order for that part from the manufacturer, etc. That is when it pays for itself very quickly. Training new techs where they can look up the model and get records of every repair searched by symptoms or repair codes. None of that is needed for a hobbyist shop but was very worthwhile in a high volume shop with 75-100 repairs a day

[gui_tarzan]

That is true. I'm in IT and we have a ticket system but it is enterprise-class and I don't need anything like that. The system I manage has automated call forwarding that sends tickets to individual teams, etc., but it's way overkill for a small shop. There are several open-source programs that would work for invoicing, but the database (history, inventory, etc.) side is what I would love to have in order to track repair history and parts just for my own use.

One thing I started doing was creating parts lists for each model I work on. That's tedious and time-consuming but worth it to me. If I get something that's been butchered like my Sunn Sentura I can quickly reference the schematic and parts list to see what's been done or what's missing.

[km6xz]

The repair field needs an open source solution but I have not found one. I was thinking of releasing one of mine for community development but would need to clean up the modules a bit. Mine uses PHP/MySQL and Javascript so it is intended as a web application and mobile use as well as in-shop and front counter use. It was built for my needs so an open source project would been to widen its appeal and application.
The time and hassle of inputting data for every repair makes sense by the time a shop has several techs, and a counter person but smaller than that, the time consumed would have a very long payback period. With higher volume, it makes sense to record more detail about the customers, manufacturers, parts, models, suppliers, and individual repairs. Once the database as a meaningful core of data like a hundred or more manufacturers and 1000 or more models, and your repeat customer's data, suddenly it speeds things up with finer grained information, easier to get to and mostly automatic in use.
I added bar codes to the equipment tag so a tech just scans the tag and its service history and current work order are pulled up. Selecting a repair code, fills in a verbose version for the customer and the tech only types in additional information that might be helpful to the next tech working on it. Selecting generic parts, looks up the manufacturer's part number and lists that on the parts/material list. If starting a new repair the symptom code that was entered by the counter person(only after they verify the symptoms by having the customer reproduce the problem in front of her, this one step improved shop efficiency more than any other) and prints unit tags, one attached to the unit and the other slipped into a holder on its storage location. The counter person scans the location bin and that is recorded in the work order so no hunting for the unit. The tech picks the next one from the list of open repairs for his specialty, goes to the bin location and reviews the work order including a list of that serial number's repair history if there is one, and a list of the most frequent repair codes for that model's history and symptom codes. The tech enters very little data, only those electrical traits taken for every unit like mains current, power out, %Thd and a could basics. That was written before the cheap but good digital scopes so now a waveform capture should in recorded with the work order.
All this requires very little time and input from anyone once the db gets large enough to be of use. Since this one I am working on now is build on a an older database that had 5,000 models and 50,000 part numbers, and 60,000 repairs, and 25,000 customers, some of it is useless like manufacturer addresses and contact info since so many have gone out of business or been absorbed in the last 10 years, a lot of work remains putting the new data in. A lot of the old data does not help me now since I can't buy directly from the manufacturers now. But the part numbers referenced to generic number is very important as is the repair history and symptom/repair information searchable by symptom by model, by type and statistical data of frequency of defect. If a symptom has a 60% history of being one repeating cause, in a particular model, a tech sure would like to know that if they are working on it for the first time.
At the time that older system was used as the core of my shop, manufacturers accepted their parts orders primarily by fax so orders were handled automatically. When a part was needed it went into the list for that manufacturer and based on priority of the repairs, the accumulation period over which parts needs from that manufacturers would be advanced or retarded and the order faxed directly.

Anyway, the cool thing about a relational db is how much more useful and easier it is to grow it the larger it becomes. I input the manufacturers as they were needed so it added a bit to the repair time at first, entering basic manufacturer data, or part numbers for a repair, it did not take very long before that entry was needed less and less until days would do by and no tech entered data was needed. Every time a bit of data is recorded, it is done, does not have to be entered again, ever, unless it changes, like a manufacturer's contact name or a change in manufacturer's part numbering system. Much of the manufacturer part numbers was entered by scanning and OCR.
An ultimate goal was to generate spice models for common units so measured values could be entered by a tech and see the expected results to aid in diagnosis. That is pretty hard now that everything is run with ASICs. That would be more suited to an open source project of building models of popular units.

[gui_tarzan]

See, it's things like this that make me wish I had actually gone into the service end of this when I was much younger. What you're talking about in such detail is what I wish I could have been doing for the last thirty years instead of what I ended up doing. I thrive on solving problems and learning new things, and as I've gotten older I have much more patience. And since I have a relaxed schedule with these right now I can take the time to input the details. I believe doing these things now will do nothing but help me down the line when I (hopefully) won't have time to do them as often.

[nickb]

I've been using Quickbooks Premier Edition for some time now. It doesn't have the sophistication of the systems Stan has mentioned but does allow me to
(a) Have a customer database with all contact and transaction details
(b) Have a job database, organized per customer
(c) Keep inventory with buy price/sell prices, vendor and vendor p/n
(d) Track job progress with notes and enter time spent
(f) Track non-inventory parts ( i.e. parts bought for a specific job)

I'm not a big fan of Intuit's too-big-for-their-own boots-attitude but for reasonable cost I did get enough functionality to make my life easy. Not a perfect fit but pretty good for an off-the-shelf solution. I think you can get a trial edition.