On Nov 29, 2006, at 11:40 PM, Lacy Moore - Aspendora wrote:
[snip]
I went from a Lucent Merlin Legend system to Asterisk. For me,
it's a tradeoff for features. To my users, it was a step
backward. I also upgraded an office from a Partner system to
Asterisk. To the users, it is a huge step backward. They have yet
to figure out how to transfer a call. On their old system, they
put the call on hold and pressed the line button at another phone.
Today, they hold the phone against their leg so the caller doesn't
here them yell for the person to come to the phone, and then the
person who the call is for comes to that phone and answers the
call. It will remain that way for them, because learning how to do
it the right way takes more work than the person coming to the
phone, or so they say.
Sounds like you have stumbled upon one of the truisms of replacing
office phone systems: people hate it when you take away their key
system "lines". So you're right, it would be a good idea for Asterisk
to implement that functionality, and they are working on it, IIRC. It
also sounds like you need to talk to your customers more before you
roll out a system, so they know ahead of time what the interface will
be and what changes they should expect. If you let them know ahead of
time, and get management on board, you should be OK.
I won't be doing another Asterisk install for a while. Customer #2
has made sure of that by telling everyone how their new phone
system sucks. Until I can find a suitable solution, I am dead in
the water. And yes, I am trying to learn C so that I can write it
myself, or modify something else to make it work.
Given the flexibility inherent in Asterisk, you really shouldn't have
to code your own. It's a great skill, but not necessary.
But seriously, the attitude of either write it yourself or deal
with it won't cut it for business users. If Asterisk is only for
geeks, then fine, it will work perfectly.
Well, not to be rude, but if you plan to sell, install, and maintain
Asterisk systems, you shouldn't be just a "business user", you should
be at least a little bit geeky. I would suggest that Asterisk works
excellently for business users, but it requires a person who is a bit
of a geek to set it up properly for those business users so they
don't notice how geeky it really is.
If all phones behaved the same, it would help. Cisco, using SIP,
has no park button. Cisco, using chan_sccp, has a great parking
concept. Polycom has a park button that doesn't appear to work
with Asterisk. We use Cisco (SIP) and Polycom. Aastra and SNOM
seem to have an easier "parking" interface. The chan_sccp
implementation not only reads back the parking spot, but also
displays it on the screen.
Why don't you take the specific phone interface out of it? Most of
your (and your users') gripes seem to be things that could be
resolved with a little research, planning, and a better grasp of
Asterisk configuration.
for example: In your example above where they can't figure out how to
transfer, why don't you edit features.conf and define the transfer
key as # or something. Then, when they have a call for "Bill" across
they way, they can do this:
1.) Answer call, determine call is for Bill.
2.) Press #. Asterisk reads back "Transfer".
3.) Dial parking extension number (700, for example)
4.) System reads back parking space number (703, for example)
5.) Call or shout to Bill "You have a call on 703"
This is not really much harder or more complicated than what they are
used to with their old key system:
1.) Same as above
2.) Press Hold Button
3.) Look at phone to see which line #
4.) Call or shout to Bill "You have a call on Line X"
This approach also cuts out the "press More button, press Transfer
Button" issue you mention below.
Getting users to make that change shouldn't really be that difficult,
especially if you let the customer know what to expect from the
beginning. Focus on management and stress the advantages they receive
as a result of Asterisk being a full-fledged PBX, not a key system.
Then explain that minor changes in the user interface are the small
price they must pay for those advantages.
What I have tried to do is the following scenario. Assign two
line keys as Park 720 and Park 721, and using third party patches,
been able to monitor those lines (which are actually parking spots)
using hints. Also, using third party patches, I can transfer to
those lines (transfer directly to a parking spot), but again, that
is a several step process (it requires a blind transfer which take
pressing transfer, then blind on the Polycom, this method, due to
no BLF does not work on the Ciscos) that just won't happen in small
businesses. It just takes too many button presses. Plus, as I
mentioned, this is third party patches that aren't in the Asterisk
main branch, and makes upgrades near impossible.
Again, this seems overly complicated, and implies that you are not
aware of the ability to specify a key for transfer in features.conf
as I mentioned above. Try to think outside of the box here. Don't
spin your wheels trying to replicate a key system using Asterisk. you
might approximate it, but as you have found out, it's a lot of work
for only so-so functionality. Instead, focus on the users' complaints
about the way your install is set up and then streamline it and
redesign to take those complaints into account. You can't provide
them with the same thing, but if you provide them with a reasonably
easy interface and better features, you'll get buy in.
Just some thoughts, hopefully constructive.
Tom
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
