SameTyme

What problem did SameTyme solve?

SameTyme solved two different problems:

  1. Patients visiting a consulting doctor (think of a small to mid sized clinic) always end up waiting in a queue (avg 60-120 minutes)
    • (a) online appointment booking services (such as Practo.com) guarantee only an appointment, not actual fulfilment
    • (b) patients who walk in to a clinic often have no clue in advance how long they have to wait
  2. Consulting doctors offering online appointments had to constantly manage two queues of patients (thereby depending on an attendant):
    • (a) patients who walked in directly for consultation
    • (b) patients who took online appointments for a specific time

How did SameTyme solve the problem?

SameTyme used a combination of hardware and software to offer a single queue for patients and the consulting doctor.

For patients

It did not matter whether a patient booked an appointment online or whether she walked straight in to a clinic: She always got a token number (not appointment time) indicating her sequence in the queue. The token number had an accompanying ETA. Patients who booked an appointment online got an SMS with the token number. Patients who walked in directly to a clinic could get a token at the push of a button. For all patients at the clinic, a large display indicated the current ongoing token.

Large display and token issuing system at a clinic.
Sample token issued to a walk in patient.

Patients who took online appointments got real time status updates as the queue moved. For example, if your token number was 5, you would get SMS updates as soon as the token number turned 3 and 4. Patients could also see the current live status of the queue online without having to wait at the clinic.

Screenshot of the website showing live status at a clinic.

For doctors

A doctor had a small display and button adjacent to her table. The display indicated what the current token number is and what the last token number is. Pushing the button moved the queue up to the next token. A doctor no longer had to worry whether the patient took an online appointment or walked in. She simply managed the queue using the button.

Small display next to a doctor’s desk. This display indicates that the current token number is 2 and the last token number is 7.

See the pitch doc we used before all this was built out.

What technologies were used to build SameTyme?

For the website and backend, we used AngularJS and NodeJS. We migrated from NodeJS to Scala as the number of appointments & doctors increased. Firebase was the data store.

For the hardware, we used Arduino Uno with a bunch of shields: A WiFi shield from SparkFun, two Sector 7 display shields, buttons, a buzzer for sound (when the counter changes) and a thermal printer. We used Arduino Uno’s in-built EEPROM memory as local storage. The Arduino Uno is certified for 100K writes, but in our experience we noticed writes up 250K working fine.

For the mobile app, we used the cross platform app development framework Ionic.

For monitoring, we used uptime robot.

What is inside the box!

Who worked on SameTyme?

Bharathi, Siva and Swaroop.

Did SameTyme scale?

No. SameTyme fulfilled 20K+ bookings between 3 doctors (2 in Bangalore and 1 in Hyderabad). Almost every patient who took an online appointment, and experienced real time updates, came back within a month to book another online appointment. Wish we had measured NPS scores!!

Out of six doctors we pitched to, four ended up placing orders. To some extent, this indicated a demand (at least amongst a few doctors).

We struggled to fulfil orders for the hardware and also maintain the hardware due to the lead time and man power involved. The lead time to get the hardware ready for each order was two weeks (one week for the parts to arrive and one week for us to assemble and setup).