Notion Database & Systems Specialist — Existing Repair Shop CRM Cleanup

Notion Database & Systems Specialist Needed One-Time Cleanup, Connection & Optimization Project I own a growing powersports repair business, Griff’s Powersports Repair, and I have already built a Notion system that we use to manage customers, machines and repair jobs. The system is functional, but as I’ve built it and learned Notion, I’ve added properties, relations, formulas and automations that have made parts of it more complicated than they need to be. I’m looking for an experienced Notion database/systems specialist to come in, audit what I already have, clean it up and properly connect everything so it functions as one efficient repair-shop management system. I am NOT looking for someone to replace everything with a generic template or move all of my existing information into a completely different system. My goal is to make what I already have work correctly and efficiently. What I Currently Have I currently have four primary databases: * Customer Service Tracker * Customers * Bikes/Machines * Service Jobs These databases already contain properties, information, relations, formulas, views and some automations. Some things are working correctly. Others are redundant or are not connecting information the way I intended. I want someone who can look at the entire system and determine the cleanest structure rather than continuing to add more properties as workarounds. The Basic Structure I Want Ultimately, the system should work like this: CUSTOMER ↓ can own multiple ↓ BIKES / MACHINES ↓ each machine can have multiple ↓ SERVICE JOBS For example: Customer: John Smith John owns: 2019 Polaris Ranger 900 * Service Job #001 — Belt replacement * Service Job #014 — Wheel bearing * Service Job #037 — Engine repair 2022 Can-Am Outlander 850 * Service Job #022 — Oil change * Service Job #041 — Top-end repair When I open John Smith, I want to see his machines and overall service history. When I open the 2019 Polaris Ranger, I want to see only the service history for that particular machine. When I open an individual Service Job, I want to immediately see which customer and machine it belongs to. If John brings that Polaris back six months later, I should create another Service Job — not another customer or another Polaris record. The system needs to preserve the lifetime service history of each machine. My Existing Customer Service Tracker This is especially important. I already have a Customer Service Tracker that I use and like, and I want it connected to the other databases. I do NOT want all of the information moved somewhere else just for the sake of rebuilding the system. I need someone to determine the best way to connect my existing tracker with: Customers + Bikes/Machines + Service Jobs while eliminating unnecessary duplicate entry. Information We Need to Track Our system needs to support information such as: * Customer name * Phone/contact information * Machine * Year/make/model * VIN * Drop-off date * Reason the machine came in * Diagnostic information * Customer approval * Repair needed * Repair performed * Parts needed * Parts ordered * Parts status * Parts payment status * Work status * Completion date * Pickup date * Service agreement * Notes * Previous service history I don’t necessarily need every piece of information displayed everywhere. Part of this project is helping me determine where each piece of information actually belongs. Repair Workflow Our repair workflow generally follows something similar to: Checked In → Diagnosing → Waiting for Approval → Waiting on Parts → Ready for Repair → In Progress → Ready for Pickup → Picked Up/Closed I want to be able to quickly determine: * What’s currently in the shop * What’s being diagnosed * What’s waiting for customer approval * What’s waiting on parts * What’s ready to be worked on * What’s currently being repaired * What’s ready for pickup * How long each machine has been in the shop * What’s been completed * Previous repair history Database Cleanup One of the biggest goals of this project is SIMPLICITY. I believe I currently have properties that are duplicate, unnecessary or could be handled more efficiently through relations, rollups, formulas or views. I want you to: * Audit all existing properties * Identify redundant/duplicate properties * Recommend what should stay * Recommend what should be removed * Correct database relations * Correct reciprocal relations * Create only useful rollups * Review/correct formulas * Review/correct automations * Clean up database views * Reduce duplicate data entry * Make the system easy enough for another employee or VA to use later Please do not delete properties, databases or existing records without my approval. Automations I have already been working on automations such as: New Repair Job * Status becomes Checked In * Drop-Off Date is recorded Status → In Progress * Work Started Date is recorded Status → Ready for Pickup * Completion Date is recorded Status → Picked Up/Closed * Pickup Date is recorded * Job is closed I also have/want a Days in Shop calculation: If the machine is still here: Today – Drop-Off Date If it has been picked up: Pickup Date – Drop-Off Date I want the existing automations and formulas audited before replacing them. If there is a better way to accomplish something, I am absolutely open to recommendations. Views I Would Like I want clean, useful operational views such as: * Current Jobs * Checked In * Diagnosing * Waiting for Approval * Waiting on Parts * Ready for Repair * In Progress * Ready for Pickup * Completed/Closed * Over 14 Days in Shop * Customer Service History * Machine Service History I’m open to changing these if you recommend a cleaner setup. Real-World Testing I don’t want the project considered finished just because the relations technically work. I want it tested against real repair-shop scenarios. Scenario 1 — Returning Customer + Returning Machine Customer already exists. Machine already exists. They bring the machine back for another repair. A new Service Job should be created and connected to the existing customer and existing machine without duplicating either. Scenario 2 — Returning Customer + New Machine Customer already exists but brings us a different ATV/UTV. A new machine should be added under that customer with its own separate service history. Scenario 3 — New Customer + New Machine New customer, new machine and new Service Job are created and properly related. Scenario 4 — Customer With Multiple Machines One customer owns several machines. Each machine maintains its own service history while all machines remain connected to that customer. Future Growth I don’t necessarily need all of these features built during this project, but I want the architecture designed so we can eventually add things like: * QR codes attached to machines while they’re in the shop * Scan a QR code to immediately open the correct machine/job * Parts inventory * Oil-change/service reminders * Automated customer follow-ups * Review requests * Additional technicians/employees * VA access and workflows * Dashboards/reporting * Parts/eBay inventory integration I don’t want today’s database structure to prevent us from expanding the system later. Protecting Existing Information These databases contain real business information. Before major structural changes are made, I expect: 1. Existing databases to be backed up/duplicated. 2. The current system to be audited. 3. Problems and redundancies to be identified. 4. Your recommended structure to be explained to me. 5. Major changes to be approved before implementation. 6. Changes to be implemented and tested. 7. Existing information to remain intact. Final Deliverables At the end of the project, I expect: * Customers properly connected to their machines * Machines properly connected to their Service Jobs * Existing Customer Service Tracker properly integrated * Existing information preserved * Duplicate/unnecessary properties cleaned up after approval * Relations and reciprocal relations working correctly * Useful rollups configured * Formulas reviewed/corrected * Automations reviewed/corrected * Clean operational views * Returning customer workflow tested * Returning machine workflow tested * Multiple-machine workflow tested * A system simple enough for me, employees and a future VA to maintain I would also like a short screen-recorded walkthrough or simple written SOP showing me how to: * Add a new customer * Add a new machine * Create a Service Job * Handle a returning customer * Handle a returning machine * Update an active repair * Close a completed repair * Find previous service history Project Structure I would prefer this to be quoted as a fixed-price project rather than an open-ended hourly project. Please include any limitations or work that would require additional charges in your proposal. When Applying Please send: 1. Your experience building relational database systems in Notion. 2. Examples of CRM, service-business, repair-shop or operational systems you’ve built. 3. Your experience with Notion relations, reciprocal relations, rollups, formulas and automations. 4. How you would approach cleaning up an existing system while protecting current data. 5. Whether you would work directly in the existing system or create/test changes in a duplicate first. 6. Your estimated turnaround time. 7. Your fixed-price quote. 8. Exactly what is included in that price. 9. How many revisions are included. 10. Whether you provide support after the project is completed. Please Answer This Question in Your Proposal Explain how you would structure the relationship between: Customers → Bikes/Machines → Service Jobs when: * One customer can own multiple machines. * One machine can have multiple Service Jobs over its lifetime. * A returning machine should receive a new Service Job without creating another machine record. * The customer’s record should still allow us to access their overall history. I am asking this specifically because I’m looking for someone who understands relational database architecture and business workflows, not simply someone who creates attractive Notion dashboards. About Griff’s Griff’s Powersports Repair is a growing ATV/UTV repair business. We’re actively developing better systems so the business can grow beyond everything having to be handled manually by the owners. I’m looking for someone who can take what I’ve already built, understand what I’m trying to accomplish, and turn it into a clean, efficient system that actually works in the day-to-day operation of a repair shop.