Generic CTI: additional fields like displayName; easier workflow for creating tickets?

[martin.von.wittich]

Hi, in response to: Feature discussion: Extend CTI integration (GitHub)

I quickly hacked a Perl script together that can push our queue calls from Asterisk to Zammad’s CTI interface; the results look promising. I have the following two suggestions though:

• Our Asterisk uses a AGI script that queries our CRM to map CALLERID(num) to a proper CALLERID(name):

  • If I call from my mobile phone number +49 176 xxxxx, it sets the name to “von Wittich, Martin (IServ GmbH)”.
  • If a German landline number calls, it will additionally postfix the name with “[City]”, e.g. the name for +49 531 xxxxxxx will be postfixed “[Braunschweig]”. This means that even numbers that can’t be resolved in our CRM will have some meaningful information for our agents.

  It would be nice if Zammad would support an additional field displayName (or something like that) in the newCall event so I could hand this information over to Zammad. It would probably only be useful in the phone overview and not for creating customers, but it should greatly help agents identify calls when Zammad doesn’t know the customer yet.

  Maybe even additional fields like firstname, lastname, email, … might be useful? Then Zammad could receive the necessary information for creating new customers directly from the CTI interface, provided that the PBX can supply it of course.

• Creating tickets from phone calls seems to be needlessly complicated: I have to click on the caller, then on small action button on the top right, and then on “New Ticket”. That’s IMO pretty hidden. I think a “Create Ticket” button directly in the phone overview would improve it.

[MrGeneration]

I like that idea, my telephone does the same as well.

[martini]

Hello @martin.von.wittich

• Our Asterisk uses a AGI script that queries our CRM to map CALLERID(num) to a proper CALLERID(name) :
  • If I call from my mobile phone number +49 176 xxxxx, it sets the name to “von Wittich, Martin (IServ GmbH)”.
  • If a German landline number calls, it will additionally postfix the name with “[City]”, e.g. the name for +49 531 xxxxxxx will be postfixed “[Braunschweig]”. This means that even numbers that can’t be resolved in our CRM will have some meaningful information for our agents.

Would it be put the customer name to user[] this would be the realname shown in the UI for the caller log. See also in curl example of newCall in https://docs.zammad.org/en/latest/cti-api-push.html

To mix it up in one parameter would be not fine IMO.

• Creating tickets from phone calls seems to be needlessly complicated: I have to click on the caller, then on small action button on the top right, and then on “New Ticket”. That’s IMO pretty hidden. I think a “Create Ticket” button directly in the phone overview would improve it.

I can follow your description. Any more actions needed at this stage?

We have a rule, if it fits for 80% of Zammad users it’s good for the product. So my questions to others, is anybody out there which is supporting this idea?

Thanks!

-Martin

[martin.von.wittich]

Would it be put the customer name to user[] this would be the realname shown in the UI for the caller log. See also in curl example of newCall in https://docs.zammad.org/en/latest/cti-api-push.html

Hm, but for direction=in, user[] seems to be the name of the user that is being called, not for the calling user:

It is the name of the calling user when direction is “out”, or of the users receiving the call when direction is “in”.

Though I realize now I could have been more clear about this in my original posting: I’m currently only using direction=in. I’ve uploaded my Perl script as a gist to show how it currently works: https://gist.github.com/martinvonwittich/ad2a5febb67c276848029904d53a00ed

The script connects via AMI to Asterisk and listens for Queue events (haven’t bothered yet to add support for normal incoming or outgoing calls), and whenever it encounters the respective events, it will asynchronously push these via HTTPS to Zammad.

Nonetheless I tried to add user[] to the newCall request to try it:

  if ($event->{Event} eq "QueueCallerJoin")
  {
    post_zammad {
        event => "newCall",
        from => $event->{CallerIDNum},
        to => $event->{Queue},
        direction => "in",
        callId => $event->{Uniqueid},
        user => [$event->{CallerIDName}], # <-- here
      };
  }

But as expected, it’s now the wrong way around - it shows:

From	To	…
+49 176 xxxxxxxx	von Wittich, Martin (IServ GmbH)	…

Instead of

