Exploring Options


A few months ago I ventured into taking all of what I learned from Web Development to create a digital replacement for a ticketing system we have at work.

Exploring Options was created about 5 years ago to compensate for the limitations in our salon software's waitlist. The built-in feature was more of a nuisance because notifications of waitlisted guests would appear in the middle of scheduling other guest appointments as well as providing only one date instance for every client time frame. This meant a client who was available all week at different times had to be added for each differing time opportunity. The list grew and the pop-ups were more cumbersome as there was no self regulated trimming of expired opportunities. Being in a busy salon is a blessing and a testament to the artists ability to bring skillful work so it generated a lot of waitlisted clients clamoring to get in.

This improvement was all done by hand on 4x5 pieces of paper. old. school.

I never imagined how much this paper ticketing system performed better than the software we were likely paying a hefty price for.
It allowed us to connect more seamlessly with our artists by streamline their individual schedules and opportunities. Guests who could be squeezed in gave artists the opportunity to maximize their books, thus increasing revenue potential for everyone involved. We were able to have conversations around each opportunity and clients were grateful to be presented with so many at times. I would say we likely created a few positive "monsters" now as guests who couldn't get in quickly enough now bypass our option for a waitlist and prefer we "pass on a message" to their artist. A nice problem for any popular salon professional.

But like anything in life, change is the only constant.

I took the best parts of our paper system and challenged myself to create a similar product in digital form. What I learned is systems need to be broken down and separated, measured, tested and sometimes burned to the ground in order to make room for an improved user experience. In my first "I feel ok putting this in the hands of users" iteration, I wanted to minimize the greatest threat to paper tickets. The lack of accountability and follow up.

When a paper-ticket returns to a guest services team member with a solution it can sadly go missing at times. Somewhere during the handoff a link gets broken and we lose our bearing. Was the guest called and if so, when? Did they change their mind on something? How many times did we call if any? Could we leave a message? or the worst of them all... the paper was accidentally thrown out because one team member thought someone else had taken care of it all. This I believed was the largest issue to tackle above any super cool search, sorting, displaying or updating feature in this web-app. I would have to create something which keeps every update connected and all parties involved informed on status changes.

At first I thought to create a status table where by each request would be handed off to other team members and everyone could see the connecting thread of each request as it traveled person to person. In the end the route taken was to create a conversation model to get everyones input on what was going on as updates occurred. Instead of tracking the hand off from team member to team member in a database table it would all be spelled out in the entire comment thread. Comments contain meaning.

My second task was to make sure a team member had a decent overall view of their requests so I began to outline the user-dashboard. I leveraged a sidebar layout with a scrollable central view housing requests all sorted and separated by task-type and status. Incoming requests would be separated from outgoing requests and each would have more specificity for being 'active' or 'completed'. I utilized Bootstrap's TAB capabilities to switch data for each request type and status in the view while also displaying a graph for completed requests through the Chartkick gem. On my right sidebar I figured to display requests which are due in 7 days by default. I introduced a helper method to sort each request availability and present only those which were about to expire, in order of expiration, separated by request type. I got to say, I really enjoyed having to break down the ruby code necessary to go from point A to point B. Thank you google and stack overflow!

I learned a great deal about myself as a developer, project manager and UX designer and like my usual self I already have a few corrections and improvements I'd like to implement. The party never stops!

What I hope to add "later" later, not "right-now" right now:
- Notifications so everyone can maintain an ear on the pulse of every request participated in.
- Search functionality to sort requests.
- Include an option to manage requests for teams/departments keeping everything a bit more tidy than a giant all access free for all.
- When the team improvement is added I'd like to clean up the team page.

Check out my ever-changing code here

Previous Post Next Post