Humble beginnings

I started my career in product as an intern in Sabbar. To describe my journey with Sabbar as truthfully as I can, I'll need to tell you all about the projects I've worked on during my time there.

My tasks consisted of but were not limited to ideating, analysing, designing using sketch, arabic copywriting and communicating with engineering. This has enabled me to take on so many different roles and gave me so many different experiences outside of my comfy little comfort zone.

‍

During my time with Sabbar, I took on many projects and designed features that would help save our internal team's time. Let's talk about these features now, shall we?

‍

🤖 Taking out the human aspect

You might me asking, what is Sabbar? Sabbar is a start up that offers a link between retail stores, restaurants, cafes...etc and hourly workers. So, if lets say your neighbourhood Mcdonald's was short staffed, Sabbar would be able to save the day by bringing in an hourly worker that works designated hours.

To give a little context, Sabbar had three types of target users:

• Giggers → Sabbar app users that use the app to apply for shifts
• Partners → Businesses that request giggers to work for shifts
• Operations team → users of our backend platform that has been mentioned earlier

Each of these target users, required their own platforms. Giggers had their Giggers mobile app (GMA for short), Partners had their Partners mobile app (PMA for short) and our operations team had their backoffice website (affectionately called BO).

Most of the work I did was for the back office, to ease the manual part of the operations on the operations team.

‍

🚑 Introducing the emergency fulfilment system

Initially, the operations team's process for recruiting giggers for shifts was very very manual. If a gigger cancels on their shift last minute (which often conveniently happened outside working hours), our team members would have to go into the back office and call all the giggers they were in contact with to find someone to cover the shift for the partner. They would also frantically send notifications to the GMA in order to get giggers to apply to the shift. If they could find a gigger that could cover the shift, the team members would then assign to the shift using our back office platform.

One of my main goals during my internship was to help make tasks a little easier for our operations team. A way I could achieve this goal was by designing a system that would automatically select giggers if the assigned gigger has canceled a shift last minute.

It seems like a simple concept on paper but it took a lot of effort. I spent time getting to know how the operations team worked, their behaviour and even shadowed some team members to see how they would handle these emergency situations. After learning more about the process, I designed the logical flow which the system would follow and writing use cases and user stories for what we called emergency fulfilment system.

‍

‍

So, how would this work? The emergency automation system would follow a few rules depending on how many hours there is before the shift would start.

The operations team had defined an emergency shift as an unfulfilled shift that is happening in 6 hours or less. After further conversations with the team, we decided to split our definition of emergency shift into two

‍

🚨 Emergency level 1:

• Shifts happening 6 hours to 2 hours before shift start time.
• Sends a notification to giggers through the GMA
• Wait 20% of the time remaining until the shift starts
• The system then assigns top applicant (based on a scoring system implemented) in the waiting list

‍

🚨 Emergency level 2:

• Shift happening 1 hour before shift start time or when the shift is in progress and the gigger is a no show
• Checks whether 4 hours are left in the duration of the shift
• Moves shift start time by one hour
• Sends a notification to giggers through the GMA
• The system will then wait 10 minutes
• The system then assigns top applicant (based on a scoring system implemented) in the waiting list

‍

The system would stop trying to fulfil the shift on two conditions

1. If there is less than or 4 hours left to the shift, the system would send a slack alert to alert the operations team.
2. If the shift did not get any applications, the system would wait until 1 hour is remaining in the shift and 4 hours or less are left in the shift's duration before alerting the team.

‍

❤️ Favourite and experienced giggers

I also created a favourite giggers feature, where the operations team would be able to add giggers to a partner's favourites list (based on branch). They are always given priority over experienced (giggers that have worked a defined number of hours with the partner) and other giggers. So, they are assigned automatically to shifts they apply to.

‍

‍

As for experienced giggers, the operations team are now able to specify if they could give priority to experienced giggers. They would be able to add the amount of hours as a requirement when creating a shift in the back office.

‍

‍

‍

🧠 Moving into bigger ideas: Normal fulfilment system

Even after designing the emergency fulfilment system, we decided it was not enough. We still needed to further remove the manual aspect of fulfilling the shifts. So, we decided to introduce, the normal fulfilment system in all its greatness.

‍

The reasons to validate going through with this project, were simple:

• The fulfilment process is still very manual
• We need to help ease the load of fulfilment from our operations team
• Automating the fulfilment process would help us scale up the demand
• We need to open up capacity within the team

‍

This project consisted of two systems

‍

✅ Normal Fulfilment

• The system will handle fulfilment for shifts with giggers that match the specified requirement
• The system will attempt to fulfill at 2pm and 9 pm everyday
• The system will attempt to fulfill shifts that are happening 72 hours to 6 hours before the shift
• The system will assign the top applicants in the waiting list

‍

In order to combat special circumstances, we also enabled the capability to turn off the system from fulfilling shifts if needed.

‍

‍

🏊 Pool assignment

A pool in this sense is basically a group of giggers. Some partners required training before giggers could attend shifts. So, the team would often add giggers that have completed training into a pool or a group and only show the shifts to these giggers.

• The system will check if a pool is part of the requirement
• The system will automatically assign any gigger under the pool that applies to a shift

** Note: In the case that a favourite gigger applies, they'll also be automatically assigned to the shift. Since favourite giggers are especially requested giggers from our partners.

‍

🙅 Striking system

So, since we left the fulfilment of sessions to the system, we needed a way to make sure that the giggers were not abusing the system but also we did not want the process to be too manual.

To define it:

It is a structured disciplinary approach targeted to improve giggers behavior, it is used to help giggers meet goals which they may be struggling to meet and stimulate positive work habits.

‍

The striking system carries different weights and gives a different number of strikes based on the severity of the action

• Cancelation 24 hours before the shift: ⚡️
• Repeated Cancelations: ⚡️
• Not showing up to the shift: ⚡️⚡️⚡️
• Attendance Unreliability (Late arrival, early leave): ⚡️

If the gigger gets three strikes, they are suspended. The gigger can get suspended twice before being completely banned from the platform.

‍

Giggers would be able to undo strikes in the following ways:

• When the gigger works 5 shifts without late arrival or early leave, they would be able to undo 1 strike.

** Note: The counter is re set to 5 if the gigger does not complete 5 shifts consecutively

To be able to combat special circumstances, we also gave the operations team the capability to remove strikes from the back office.

‍

🧲 Pulling businesses in

‍

Another initiative that I worked on was to design a calculator that could calculate the employment costs for full time/part time vs hourly flexible workers.

In order to gather information, I had to work with our finance department in order to get all the calculations down. These calculations would serve as the backbone to the design. This was an opportunity for me to learn more about hiring and costs behind things like social insurance, recruitment etc.

This project was math, content and design heavy. The design and content of the page needed to be as clear as possible, this included arabic content as we were serving a majority arabic speaking population. The calculator needed a responsive design that could work on all screen sizes.

‍

‍

What was particularly challenging was the fact that this task involved the business side of things. Throughout my time at Sabbar and until that point, I was mainly working on our back office platform and the Sabbar app. So, it was definitely very interesting to work on something new.

‍

‍

Humble endings

As my time with Sabbar ended, I realised that the projects that I have worked on has left a mark. These projects helped me build my system design skills, as well as my communication skills (as we had to communicate the new features to the operations team, as well as, engineering team).

If you want to read more about this experience, you can read my internship blog post on Sabbar's website.