From	To	…
von Wittich, Martin (IServ GmbH) +49 176 xxxxxxxx	agent.that.took.the.call	…

So the need for a way to pass this info properly to Zammad IMO remains.

I can follow your description. Any more actions needed at this stage?

Full disclosure: I have no idea

Currently only our department head and I are evaluating Zammad, and at this point we’re mostly playing around, we haven’t used it productively yet. I expect that the CTI features will be more relevant to our sales staff than to our support staff (we supporters seldom create phone tickets, we usually just ask our customers to send a mail instead), and I just thought “hm, creating phone tickets from the call history seems a bit unintuitive” ^^

[martini]

Hm, but for direction=in, user[] seems to be the name of the user that is being called, not for the calling user:

Now I got it. That makes sens. In the past we did not get more infos from the BPX (just there caller id). But your use case is very good. -> We will add a parameter for that. I’ll post an update here.

For actions I wait until some more feedback for now.

Merry christmas!

-Martin

[jampy]

I second to what Martin von Wittich requested.

I’m playing around with the Generic CTI, too (in my case with the popular 3CX PBX) and I’m not sure if I’m missing something or if the CTI is really intended to work the way I’m experiencing.

• When I send the “newCall” event, it seems that the only reaction is the Browser notification (out of the window) and a new entry in the “phone” tab list. I would have expected that a automatic popup would come up showing user information and offering actions. As it seems, when a call comes in, I need to manually click on the “phone” tab, locate the entry in the list and hover the mouse over a tiny spot in the list to get more information. That’s a lot of wasted time during a call. Is this by design or am I missing something?
• What’s the use of the “user[]” field in the API? I expected that it would be used as a filter so that the call shows up only for matching agents, but it rather seems just to be a “dumb” text field passed to the phone calls list?
• Whats the “queue” field in the Push API? Could not understand what it does.

As for the workflow / actions, I’d like to give you some additional feedback:

• First of all, it would be a huuuuuge benefit if Zammad could offer better assistance for agents when a phone call comes in. When the phone of an agent rings, it would be ideal if the agent immediately (without any manual action) sees information about the user including open/recent tickets and so on. The current API could already allow that if the user[] field is actually mapped to agents.
• During the call, it would be great to have the possibility to create a new ticket with a click, without having to create a new user manually (although that would require a “merge user” functionality, that’s currently missing).
• Similarly, it should be possible to add a note to an existing ticket.

For reference, see the workflow in Freshdesk/Freshphone (the UX has become terrible since they made “Freshphone” a separate product, but you get the idea):

A new phone call coms in: you see the name of the caller and the queue name immediately.

During the call: you can click on the user name to open it’s profile and you see it’s recent tickets (clickable, of course):

There is an action to create a new ticket or to add a note to an existing ticket. Note that you can choose this while the call is still going on, the ticket is created/enhanced later…

Either way you can write notes (during the call) that will be added to the ticket at the end of the call:

Unfortunately it’s still too many clicks(!) to create a ticket for me (it was better in the older interface), but it shows well what an agent should be able to do, when he answers phone calls.

I’m pretty convinced that such a functionality could be added easily to Zammad.

Actually the main reason why we’re considering moving from Freshdesk/Freshphone/Freshchat to Zammad is a hopefully better phone integration and the much, much faster and nicer UI.

PS: Actually Freshdesk also offers the possibility to store the call recording along with the ticket, but that cold be slightly more complicated.

[MrGeneration]

First of all, it would be a huuuuuge benefit if Zammad could offer better assistance for agents when a phone call comes in. When the phone of an agent rings , it would be ideal if the agent immediately (without any manual action) sees information about the user including open/recent tickets and so on. The current API could already allow that if the user[] field is actually mapped to agents.

The Browser notification already shows the caller name, if Zammad knows the caller.
If you click on the users name within the caller log, you’ll get an overview of all users tickets and (if applicable) his organisation.

Personally, as someone that works with this function every day, I’d dislike popups (I really hate it when something begins to jump on my screen). At Zammad we have a group number, so this would mean that every agent would get that popup, no matter if he will (or can) pick up at that moment.

