Innovation Brief

Blake Sutton – Lead Developer

University of Advancing Technology

April 2014 – Current



Computer Shopware is a solution to the many multi-purpose computer repair shops need for tracking and managing computers and clients. The current process for tracking and managing computers requires multiple systems and entering customer information manually into each of these systems. This project aims to eliminate the need for multiple entry as well as provide an intuitive user interface for this data entry as a majority of the software that is used is not intuitive and has a steep learning curve. This project’s second goal is to be extensible in a way that allows multiple platforms to interact with it as well as allowing plugins to be created in order to further customize it to specific needs. This extensibility will allow Computer Shopware to be useful in many workflow style scenarios rather than being limited to strict repair shops. A solid underlying database system and layout are imperative to this system being successful and stable.


Database Driven, MVC, Plugin, API, Framework, Extensibility, CRM, Multi-Platform, Enterprise Software, Multi-User, Networked, Computer Repair, Repair Shop, User Friendly, Intuitive


Background Information and Prior Art

There are currently a few other repair tracking applications available on the market. The main issue is that all of them stick to a particular area or problem and are a single use type of software. When working in a computer shop it is a hassle to have to enter customer information into multiple systems. Some systems are great at actually tracking the repair process but tend to fall short at managing clients or the payment and invoicing side.

PC Repair Tracker or PCRT (“PC Repair Tracker”) is one of the more useful applications that I have reviewed while looking for a software that does the required task. It handles computers as assets and does a great job tracking these assets through the process. This application falls short in several areas though. It does not allow bulk items in the checkout is one of the major setbacks. If you sell 50’ of cable the receipt and invoice show 50 line items for 1’ of cable each rather than grouping them together. PCRT also does not handle customers efficiently. If a customer brings in two computers you have to fill out the customer portion twice, once for each computer. This double entry of data is inefficient especially in a world where many families have multiple computer systems. PCRT is extensible in the way that it is non-obfuscated php and you are allowed to edit the source. The problem with this is that you have the potential to mess the entire system up while trying to simply change a few words.

Repair Shopr (“Computer Repair Shop”) is also a really great tool in most aspects. It handles customers excellently and allows a basic pc repair tracking but it is not the most effective repair tracking tool as it is mainly used to generate invoices. Another large downside to this software is recurring cost. A multiple user system could end up costing ~$1200 each year. Recurring costs are acceptable in some situations but a large upfront cost is usually more economical in the long run. Repair shopper was not designed with computer repair in mind. It is a modification of their general repair shop software. This program is also not extensible. They do update it but there is no way to add custom plugins.

All of the software that I have found and used in an active running shop have similar downsides or issues. The most notable or most prevalent are some of the largest issues. Many of these types of software have recurring monthly fees. This ends up costing repair shops an exemplary amount of money and especially with startup shops this is not acceptable. A fee for upgrades or new features is a good alternative but this is few and far between. Most of the software that is available is a web based only application. This is a great advantage in most cases as it will run on many platforms but there is not good mobile support through add-on applications or mobile websites. Very few PC techs do not have and carry a smartphone so an application or mobile tech interface would help efficiency greatly.

Customers are just as important, if not more so, than the computers themselves. A program that runs a repair shop should treat them that way. Being able to manage and track customers is just as important as tracking the computers and repair process. If a customer has 5 completely different jobs with a repair shop it should be easy to add 5 jobs under a single customer without having to enter the data multiple times. This slows down the part of the work while a customer is sitting there trying to get a quote or a computer checked in and could cost you the job.

These systems reviewed are not intuitive and they are not sleek. A system that could be seen by a customer or that needs to be picked up quickly by technicians should be intuitive and self explanatory. If it takes 5 or more minutes to find information then this is a good indication there is a flaw in the system or something could be improved upon. These interfaces should be simple with quick access the the information needed.

The last area where there is great room for improvement is with extensibility. None of the systems that I have tested or used allow plugins. With an ever changing tech world the ability to extend functionality would be a great asset. Rather than looking for another system to handle a certain feature that you need it would be great to have the ability to just extend what already exists. This would allow the data that you have to be extended and used to its fullest potential.



Free Universal Repair Tracking System – Simple To Use – Free!. (n.d.). RepairTraq. Retrieved April 13, 2014, from

Home – Computer Repair Shop Software &€“ CRM & Invoice System. (n.d.). Computer Repair Shop Software &“ CRM & Invoice System. Retrieved April 13, 2014, from

PC Repair Tracker – PHP/MySQL Computer Repair Shop Tracking Software. (n.d.). PC Repair Tracker. Retrieved April 13, 2014, from

Repair Shop Software. (n.d.). Repair Shop Software. Retrieved April 13, 2014, from

The Complete Client Management, Recurring Billing & Support Solution. (n.d.). The Complete Client Management, Recurring Billing & Support Solution. Retrieved April 13, 2014, from

