cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Mayor / Maire

Re: Developer’s Blog: Learnings from customer testing sessions


@z10user4 wrote:

All I know is that no one likes to be completely in the dark as to where they stand.


@z10user4 amen!!!!!


>>> ALERT: I am not a moderator. For account or activation assistance, please click here.
Oracle

Re: Developer’s Blog: Learnings from customer testing sessions

@srlawren  i dont disagree with you i believe i started that sentence or possibly,  as kind of a last ditch method of getting some info from the abyss, since the eta accoriding to alan was a in the near future (and we all know what that means).  

 

I would love to see something on the lines of: working on messages submitted day x at time y toronto time.  working on tickets from 48 hours ago. again assuming FIFO

 

in the end i think the ticket number is possibly red herring, if the form works in getting accounts verrified and all the needed info, then i think the effecincy of the process will improve.

 

how failed activations will work, or people who did not setup a selfserve account with the form will be interesting

Mayor / Maire

Re: Developer’s Blog: Learnings from customer testing sessions


@mimmo wrote:

@Alan_K  another thing that i believe would be benificial is to have a proper understanding how the backend of the private messages works:

 <trimmed the details for brevity>

 

@mimmo this is a great ask, it would sure help reduce the opacity of the current (and by extension: near-future) process


>>> ALERT: I am not a moderator. For account or activation assistance, please click here.
Model Citizen / Citoyen Modèle

Re: Developer’s Blog: Learnings from customer testing sessions

Hope to see more updates like this in the near future!

Deputy Mayor / Adjoint au Maire

Re: Developer’s Blog: Learnings from customer testing sessions

Next?  U.S. roaming text bug after arriving home, suspended account on reneway day, and fix 2 step procdure of add-on purchase?

Oracle

Re: Developer’s Blog: Learnings from customer testing sessions

The lively discussion here is great.  The only thing that has been mentioned which I don't agree with is removing the current private message method of moderator team interaction.  My biggest concern with identity verification is the lack of a fail safe option.  If an existing customer forgot their password, cannot get into the self serve to pay up on a suspended account would have a real problem on their hands.  Likewise the customer trying to activate and need moderator team assistance isn't going to be able to navigate the identity verification.  For all the faults with the current interaction system, it can handle all situations.  Unless a replacement is found, the current model has to be retained as a backup.  

Oracle

Re: Developer’s Blog: Learnings from customer testing sessions

@will13am  that can be handled via the smart form. Assuming it's smart enough.  It should be designed is a way to handle all situations. Ie activation errors (where no self serve account is created). It should/could still submit even without verification. 

 

The reason I suggested removing private messages as a primary/initial contact method was so that everyone gets a ticket number everyone goes through same process. And this avoids having multiple access points for help.

 

This is also assuming there is a way to access the form without Simon. 

Deputy Mayor / Adjoint au Maire

Re: Developer’s Blog: Learnings from customer testing sessions


@srlawren wrote:

@mimmo wrote:

@srlawren  if you get a ticket number of 500 and then find out ticket 400 was worked on. And later find ticket 425 is worked on you know roughly when yours will get addressed.  Assuming  answered in order received 


@mimmo I mean, sure.  But let's say you're on hold with your home TV/internet provider.  You get in the queue, and they say "estimated wait time is approximately 85 minutes", they don't say "you are customer 123 in line, and we are currently assisting customer 62".  Unless you know an average time per customer (ticket velocity) and how many agents are working (team velocity), you really have no way to know what your position in the queue might translate to in reality.  For example, maybe you're number 201 and they're on number 199, so you think, any second now!...but then it turns out that each request actually takes an hour and a half....


True but, what about this situation. If we assume they process the tickets in the order they arrive (First in First out) and you ticket number is 1701 and they are currenly working on ticket 1686 you know their likely will be some wait. After a few days of waiting you check back to see your progress and the display says they are now working on ticket 1742 then you know that either your ticket was missed, still being processed by higher level, or completed. Checking your ticket status flag Ex. Open, Closed, Under Review, Escalated, Awaiting User Response etc. would let you know if you need to take any actions yourself. So if your ticket is still sitting in the Open status and they are far past yours in the queue odds are the Mod who got your ticket got distracted and moved on accidentally without doing anything.

The only complication I can see with the spot in queue isn't exactly processing time based, it's the fact that multiple tickets can be actioned at once due to there being multiple mods. If Mod A has 1699, Mod B has 1700, Mod C has 1701 and Mod B finishes their 1700 ticket, they would move on to 1702 which may be a redundant ticket because someone was spam happy and didn't get a response within 5 seconds so they sent another identical ticket. Since Mod B recognized the ticket as being the same as 1700, they close that ticket and go on to 1703. This would imply that 1704 is next (which it truly is) but also that 1699 is likely done  (which it is not). So now the person who issued 1699 might be watching the queue counter due to knowing theirs is being worked on and with the queue rapidly advancing beyond their number might pull the trigger and create ticket 1776 for the same topic as 1699 despite it being actively worked on at the moment. 

I likely didn't explain that all that well, but I tired. I am so tired. 

Model Citizen / Citoyen Modèle

Re: Developer’s Blog: Learnings from customer testing sessions

I'm wondering how often problems are fixed by the time a Moderator looks at the original message/ticket? Will there be a way that the client can mark the ticket as completed so that the Moderators don't spend unnessary time should passing time or the community be able to solve the issue?

Good Citizen / Bon Citoyen

Re: Developer’s Blog: Learnings from customer testing sessions

Exciting times indeed.

 

I look forward these new tools that will be soon available to the "public". Go SIMon!

 

Let us know if we can further help/test in any way.