Currently, we have 3 registers in our system: 2 registers for our front checkout desks, and 1 "register" that is actually a lockbox. In the event that we have an excess of cash in the front register(s), we make a withdrawl from that register and then deposit it into the lockbox for safekeeping, this requires 2 separate transactions. From there, we either keep it in case we need it to put back in the register, or withdraw it again to deposit it into the bank.

I would like to see a transfer button that allows a user to select which register they are pulling the funds from, and specifies which register they are transferring the funds too. This would allow for a more simplified approach than two separate transaction, and a register change. I'm not concerned about being at the specified box to make the deposit because only two managers have the ability to do this, as well as each register is verified at the end of the day anyway. If an error somehow occurs, it should be easy to resolve.

On desktop:

The Ticket Summary\View Log\"Notes" section is horribly restricted. We write a good deal of information in this log, so as it expands downward we end up with a thin looking column. Worse is when we have 2 or 3 entries like this in the log. It creates a need for a lot of extra scrolling.

1st Suggestion: If the "Notes" are bigger than 5 lines, there should be a "See More" button. This will create a nice uniformity. Downside is you would need that additional click to see the full note.

2nd Suggestion: The "Notes" column width should be 2 to 3 times greater. Downside here is that larger notes will still need a lot of scrolling, but they will be easier to read.

Just wanted to share our Twilio integration with everyone for inspiration purposes. Before I get to how we are using it with RepairShopr, let me just detail why we have all our phone numbers with Twilio.

We recently implemented Intercom as our customer-facing support & communication tool. This means that all customer communication goes through Intercom now. We did this because our clients have indicated to us that multiple communication channels are important. Using Intercom, our clients are able to chat with us via our website and our remote assistance website (ScreenConnect) as well as via email. We then hired a developer to write an integration to allow us to communicate via SMS through Intercom (via Twilio). So now, a customer can email us, text us, or chat with us and it's all through one interface. Pretty great. The next step for us will be integrating Intercom and RepairShopr so that we can easily move a conversation to a ticket (with Zapier, this is possible, but it's an all-or-none approach). We'll likely develop a custom integration for that too.

The next thing we wanted to do with Twilio was move our PBX into it. Right now, all calls are forwarded to cell phones, but we use 3CX to implement the IVR. By using Twilio studio, we moved all that to Twilio. The only thing we're missing is call confirmation, which we are working with Twilio on getting sorted (so that we can press 1 on the receiving cell phone to accept the call). So after building out the IVR in Twilio, and building out a couple of direct-to-cell flows for direct lines, I got a bit creative and did this...

When a call comes in to our IVR, the user chooses from several different options. Once they are at the point where they'd be connected to either an individual or individuals, we kick off an API request to RepairShopr to see if the callers number matches a customer entry. Now, this isn't perfect at the moment because Twilio will search for a number as "+15552225555", so it won't match if the number stored is "15552225555" or "5552225555. So we have some work to do to update our customer numbers. Now, if there is no match, Twilio will do another API lookup against OpenCNAM so we at least have more information. In either case, the data from the API is passed along via Pushover to the user or users who will then be called (so they know it's a work call coming in, with different notifications depending on if the person chose a direct extension or a "book a service call" option). And if there is no answer, they go to a Twilio voicemail, after which the voicemail URL is sent via Pushover. That part also isn't perfect right now because if they get the end-users cell phone voicemail (because they declined the call or their phone was off), Twilio doesn't know and believes the call is connected. That's where the "press 1 to accept" comes into play.

FYI, you can also send text messages instead of using Pushover. We went with Pushover because we already use it for other things and it's technically cheaper than SMS (looking past the one-time payment required for the app). But we did originally have it working with SMS just fine.

I'd love to hear any feedback anyone has on other things to do here. Twilio is quite incredible when it comes to stuff like this.

Let's add icons next to appointments that match up with the "Appointment Type". This way we don't have to click into each appointment to know if we need to be onsite, or remote in, or just make a simple phone call. This should leverage the icons that are already selectable per customer profile. We should be able to assign an icon to each appointment type (seeing as though each shop will have their own different appointment types)

My team already writes the appointment type into the ticket subject, but that field is limited and I would rather use it for pertinent information about the appointment/ticket/fix.

See my proposed graphic below

https://imgur.com/eeZQsTR

When creating a customer we always ask if they would like to receive our email communications. If they opt in, we are synced with Mailchimp so they will be added to our list. Because we are sensitive to our customer's privacy and preferences, we'd like to have the opt out box checked by default so we have to UNcheck it if they want to opt in.

This is not a big deal, but since there are preferences for other things to be checked by default, it would be nice so we don't inadvertently add people to our list who did not opt in or who were not asked. Thanks!