osTicket :: Support Ticket System | osTicket. (n.d.). osTicket :: Support Ticket System | osTicket. Retrieved April 11, 2014, from | OTRS Simple Service Management. (n.d.). otrscom. Retrieved April 13, 2014, from


Project Description and Innovation Claim

Computer Shopware is designed to be a one stop system that solves the problem many computer repair shops and other companies have with finding a unified system to manage the customers and all other aspects of their business. This project aims to solve that problem by providing a solid shell, with a great interface, that allows this software to grow and to be customized without the worry of ruining the internal workings or the main framework. This software should support basic billing, crm, repair tracking or workflow management and invoicing out of the box. Possible plugins or features included could be asset and inventory labeling and credit card processing depending on development time. This project will deviate from other similar software by allowing complete control through plugins and extensions. The ability to customize this software to an individuals or businesses needs has not been explored to its full potential and could greatly improve usability as well as efficiency.


Usage Scenario

Computer Shopware will be used by small to large computer repair shops as well as other businesses that are constantly innovating and expanding the types work they perform. By storing all of the information about the clientele, or other relevant data, in an extensible framework the computer shop simply needs to add a plugin that extends the program for their next big project. A great example of this would be as follows. Joe’s Repair Shop, who currently uses Computer Shopware, decides they want to start offering web hosting. Now Joe’s client walks into the office to pick up their computer and sees that he is now offering web hosting. Joe pulls up the clients account in the system. Joe asks what domain name the customer would like and, with the help of the domain plugin Joe created earlier, the system registers the domain and adds it to the customers service page in his online account. This is faster then the system Joe used before where he loaded his domain managing software and entered his clients information into the new system and then added the domain which generated an invoice that was not similar to his repair invoices and also generated a second account manager for that software’s online management for the customer.


Evaluation Criteria

There will be several criteria that will need to be evaluated for effectiveness of the software. User Interface, Extensibility, Framework.

Test 1 – User Interface

  • Intuitive and Easily Learned
  • Sleek/Pretty appeal to users
  • Good Layout
  • Modifiable

This test will be conducted on a group of possible users, people with no experience in this field, and secretary type workers. A rating of 1-5 will be given for the interface in each of the aforementioned categories. In addition a section for additional comment will be added if the rating is low to identify why they rated it as such.

Test 2 – Extensibility

  • Plugin’s are simple to write
  • Good documentation to follow
  • Easily learned system
  • All necessary api hooks present

This test could be proposed after the aforementioned test. This would allow others to try and fix any issues that arose from the first test through extension or plugins. A group of developers would be given the documentation and an example plugin and asked to create a simple plugin for the system. They could then rate the API and Extensibility with the criteria listed above. A possible contest or award for best plugin could be a great way to get some developers on board.

Test 1 – Framework

  • Stability
  • Full Featured
  • Intuitive
  • Expandable/Future Proof

This test would be done during the evaluation of the other criteria. We would need have users actively using the program to know if there was a major framework flaw. If the system holds true throughout the process then we know there is stability. If there are issues with the plugin test that show that there are missing API hooks or information then we know this is not fully featured. The future proof would be tested by added thousands of data points to the database through scripting and test if the software can handle the loads. This could be tested by adding all plugins to the software and seeing how well it ran. The future proof is a test of time more than anything. If fixing and adding features that were found to be missing or broken is simple then this is an expandable and future proof application.


Project Logic Model

Goal – To develop a one-stop, extendable platform to handle all aspects of managing a computer repair shop

Objective 1 – Establish a strong backend/database model for the framework to run on.

Activity 1a – Establish an extendable model within database constraints.

Activity 1b – Develop a solid set of tables for the built in features.

Activity 1c – UML design for database tables

Activity 1e – Write SQL Table Create Code

Objective 2 – Establish a front-end model or software pattern that is efficient and extensible for future proofing.

Activity 2a – Develop shell classes for all of the included features within the constraints of the design pattern.

Activity 2b – Finalize shell classes and test their interface with each other.

Activity 2c – Add or extend classes with public methods for API and extensibility.

Activity 2d – Verify shell’s interface with backend interface

Objective 3 – Develop a user friendly interface that is both intuitive and has room to grow in the future.

Activity 3a – Sketch some rough layout options and get a peer review of them.

Activity 3b – Implement Main Screen

Activity 3c – Implement List Item Screens (Customers, Clients, invoices etc)

Activity 3d – Add extendability to UI for plugins to be able to extend.

Activity 3e – Test the implemented UI with potential users of software.

Objective 4 – Build documentation for all aspects of the software and make it user readable and publicly available.

Activity 4a  – Pull documentation from all of the public classes and functions.

Activity 4b  – Add information about implementing plugins to integrate more features.

Activity 4c  – Build documentation into a website for easy access.