> For the complete documentation index, see [llms.txt](https://codehas.gitbook.io/the-repairbox/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://codehas.gitbook.io/the-repairbox/faq.md).

# FAQ

This FAQ answers common questions about using RepairBox: how repair records work, how catalog and custom intake differ, how staff portals and outlets are organized, how estimates/billing and notifications interact, and what to check when a workflow does not behave as expected.

**Important:** RepairBox options can vary by deployed version, permissions and configuration. Answers distinguish the product's documented data model and verified behavior from features that must be confirmed in the installed UI. Do not assume that a control or automation exists just because it is useful.

## 1. RepairBox basics and business fit

### 1. What does RepairBox do?

RepairBox connects customer intake, repair tracking, workshop processing, diagnosis, estimates and approvals, quality control, billing/payment records, customer communications and reporting. The central workflow is:

**Customer → Repair Order → Repair Items → Diagnosis → Estimate/Approval when required → Repair → QC → Invoice/Payment → Pickup/Completion → Notifications and history.**

Start with Repair Management Overview.

### 2. What types of repair businesses can use RepairBox?

It is designed for device-repair workflows such as mobile/tablet shops, computer/laptop repair services, electronics and game-console workshops, multi-device intake counters, and businesses with multiple outlets. It can also represent business customers and their billing details. The business must configure its catalog, statuses, permissions, tax rules and checklists to fit its real operations; RepairBox does not automatically know every shop's process.

### 3. Can a business operate more than one outlet?

Yes, RepairBox's product model supports a business with multiple outlets. Repair Orders belong to an outlet and user access/reporting should respect outlet scope. Configure the business/outlets and verify where a test order is saved. See Business & Outlet Management.

### 4. What is the difference between the Admin Portal and Workshop Portal?

The Admin Portal (`/admin/*`) covers administrative and operational tasks according to permission: customer intake, catalogs, users, settings, billing and reporting. The Workshop Portal (`/workshop/*`) focuses on assigned repairs, diagnosis, checklists, notes, status updates, reassignment where permitted, QC and workload. A technician should not automatically receive every admin or financial permission.

### 5. Does every feature work automatically after installation?

No. Catalogs, outlets, users/roles, statuses, priorities, checklists, tax/billing, notifications and external providers need appropriate setup. Provider credentials alone do not enable every notification; a payment-provider account alone does not prove every checkout/refund flow is available. Complete Initial Configuration and test workflows before live use.

## 2. Customers, Repair Orders and Repair Items

### 6. What is a Repair Order?

A Repair Order represents the overall customer repair transaction/intake. It has a database identity and a separate human-readable repair reference, for example `REP-2026-000125`. Use the human-readable reference for everyday communication, but do not treat it as a secret token or database primary key.

### 7. What is a Repair Item?

A Repair Item represents one device/unit under a Repair Order. It can have its own device details, problem, service/defect, diagnosis, technician, status, checklist, notes, attachments, pricing and activity history. One order can therefore contain devices at different stages.

### 8. Can one Repair Order contain multiple devices?

Yes. This is a core RepairBox model. Add a separate Repair Item for each device so its services, condition, accessories, technician, status and notes do not become mixed with another device. See Adding Multiple Devices.

### 9. When should I create separate Repair Orders instead?

Use separate orders when the devices belong to different customers, separate commercial transactions or unrelated operational processes, according to your business policy. The same customer bringing two devices at one visit can often use one order with multiple items, but that is not mandatory for every situation.

### 10. How do I create a Repair Order?

Find or create the correct customer, select the responsible outlet where required, create the order, add each device as a Repair Item, select standard or custom intake, record the reported problem and relevant condition/accessories/notes, set the appropriate initial state/priority, then save and verify the record. The exact fields shown depend on the installed form. See Creating a Repair Order.

### 11. Can I change customer or device details after saving?

Use the edit controls and permissions available in the installed application. Before changing a customer association or a device description, confirm that the record really belongs to that customer/device. Historical repair facts, financial records and activity history should not be silently overwritten. If the edit would change a quote or invoice, follow the relevant billing correction process.

### 12. What information should be captured at intake?

Capture the customer and contact details needed for the job, the correct outlet, device/model or custom description, customer-reported problem, relevant services/defects, existing damage/condition, accessories actually received, and useful photos/notes where the form supports them. Do not store device passwords, unlock codes, card data or unnecessary personal information in general notes.

### 13. Why should customer-reported problems and technician diagnosis be separate?

The reported problem records what the customer says; diagnosis records what the technician establishes after inspection/testing. “Battery drains quickly” is a symptom, not proof that the battery must be replaced. Keep both facts visible in the appropriate repair fields/history. See Diagnosis & Repair Workflow.

## 3. Catalog-based and custom repairs

### 14. What is a standard/catalog-based repair?

It uses shared catalog records. The intended selection path is **Device Type → Brand → Device/Model → relevant Services and Defects**. This helps staff use consistent device names and relevant service/problem options. See Device Catalog.

### 15. When should I use a custom repair?

Use custom entry when the device/model is missing, ambiguous, vintage/unusual or not accurately represented by the catalog. The RepairBox model supports manually describing Device Type, Brand, Model, Problem, Service and Notes. Do not select a similar-but-wrong catalog model just to complete the form. See Standard vs. Custom Repairs.

### 16. Does a custom repair automatically add a new model to the shared catalog?

It should not be treated as a catalog-maintenance action. Custom details describe the particular repair and must not automatically create a global device/service/defect record. If the business wants to reuse a model or service, an authorized user should deliberately add it through catalog management after checking duplicates and relationships.

### 17. What is the difference between a Service and a Defect?

A **Service** describes work requested or performed, such as Screen Replacement. A **Defect** describes a reported/observed problem, such as Cracked Screen. A defect is not automatically a confirmed diagnosis, and selecting a service is not proof the customer approved the final work. See Services & Defects.

### 18. What should I do if a device/model or service is missing?

For the current repair, use custom entry if that option is available and appropriate. Separately ask an authorized catalog manager to review whether a reusable record should be added. Check the brand/model and service/defect relationships before creating new entries to avoid duplicates.

### 19. Do catalog choices determine the final price?

Do not assume so. Catalog services may provide structured choices and may have pricing fields depending on the deployed version. The final estimate/invoice can depend on configured charges, approved scope, tax, discounts and other rules. Verify the saved estimate/invoice rather than treating a service label as a guaranteed total.

## 4. Statuses, priorities, assignment and workshop workflow

### 20. What is the difference between status and priority?

**Status** tells the team where the repair is in the lifecycle. **Priority** tells the team how urgently work should be handled. An item can be Waiting for Approval while still marked Urgent. RepairBox's documented public booking flow lets customers choose a priority, and the priority-management form includes an extra-charge amount. Low priority is the documented default with zero extra charge; other levels and amounts are configured by the business. Example charges are illustrative, not universal. Verify the displayed fee and final total in your current booking flow; do not assume a priority automatically guarantees a completion deadline or automatic queue reassignment.

### 21. Can statuses be customized?

RepairBox's status model is configurable. Its documented status fields include Name, Slug, Description, Color, Sort Order, Is Active, Is Default and Is Terminal. Keep labels meaningful and test how the installed workflow uses terminal/default flags. Adding a status label alone does not enforce a checklist, customer approval or payment rule. See Repair Statuses & Priorities.

### 22. Why are Repair Order status and Repair Item status different?

The order summarizes the overall customer transaction; the item describes one device. A phone may be in QC while a laptop in the same order is awaiting diagnosis. Update the correct level and ensure customer-facing messages do not say every device is ready when only one item changed.

### 23. How do I assign a technician?

Open the right Repair Order and identify the Repair Item, then use the assignment control available in the installed app, save and verify the intended item's assignee. Assignment is permission-controlled (the product permission vocabulary includes `tickets.assign`) and must respect outlet scope. Do not assume an order assignment automatically changes every item. See Assigning Technicians.

### 24. Can a repair be reassigned?

Reassignment depends on the current user's permissions and the controls available in the deployed workflow. Preserve diagnosis, work notes, checklist outcomes and handover context; do not erase previous assignment history. Verify the new technician can access the item and that other devices in the same order were not unintentionally reassigned.

### 25. How should technicians use checklists and diagnosis?

Use checklists to record the checks/actions actually performed. Use diagnosis fields/notes to record technical findings. If a check fails, record the failure and the next step; do not mark the device ready merely to finish a workflow. Exact checklist fields and automatic status-blocking behavior depend on the installed version. See Checklists & Diagnostics.

### 26. What happens if QC fails?

Record which check failed, return the item to the appropriate repair/rework state using the supported workflow, and repeat the relevant checks after corrective work. Keep the item out of Ready for Pickup when required checks have not passed. Do not assume the application automatically blocks a state change unless the deployed code implements that rule. See Quality Control.

### 27. Does “Ready for Pickup” mean the order is completed or paid?

Not necessarily. Ready for Pickup is a readiness/hand-over state; actual collection, completion and payment are distinct facts. Review the relevant Repair Item(s), invoice/payment records and completion action. If an order contains multiple devices, one item being ready does not mean all items are ready.

### 28. Can an order be cancelled and the payment refunded automatically?

Do not assume so. Cancellation and refund are separate workflows. Follow the installed cancellation process and business policy, keep the original invoice/payment history, and use the supported refund/credit process if money must be returned. Verify provider and RepairBox records where online payment is involved.

## 5. Customers, roles and outlets

### 29. Can RepairBox manage individual and business customers?

The customer model supports **Individual** and **Business** customer types. Business records can include legal company name, contact person, registration/tax information and billing details, depending on the fields exposed by the deployed form. Choose the type that matches the customer record and invoice context.

### 30. How do I prevent duplicate customer records?

Search existing customer records using available name, email and phone values before creating a new one. Verify identity—similar names or a shared phone number are not enough to merge people. Normalize international phone numbers consistently where supported and use the approved process for correcting duplicates.

### 31. Can customers have multiple addresses and contact methods?

The customer model is designed for primary/secondary email and phone, language/contact preferences and multiple addresses such as Billing, Shipping, Service and Other. Exact entry/edit options depend on the installed customer form. A stored Shipping address does not by itself prove a courier or delivery workflow is enabled.

### 32. How do roles and permissions work?

Roles group permissions; permissions authorize specific actions. RepairBox's permission vocabulary includes areas such as repairs, customers, devices/services/defects, checklists/diagnostics, billing/payments/tax, notifications, users/roles and reports. Roles are dynamic. Backend authorization—not just hidden frontend buttons—must deny unauthorized actions. See Roles & Permissions.

### 33. Can a technician see every outlet's repairs?

Only if their role and outlet scope permit it. Outlet access is a separate boundary from general role permissions. Test list, detail, export and attachment routes; hiding another outlet in the UI is not sufficient security.

## 6. Customer portal and booking/tracking widgets

### 34. What can customers do in the Customer Portal?

Depending on which features are enabled, customers may view their authorized repairs, check progress, review estimates and submit approvals, see invoices/payment information, view notifications and manage permitted profile/contact preferences. The current deployment determines the exact screens and actions; a public tracking page is not the same as authenticated portal access.

### 35. Is the public tracking widget the same as the Customer Portal?

No. The product guide documents a public Track Repair widget where a visitor enters the Repair ID and sees repair status and repair logs; the result can be printed or downloaded as PDF. The Customer Portal is the authenticated alternative for the customer's authorized records. Because the documented public lookup accepts a repair ID, treat that ID as a reference—not a secret. Confirm the deployed widget's fields and ensure internal notes, private customer details and unrelated records are not exposed.

### 36. How does the embedded repair booking widget work?

It places a customer intake journey on the business's website. A customer enters contact and device/problem details, submits the request, and RepairBox should validate and persist the data according to the installed widget workflow. Staff then verify the saved customer/order/items and continue the repair process. The success message must accurately say whether a request was received or an order was confirmed.

### 37. How do I configure the booking widget?

The product guide documents an **App Settings → Embedding Code** area that generates snippets for the Repair Booking Form, Track Repair widget and Support Form widget. Use the currently generated snippet, not a guessed script URL. The documented booking flow selects Brand → Device/Model → one or more related Services/Defects → priority → required customer information → payment information when that payment step is enabled. After successful payment, the documented flow confirms the Repair Order by email and offers a printable result. Before publishing, test the currently deployed widget, inspect the saved RepairBox order/items, verify the priority fee and payment state, and confirm the notification recipient. Only describe additional embed switches—such as custom CSS, a language selector, sizing or allowed-origin controls—if they actually appear in the installed widget configuration.

### 38. Can a public booking submit multiple devices?

The core RepairBox model supports multiple Repair Items under one Repair Order. Verify that the deployed widget's actual form supports adding multiple devices and that each submission creates/associates a separate item. Do not promise multi-device public intake until it has been tested in that widget build.

### 39. Does submitting the widget automatically confirm the repair, appointment or final price?

The documented public booking flow includes required customer information and a payment step; after successful payment it confirms the Repair Order by email and provides a printable result. The current deployment should be tested to confirm the same sequence is enabled. Submission/payment still does not mean the device has been diagnosed, the repair has passed QC, or a completion date is guaranteed. Do not promise appointment scheduling unless the current widget actually offers it.

### 40. What information should public widgets hide?

They should not expose admin/workshop records, private customer data, internal notes, secret tokens, staff-only attachments or another customer's Repair Order. Validate and authorize on the server; do not send the full staff resource to the browser and rely on CSS to hide fields.

## 7. Estimates, invoices, tax, discounts and payments

### 41. What is the difference between an estimate and an invoice?

An **estimate** proposes work and expected cost; an **invoice** records charges for payment. Sending an estimate is not customer approval, and an approved estimate is not proof of payment. Keep all three states/records distinct.

### 42. How does customer approval work?

Use the approval action/state actually available in the installed RepairBox workflow. Verify the correct customer, device/scope and estimate version; record approval or rejection; do not proceed with chargeable work that requires approval until approval is recorded. A sent/read notification is not approval. If scope or price changes, use the supported revision process.

### 43. How is the invoice total determined?

Verify the saved invoice lines, currency, configured service/charges, tax and discount treatment. Do not trust a total sent from the browser or assume a catalog service equals the final amount. The precise tax-inclusive/exclusive rules and line-level behavior must be confirmed in the deployed billing workflow.

### 44. Can RepairBox apply tax/VAT and discounts/coupons?

Tax/VAT and discounts/coupons are documented parts of RepairBox's billing scope. Their exact fields, restrictions, stacking rules and calculation order depend on the installed billing forms and code. Test a sample invoice and reconcile the result before using live financial data. Avoid applying the same tax or discount in both RepairBox and an external provider unless reconciliation is designed for it.

### 45. How should online payments be verified?

Use the supported provider integration and reconcile the result to the correct RepairBox invoice/payment record. A browser success page is not authoritative proof of settlement. With Stripe, use matching test/live keys, validate signed webhooks and make event processing idempotent. Do not mark an invoice paid solely because the customer returned to a success URL.

### 46. Does cancellation delete an invoice or automatically refund a payment?

No such behavior should be assumed. Cancellation, invoice correction and refunds have different meanings. Preserve the original financial records and use the supported refund/credit process with appropriate permissions and reconciliation. Check the actual gateway result and RepairBox payment record.

## 8. Notifications: how delivery actually works

### 47. Why is a notification not sent even though the provider is configured?

Provider setup is only one gate. The current RepairBox notification implementation has a **Customer Notifications** enablement control, **Default Contact Methods**, channel-specific templates, recipient resolution and channel/provider configuration. The observed default for `default_contact_method` is `['email']`. A customer notification template whose channel is not selected in Default Contact Methods is skipped.

### 48. What is the difference between Default Contact Methods and provider settings?

Default Contact Methods controls whether a customer notification channel passes the dispatcher gate. Provider settings connect the application to the mail/SMS/WhatsApp delivery service. Selecting SMS does not create provider credentials; enabling a provider does not make an unselected template channel send. Templates must also exist and match the event.

### 49. Which channels are confirmed in the current notification evidence?

The implementation note confirms Email, SMS and WhatsApp as customer contact-method values, plus a separate in-app notification path where applicable. The observed default is Email only. Always verify the actual settings page and installed build before assuming an additional channel or event is available.

### 50. Why must SMS and WhatsApp be tested before enabling live messages?

The current implementation note identifies a recipient-resolution defect: the repair dispatcher passes the customer's email as a generic recipient, and SMS/WhatsApp code may prefer that value before falling back to the customer's phone. **Do not enable live SMS/WhatsApp customer dispatch until the code fix is deployed and a controlled test confirms the logged destination is the customer's phone number.** Changing Default Contact Methods alone will not fix the recipient bug.

### 51. How do I troubleshoot a missing notification?

Check in this order: (1) did the event occur? (2) is there an active matching event/channel template? (3) are Customer Notifications enabled? (4) is the template channel selected in Default Contact Methods? (5) is the provider configured and enabled? (6) does recipient resolution choose the correct email/phone? (7) what status/skip reason/provider response is logged? Check queue workers only if the deployed delivery path uses asynchronous jobs. Do not keep changing a repair status to force another send.

### 52. Does a “sent” notification mean the customer received/read it?

Not necessarily. An application/provider may accept a request without proving the recipient received or read it. Keep repair state, customer approval, payment state and notification delivery as separate records. Use provider delivery status/logs where available.

### 53. Can every status change send a notification?

Do not assume so. A status change sends a message only if the installed app emits the corresponding event and an active matching channel template is configured, with all notification gates passing. Current evidence confirms a Repair Created flow but does not prove every status, assignment, estimate, QC or payment event has a default template.

## 9. Integrations and troubleshooting

### 54. What is the difference between an API token and a webhook secret?

An API bearer token authenticates a client calling an authorized API. A webhook signing secret verifies events sent by a provider or webhook sender. They are not interchangeable. Keep both server-side, use HTTPS, verify the expected authentication scheme, and never put staff tokens in public widget code.

### 55. How should Stripe webhooks be handled?

Use the exact endpoint and signing secret for the right Stripe environment, verify the signature with the supported Stripe method, match the event to the stored RepairBox payment/invoice, and process duplicate events safely. A webhook success does not mean every downstream notification was delivered.

### 56. Why does a webhook arrive more than once?

Webhook delivery is commonly retried when a sender does not receive acknowledgement. Consumers should verify authenticity, store event identifiers, deduplicate processing and make side effects idempotent. Do not create a duplicate payment, repair or customer message for the same logical event.

### 57. Can I put API keys in a widget or React code?

No. Secret API keys, bearer tokens, SMTP passwords, provider tokens and webhook signing secrets must remain server-side or in a protected secrets manager. Public widgets must call narrowly scoped public endpoints and must not inherit staff access.

### 58. Which features should I test before going live?

At minimum: customer creation/matching; standard and custom repair intake; an order with multiple devices; item-level technician assignment and status changes; diagnosis/checklist/QC failure and pass; estimate and approval; invoice and payment reconciliation in test mode; email delivery; SMS/WhatsApp recipient mapping after the fix; public booking/tracking authorization; and outlet/role access boundaries.

### 59. Can I import/export the catalog, automatically schedule pickups, or deduct inventory?

Only treat those capabilities as available if the current deployed UI/code explicitly supports them. They may be useful in a repair business, but an import/export action, appointment workflow, shipping/delivery integration or inventory deduction must not be promised based only on the broader product model. Check the relevant catalog/workflow screen and release before relying on it.

### 60. What is the safest way to investigate an unexpected result?

Start with the authoritative record: Repair Order, Repair Item, estimate, invoice/payment, checklist or notification attempt. Verify the saved data, current user's permission/outlet scope, event/template/provider gate and logs. Do not repeatedly submit a booking, re-trigger a status or retry a payment until you have checked whether the original action already succeeded.

### 61. What are Canned Replies, and do they send automatically?

Canned Replies (also called Quick Replies) have a Title and Body/Content that staff can reuse during a supported workshop/customer communication action. Saving a reply only stores the snippet; it does not itself send a message or create an automatic status trigger. Event-driven messages are configured separately through Notification Settings. See Canned Replies.

### 62. Where can I purchase RepairBox at a discounted price?

{% hint style="success" icon="tag" %}
Purchase RepairBox through the [official Gumroad listing](https://codehas.gumroad.com/l/repairbox) at a **10% discounted price**.
{% endhint %}

### 63. Can I request a customized version of RepairBox?

{% hint style="info" icon="envelope" %}
Yes. We offer customized versions for business-specific requirements. Contact <info.codehas@gmail.com> and describe the features or workflow changes you need so we can discuss your requirements.
{% endhint %}

## Related documentation

* Welcome to RepairBox
* Initial Configuration
* Creating a Repair Order
* Standard vs. Custom Repairs
* Device Catalog
* Repair Statuses & Priorities
* Customer Portal
* Notification Settings
* Embedded Repair Booking Widget
* Public Repair Tracking Widget
* Stripe Integration
* API Authentication
* Webhooks and Notifications
* Canned Replies