API comment (Long Post!)
Hi,
This is a great product. Especially the Exchange Integration, perfect for Microsoft Small Business Server 2008 customers, when it arrives.
I think you should definitely have an API or set of APIs as an ambition, and I also think it will get you more paying customers. But maybe I'm wrong; however it would certainly get us more customers as a reseller. Maybe it shouldn't be top priority first off; call handling is definitely priority number one at the moment for me. Wasn't their some talk of TAPI support? It's a lousy API but at least it's standard. The trouble is no one ever implements all of it. I've also looked at CSTA, which I hadn’t heard of, it’s a bit dense, it would be great if you could write some good docs for this if this is the way you go. You could just write your own API specification and just keep it simple and elegant.
One of the great benefits of the PC environment over the proprietary systems like Nortel, Avaya etc. is that it is (or can be) more open. The trouble with the ultimate openness of open source is that it just isn't easy enough to use. In open source there is no real API, there's no line between the inside of the system and the outside of the system, you can just hack in at any level. What would be nice in 3CX sip server is a clean well documented API we can use to interact with the system, not fiddle internally with how it works, or produce some horrible hybrid hack. I take the point that the software should be designed to work well without people having to fiddle with it, but a good API does not fiddle, it is an interface every bit as designed as the Human Interface.
This is what the APIs should be for IMHO.
1. Call control/monitoring per user
It should be possible for API users to program an application that sits on a user’s desktop and can control their handset. Much like 3CX Call Assistant or Avaya IP Office Phone Manager does, but customised to the specific application. The API can then be used to integrate with CRM systems so that for example whenever you answer a call a list of possible contacts appears (using the CLI) so you can more easily write and file an attendance note for the call. It would be even better if the call could be recorded and added to the customer record as well. What about customers being dialled by clicking a button in the application? If the operative can see what the busy or away status of others in the organisation from his or her LOB application then, when a customer service call becomes a support call, they can transfer the call to the individual who can best help. Extension status reporting is not well suited to a SOAP method, to get a busy lamp field you might be better off with a network broadcast. Or maybe not. Out of interest how does the call assistant do it?
2. Call control/monitoring for whole system
This is less important, but still great to have. It should be possible for the system to do things to calls system wide. When a call comes in an event can be fired. Then using the API we can do things like ask for the customer’s account number and store it against the call, presenting it to the operative when they answer. Or what about looking the CLI up in a database and displaying the customer’s name against the call, so that it appears on the hard phones and on the Call Assistant (or replacement). How about looking up the caller on the database and trying first to connect them to the last person they spoke to, before falling back to the hunt group. All things you could do with an API, with a handful of methods.
3. Call recording and logging
If you record call and/or log calls you need some means of accessing the recordings and call records. Call recordings could be bundled off into a directory with their filename organised according to schema. Better they could be named with GUIDs and call records could contain 'links' to them. The call records need some form of API. You could get them with SOAP calls, or with ODBC, they could be stored in CSV files in a nominated location (they are with most systems, as so called CDRs which is a not very standardised format), or maybe XML files. Once you have access to them through some sort of API (even if the API is just a file path, CSV schema and file naming schema) they can manipulated to see how soon call are being answered, which operative is answering the most calls etc. by custom or boxed software.
I do not think there is any need for a configuration API. In fact I think you're better off without one. That crosses the line.
I use .NET as well BTW. I hope these are good ideas and I'm not just being annoying...
Chris.
And, if it is reasonable, we'll provide such API. See, I just can not do "some API". I can do "specific API"
