Creating a Form to Capture User Inputs

[RPM]

I'd like to give a group of customer service folks access to an app that will capture some basic information. Essentially a form where they can input an id, topic, and click some buttons to record timestamps at various phases of the call. Ultimately, the goal is to end up writing rows like these to a yxdb for later analysis.

User	Caller	Topic	Call Start	Segment 1	Segment 2	Call End
Sam	Ben	Cancel	11/28/16 12:20 PM	11/28/16 12:24 PM	11/28/16 12:30 PM	11/28/16 12:40 PM
Pam	Jen	Update	11/29/16 1:20 PM	11/29/16 1:22 PM	11/29/16 1:35 PM	11/29/16 1:51 PM

New to apps; from what I've read, it seems this can only be achieved by chaining multiple apps together to capture the different time stamps with each app looking up that record in the yxdb and appending a new timestamp.

Is there a more elegant way to do it in one form? Maybe have checkboxes they can hit to capture the time stamp for start, s1, etc? That way if they accidentally hit it, they can toggle to regenerate?

Or is there a way to generate a temp output on the screen that looks like that and then write the whole row to the yxdb at the end?

Appreciate any help; thanks in advance.

[MarqueeCrew]

@RPM,

You've got more challenges than you might think.  Suppose you have 100 operators clicking through your app simultaneously.  You're going to want to have many inserts.  I think that a database (normalized) solution is what will be called for.  You can summarize the data later in the process.

Step 0:  Assign a GUID (Global Unique IDentifier) to the event/call.

Step 1:  Lookup incoming caller

Step 2:  Create Insert (GUID + USER + CALLER + Action + Data + DATE/TIMESTAMP)

Step 3 - N: Create Insert (GUID + USER + CALLER + Action + Data + DATE/TIMESTAMP)

An action could be Start Call, End Call, Offer, Acceptance, Reject, Close, etcetera.

Data could be topic or information describes the action.

The first part of the application would have GUID and Lookup functions (if available) and then continue to build inserts.  Ultimately, if a "END" function is recorded, the application would close and you could summarize the entries if you wanted or perform that summarization in an administrative function.

These are food for thought.  It is likely that you'll get more ideas posted.

Cheers,

Mark

[RPM]

Thanks for the tips. Still struggling to understand this; if you can clarify a few things..

Step 0 - to create a GUID - is there a way to capture a run count or session from the app itself? Don't know if that is an accessible variable

Step 1 - look up incoming caller - this was meant to just be a text input from the user

Step 2 - create insert (GUID+User+Caller+Action+Data+TimeStamp). We were thinking of using yxdb but that doesn't seem possible now. Do you mean use somthing like sqlite and append rows? 

Step 3 - how are we recapturing the GUID+USER+CALLER...info without reading the sqlite first? There is no other way to pass data between chained apps right?

Would it help if we posted our prototype?

[MarqueeCrew · Accepted solution]

@RPM

I suggest a GUID to create a unique identifier for every set of entries.  Think of it as a record ID.  It is the glue that would allow you to join a call start, call end and as many segments as you want.  Each segment/action would be it's own record.  The application assigns one as you start it and it stays with you through your call.

You can use a text field for the incoming caller.  If you have caller id, then you can put the # in to the phone and lookup the customer.  If you have a customer #, you can use that too.  My concern would be that Gerry, Geri, Jerry or other typo variations could exist and if you want to create a call history, that you'll find yourself wanting to have standardized the customer information when the call was received.

The creation of a YXDB isn't the way to go. You can use SQLite as a solution.  If you PM me with your name, email and phone then maybe we can setup an hour to talk through the project on a WebEx.

Cheers,

Mark

When you design the app, you'll need to consider multiple users updating the database simultaneously.  You'll pass the GUID along the way.

These thoughts are all theoretical.  

[RPM]

Great points. I'll take you up on that offer. Thank you.

[sandeepaon]

Hi Mark,

Thanks for joining our call today on helping on this call center solution. As discussed in today's call we have tried cutting the app names of the dependent apps to two characters to see if that will reduce the Cache key length  and can get rid of the Cache error. But we are still getting the same error after executing the step 8 in the chain.

Also as you mentioned we have created a new chain app with 11 steps, each capturing just a datetimenow stamp. even with this approach we are still not able to pass the step 8. can we check with alteryx to see if there is any limit on the number of apps that can be chained?

Thanks..