I think it’s better to open a new screen (with whatever information) on establishing the call (in my opinion, if you really need this). This would require Zammad to know the end users extension. But that would be required on the other solution as well.

Just my 2 Cents :>

[jampy]

Of course there are different opinions, no doubt about that.

It would be great if Zammad would allow certain behavior and let the agent/sysadmin decide what should happen.

We too are handling many calls per day and thinking about having to do multiple clicks for each call makes me feel uncomfortable.

Popups can be designed in different ways - even less invasive. I would even sacrifice a part of the left sidebar for this functionality (permanently showing phone status). Remember that also the OP would like a “less complicated” workflow (although he was not specifically talking about popups)

For me, a new screen would be horrible because during the call I want to review the customer’s tickets, update it’s details or whatever.

At Zammad we have a group number, so this would mean that every agent would get that popup, no matter if he will (or can) pick up at that moment.

Exactly my situation. However, agents can log in/log out the group call / queue or set themselves to DND (do not disturb). All that controls if their specific extension will ring on a specific call coming in or not. If it does, I think it would be useful to provide information as quickly and easily as possible.

I understand that the Zammad CTI API is currently agent agnostic. At least the API itself could be easily enhanced in this regard, IMHO.

This would require Zammad to know the end users extension. But that would be required on the other solution as well.

By “end user” you mean the agent? Not if the PBX does the extension => agent mapping. I originally thought that’s what “user[]” is for, but it’s apparently not (still wondering what’s it’s use as described in my last post).

What’s the “other solution” you’re talking about?

Cheers

[MrGeneration]

By “end user” you mean the agent? Not if the PBX does the extension => agent mapping. I originally thought that’s what “user[]” is for, but it’s apparently not (still wondering what’s it’s use as described in my last post).

What’s the “other solution” you’re talking about?

Correct, by end user I meant agent in this case.
The other solution I was referring to is the knowledge of the extension of your agent.

I don’t know PBX and co well enough to know how the mapping is done the best. I currently think that mapping inside of Zammad would be better, because we could cover all phone systems (aka I don’t know if sipgate and placetel do that mapping in a way we could cleanly use).

Also not sure about the DND state being supplied by all devices cleanly.
In my case were I could test this is sipgate: Sipgate does not show it’s presence display when I enter my hardware phone into DND-Mode. The phone is configured exactly after what sipgate wants.

In that case Zammad would always display the phone calling in a more present way as it does at the moment. (That’s the main thing I actually wanted to come to, sorry for taking so long haha)

[jampy]

To clarify about the DND state: I didn’t mean that the state is communicated to Zammad. Instead, the phone (extension) simply i not considered when a call comes in.

Say you have 10 agents on a call queue / ring group and 3 of them are in DND*. Only 7 phones will ring (if configured “ring all”) or the DND phones will be skipped (if round robin or something).

*) 3CX, for example, has a mechanism to log in / log out a queue manually (an agent can choose to accept calls or not). Things get even more interesting when (per-agent) business hours come into play… I guess all bigger PBX systems have similar mechanisms.

Anyway, in the end the current Zammad CTI design seems to be tailored around the main number (the ring group) and not the extension. That’s decision is probably worth discussing in the first place (all the other problems are details that depend on that decision).

IMHO, the Zammad UI is agent-centric and that should be respected by the phone integration as well.

FYI, In our specific case we’re approaching a different route now - encapsulating Zammad in a Electron shell and adding a specific interface that acts as a mediator between the PBX and Zammad, automating the Zammad UI to create tickets and so on. First tests look promising. It even allows us to integrate the 3CX webclient all in the same window. The Zammad CTI API will be used as a simple call log, if at all.

Cheers

[martin.von.wittich]

I’ve got another very minor wish for the CTI interface: I would welcome it if the CSS property user-select: none could be removed from the caller names (<span class="user-popover">) because it needlessly prevents agents from copying intact caller log excerpts e.g. into a company chat.

EDIT: moved to separate thread.

[MrGeneration]

I think this should be an independet FR, because it’s kinda off the original topic and might be lost when choosing to work on this. Just wanna make sure that this doesn’t happen.