Important product naming update: Sidekick is now called Gladly (AI) and Gladly Hero (the Platform) is now Gladly Team. Please keep this in mind as you read through our documentation.

Repairshopr on App Platform Overview

Prev Next

RepairShopr runs repair and service businesses: computer and phone repair, appliance work, managed IT and field service. The RepairShopr App Platform integration brings the Customer’s repair tickets onto the Gladly Customer Profile (ticket number, status, what the item is in for, the promised date, the assigned tech and the location), matched automatically from the email address already on the profile, so Team members answer “is my repair ready?” without opening RepairShopr.

Your Team members act on a repair from the Conversation through four forms in the compose menu, and gives Gladly AI six actions. No form asks for an internal ID: the Team member picks the repair from a list of that Customer’s own tickets, and the Customer is resolved from the profile. The ticket statuses and problem types a Team member may set are limited to the values the merchant allows.

Customer repair tickets for laptop issues and scheduled maintenance details displayed.

Key benefits

Every repair on the Customer Profile

The Repairs card lists the Customer’s repair tickets with number, status exactly as your shop names it, subject, problem type, created and promised dates, assigned tech and location. Resolved repairs stay on the card alongside in-progress ones, so a finished job can be confirmed as readily as one still on the bench. There’s no ticket number for the Team member to ask for first.

Act on a repair without leaving the Conversation

Four forms in the compose menu cover the day-to-day work: start a repair ticket, update a repair’s status, add a note for the bench techs or the Customer, and book an appointment.

No internal IDs, ever

RepairShopr identifies a ticket two ways: a number the Customer sees on their receipt, and an internal ID its API writes to. They are different values, and confusing them sends a change to the wrong record. Team members see neither; they pick the repair by its number, subject and status, and the app supplies the ID.

Merchant control over statuses and problem types

RepairShopr’s API accepts any text as a ticket status or problem type without validating it, so a typo silently parks a repair in a state your automations, saved searches and reports do not recognize. The app enforces the list you configure before the request is built, and that same list is what Team members pick from, so they are never offered a value the app would refuse.

Customer emails are never sent by accident

A note and an appointment booking can both email the Customer from your shop’s RepairShopr account. Both default to silent. Emailing is an explicit choice on each form, and the confirmation the Team member sees says which way it went.

Supported features

The RepairShopr App Platform integration is available in the following areas of Gladly:

Gladly Team

The Repairs card is available on the Customer Profile. When a Team member opens a Conversation, the card matches the Customer to their RepairShopr record and renders their live repair tickets alongside the Conversation.

Four agent forms are available from the compose menu. These require a one-time setup step described under Install.

Gladly AI

Data Pulls are available in Guides, so Gladly AI can answer repair questions from the Customer’s live RepairShopr data during a Conversation. All six actions can be called as part of a Guide, including the two lookups that have no form.

Details

What data can you access

Repairs card

  • The Customer’s total repair count, in the card header

  • The RepairShopr customer name, or business name where the record is a business

  • For each repair: ticket number, status as your shop names it, and subject

  • The problem type the ticket is filed under

  • The date the repair was created and the date it is promised back

  • The assigned tech, where one is set, and the shop location handling it

  • Repairs your shop has marked resolved, shown alongside the open ones

  • A plain message rather than an empty card when the Customer has no RepairShopr record, or has a record but no repairs

  • A note of how many repairs exist in total when the Customer has more than one page of them

Customer and ticket records

  • Customer: RepairShopr customer ID, display name or business name, and email address

  • Ticket: internal ticket ID, customer-facing ticket number, subject, status, problem type, and the created, promised and last-updated dates

  • Ticket: assigned tech and location name, where your shop sets them

  • The shop’s own ticket status list and problem type list, used to populate the choices Team members see

What Team members can do from the Conversation

