Jump to content

Rick Guyton

Customers
  • Posts

    628
  • Joined

  • Days Won

    41

Posts posted by Rick Guyton

  1. Here's what we do:

    1) Create a "Star  Code" callflow leading to a menu. Pick a star code that's not in use anywhere else.

    2)  Drop in a Menu

    3) Create a menu message, set it to a TTS and input this  "Hello, I can help you open and close your office manually. For instance you may want to force your office to be closed during a holiday. Or, may want force your office to be opened if you will be staying late. A quick note before we get started, please do not end this call early or your system may not behave as expected. I will hang up the call when we are all finished. To reset your office back to the schedule setup when your system was configured, please press 1. To manually close your office, please press 2. To manually open your office, please press 3. Thank you."

    4) Drag in a manual presence three menu items. Set them all to update your star code feature. 1 should update to idle and 2 & 3 should update to busy.

    5) Under option 1 drag in a reset time of day and reset these TODs... "Main Monday" "Main Tuesday" "Main Wednesday" "Main Thursday" "Main Friday" "Main Saturday" "Main Sunday"

    6) Under option 2 drag in a disable time of day and pull in the same TODs

    7) Under 3 drag in en enable time of day and select the same TODs.

    I love this config. I've posted before about doing this with three separate BLF keys. But, that took up quite a few keys. And people would always forget when to use what keys. With this setup, the TTS explains how it works every time. So there's no need to train new people. It doesn't get forgotten about because there's a big red button when it's activated. And, we don't get pestered about setting holidays up for out clients.

     

    image.thumb.png.1b7f859dbc76723c56eb2d78d72c30f8.png

  2. I'd like to second (3rd?) the consistency issue with inheritance. Also, not listed, but critical for us is the load and save times. It takes on average 10-15 seconds to load a profile and 20-25 seconds to save the profile. For those of us with over 200 phones, that's more than an hour solid of sitting starting and a spinning circle just to make one system wide change. For instance, at one point, we needed to change our proxy server port on some but not all phones to 7000 to get a round a temporary glitch 2600hz was having. We did this via the provisioner because that's the only remote access we have in a lot of scenarios. But, still to this day there are an unknown number of my users that don't have redundancy because try as I might I just can't get myself to slog through the 2+ hours of wait time needed to check every single device we have. I know that re seller defined templates would fix this. But, it's truly unfortunate that we'd have to sacrifice support just to set consistent setting that over writes even user defined settings. So... that's my vent...

     

    Here's our list of priorities:

    1) Template customization (Wouldn't need this personally if we could simply define our own per-phone-model defaults)

    2) Provisioning service integration

    3) Adding a company directory to auto-provision with the phone (Oh man, if this broke out into categories using the proposed Locations App....)

     

    I really fell like all of the other items are completely un-important to us. Or, could easily be achieved using a supplemental config file that's available as a feature on most phones now.

  3. 4 hours ago, Chris Kerber said:

    II have to remind again, because this is one of the first times we're pushing out concepts so early in the design phase of this application, that everything is subject to change. I'll make sure that we take all of your suggestions/use cases into consideration when we push it up to technical review though!

    10-4. I think we all appreciate being looped in sooner than later. Thanks again for sharing.

  4. On 8/17/2017 at 3:33 PM, Josh Sanders said:

    Hey everyone! As Chris mentioned above, a new app—which will make handling multiple locations less cumbersome—is in the final stages of the design phase. As such, we wanted to share a few visuals from the design process.

    It's important to note that these visuals may not reflect the final app with full accuracy. Some information, functionality, and/or layouts depicted in these screenshots may not (or will not) be making it to development, as final mockups are still going thru revisions. With that said, they do represent the general look and feel of the app, so we wanted to share a glimpse of what's coming!

    locationsApp_teaser.png

    Wow Josh, this looks amazing! I have a few questions if you don't mind.

    While you are masquerading as say San Francisco, would you be able to reference a Portland user/device in call groups or main callflows? We have clients that frequently overflow calls from one location to another.

    Also, would Portland users be allowed to use San Francisco caller IDs, extension numbers, etc? Some of our clients have branch offices that need to operate effectively as HQ, but still need different 911.

    In addition, we have some users that operate as HQ, but work from home. These users will need their own DID/911. But I'm not sure a full "location" would be appropriate.

    Finally, one of my clients has a HQ biller that works out of a clinic that's near her home in Lousiana. Ironically, she doesn't even bill for the Louisiana clinic. It's just close to her. I'm curious if you'd have that user in the Louisiana clinic's location at all. Or, just set her up as a "work from home" style location like above?

    How would you handle these situations in your locations app?

  5. I'm testing the 81.0.110 firmware and I wanted to give you all a first impression.

    1) Ohhhh, finally this screen area is actually getting use. The primary account display name now scrolls across the top line here.

    2) All I ever really used this area for was to display the name of the phone. Now, it's a freed up programmable button I can do anything I want with!!

    3) BLF status now shows as a RED dot in the icon AND on the DSS button light.

    4) Ok, I got a little number happy, this just shows BLF in idle (green)

    5) Park icon is new and more representative of the function now. This is showing a parking spot in use

    6) Got number happy again, this is a parking spot that's idle.

    I'm pretty happy with it all so far. I've had a couple dozen phones on this F/W for a few days now with no negative feedback. The only thing I've found that I don't love is they now have an inactivity screen saver that comes on like after something like a minute or two of inactivity. As far as firmware flaws go, that's pretty easy to overlook.

    Also, the parking issue from 80.0.130 doesn't seem to be an issue. Need to confirm this on a few more phones though...

    Screenshot.png.c5ae51eefa55d72cf5a49330a9ca3a48.png

  6. Just now, Karl Stallknecht said:

    The customer doesn't want any phones to actually ring or indicate that a call is coming in.

    Ok, confused... If you want inbound callers to be automatically put on hold without any indication to the end user that's a queue. Unless they don't ever want the call routed to them??? If so, they won't be in business long. Sorry Karl, I've got to missing something here.

  7. 1 minute ago, Karl Stallknecht said:

    Not quite, but close...the idea would be that people call in without there being an actual ringback to the customer.

    Soooo.... Queues? ;)

    You can play hold music will it rings phones in the call group. It's a setting inside call groups. Is that what you are looking for?

  8. 1 hour ago, Darren Schreiber said:

    I agree with that completely. We'd LOVE to have the public feedback. Frankly we've also been struggling with how to get people to actually test. I know ya'all are busy, but honestly we can't think of everything to test and it drives the costs way up if 100% of the testing is on us.

    Ok two thoughts here.

    First, I'm not sure FW issues specifically needs to be handled in the sandbox. We can just upgrade our phones and report back like I did on the 80.130 yealink f/w. 

     

    Second, while I think bug hunter credits would be awesome, I think the bigger issue is more that we don't know what awesomeness is available in sandbox because you only announce changes when they get to production. Right now for instance my Monday is clear. If I knew what new hotness was available in sandbox right now, I might spend a good part of the day whacking at it. And if I knew when that multi location feature was dropping, I'd block off a week to turn it inside out and back again. But I really don't want to slog through every app in sandbox trying to find new buttons to hit every week.

  9. Perhaps the solution to all of this might be the white label URL for firmware.

    For those that want a different default firmware than what's offered:

    If you are hosing your own files, who says T27-45.80.0.95.rom has to actually contain 45.80.0.95? Rename T27-45.80.0.130.rom to T27-45.80.0.95.rom and boom! Now your "default" is .130 not .95.

    For those that are concerned about new firmware:

    So... don't put up the new T27-45.999.999.999 firmware up. Provisioner can reference it all it wants. If it's not there, it's not upgrading.

    Thoughts?

×
×
  • Create New...