Choosing an attendant console for Microsoft Lync

Traditionally the most common and most popular way to create an attendant console for a given platform was to use a standard like CTI or SIP.  The program would emulate a CTI route point, or SIP endpoint and answer an incoming call much like a phone on the system.  This approach has several advantages.  Almost every modern phone system today can talk either SIP or CTI, so you immediately have compatibility on almost any phone system.  Since you are essentially becoming a phone or phone server at this point, the features you develop would likely work universally from system to system.  To start the developer would develop some sort of user interface that an operator/receptionist could understand.   From there it was up to the developer to create the basic functions, answer, hang-up, hold, resume, transfer, etc.  From here you could expand your feature set to combine a myriad of SIP functions to create things like call parking, some sort of queue, etc.  This approach does have a few drawbacks too.  Since you are in possession of the call, you have the ability to drop or lose it if your software misbehaves and you don't have a proper fallback mechanism in the phone system.  You are also responsible for music on hold, and dealing with whatever queue related functions you have created.   In Microsoft Lync you are left with another, rather large disadvantage to using this approach.  To say Lync is just a phone system is like comparing your car to a chair.  Yes you can sit in/on both with a similar result.  It's fairly obvious that your car has many features your chair does not.  Lync is no different, while it does the telephony end of a typical phone system, it brings many more collaboration features with it, and on almost any device you would be using.



As a developer Lync comes with 4 major SDKs at your disposal, giving you complete control on the front end client and the back end server.  This is a HUGE difference compared to what developers typically see on other UC platforms.  So it begs the question, "Does the traditional UC development model fit Lync?"  I believe the answer is no.  Does a receptionist do the same job on a Lync system as she would on a traditional pbx?  The answer may largely be yes, but would said operator not benefit from being able to seamlessly use instant messaging, audio conferencing, call park (orbit), native response group (queue) monitoring, recording, transfer to voicemail, calendar visibility, and a whole host of other Lync specific call control and look up functions?  I whole heartedly believe the answer to this question is YES, and that answer of yes fundamentally requires a different approach be taken to the attendant console in regards to Microsoft Lync.

SDK Links
http://msdn.microsoft.com/library/office/jj162980.aspx

Doug Routledge, C# Lync, SQL, Exchange, UC Developer