Four forms are available in the compose menu:

  • Start a repair ticket: for a Customer already in RepairShopr, with a subject and a problem type from your approved list

  • Update repair status: pick one of the Customer’s repairs, then a status from your approved list

  • Add note to repair ticket: internal by default, with an explicit option to email it to the Customer

  • Book an appointment: with a summary, a start time in your shop’s local time, and a length

The two lookup actions have no form on purpose. They exist so Gladly AI can find the record it needs, and a Team member never has to, since the forms already resolve the Customer and list their repairs.

Supported actions

Six actions are available. Two are reads: find a repair ticket by the customer-facing number, and find a Customer by email address. Both return the internal IDs that the write actions take.

The four writes create a repair ticket, change a ticket’s status, add a note to a ticket, and book an appointment. Each validates its input before any request reaches RepairShopr, so a status or problem type outside your approved list, or an appointment date that could be read two ways, is refused with a message explaining why rather than written incorrectly.

Adding a note or booking an appointment can email the Customer from your shop’s RepairShopr account, using your shop’s email template and reply-to address rather than Gladly’s. Neither does so unless the Team member chooses it.

Merchant settings

Two settings in the app configuration decide what Team members and Gladly AI may set on a ticket. Both are optional, and both feed the choices shown on the forms.

  • Ticket statuses agents may set: a comma-separated list matching your RepairShopr status names exactly. This is what the status list offers, and the only set the app will accept. Left blank, the app falls back to RepairShopr’s seven standard status names.

  • Problem types agents may set on a new ticket: a comma-separated list matching your RepairShopr problem types exactly. Left blank, Team members cannot set a problem type at all, and RepairShopr files tickets created from Gladly under its own “API” type.

If your shop has renamed its ticket statuses, fill in the status list before rolling out. Until you do, the app offers only RepairShopr’s standard names, which your shop no longer uses.

How does customer matching work?

The app finds the Customer’s RepairShopr record from the email address on the Gladly Customer Profile, using RepairShopr’s own customer search. That search matches on name and business name as well as email, so occasionally more than one RepairShopr customer comes back for one profile.

When that happens, every match is shown rather than the first one being taken silently, and each repair in a form is labeled with the customer it belongs to, with a prompt to check the name before writing to it. A Customer with no email address on the profile, or no RepairShopr record, sees a plain explanatory line on the card rather than an error. If RepairShopr itself returns an error, that is reported as an error rather than as a Customer with no repairs.

Key use cases

Answer “is my repair ready?”

Use case: A Customer emails or calls to ask whether their item is finished.

How it works: The Team member reads the status, promised date and assigned tech off the Repairs card. A repair your shop has already resolved is on the card too, so a finished job is confirmed just as quickly as one still in progress.

Business impact: The most common question a repair shop receives is answered in the first reply, without opening RepairShopr and without asking the Customer for a ticket number.

Start a repair and book the drop-off in one Conversation

Use case: A Customer calls to arrange a repair they have not brought in yet.

How it works: The Team member creates the ticket with a subject describing the item and fault, picks a problem type from your approved list, then books the drop-off appointment. The Customer is carried through from the profile, so neither form asks who the repair is for.

Business impact: The job is on the bench schedule before the Conversation ends, rather than becoming a note for someone to key in later.

Move a repair to Waiting for Parts and tell the bench

Use case: A repair is blocked pending a part.

How it works: The Team member picks the repair from the list, sets the status to your shop’s own “Waiting for Parts” value, and adds an internal note for the technicians. The note stays internal unless they choose to email it.

Business impact: The shop’s reporting stays accurate because the status came from your approved list, and the bench gets the context without a separate message.

Keep the Customer informed without leaving Gladly

Use case: A repair is finished and the Customer should be told it is ready for collection.

How it works: The Team member adds a note to the ticket and chooses to email it. The note is recorded on the repair and sent from your shop’s RepairShopr account, so it carries your shop’s template and reply-to. The confirmation states that the Customer was emailed.

Business impact: The Customer record in RepairShopr and the Conversation in Gladly tell the same story, with no separate copy-paste step.