SimplQ - What next?

[daltonfury42]

The original idea behind SimplQ when we started it was to be a simple crowd management utility website. Anyone can go to www.simplq.me create and start operating a virtual queue in under 20s.

We have build a nice website that is almost there. It's 90% complete in terms of functionality, and we will slowly and steadily reach 100%.

But no product is a success unless someone uses it. We are still 0% when it comes to adaptation. I have been thinking about this over the last few months, have been talking to people. I see two possibilities of going forward:

Polish and Maintain Existing Site

If we go this route, if someone starts using it, they have to be someone who sees and manages crowd on a daily basis. Rarely do common folk have the need to manage a crowd (they do have to wait in a queue at times). Stick to the core idea, improve and passively develop tiny features around the current product. Passively market to anyone who manages crowd in their day to day life.

Build for business use

If a regular business has to use it, there is a lot of work that is needed to be done. queue management is seldom the priority for the business. It doesn't have the core value addition proposition that would make a regular business, even if they handle crowd, adopt it just for managing queues (happy to be proven wrong). If we are thinking of targeting them, we would have to slowly and steadily develop some other core functionality:

1. Upload menu, let customers pre-order in advance (minor value addition - some businesses "might" find it useful)
2. Accounting, Invoice Generation (Major Value Addition - everyone needs this) (Example: https://www.profitbooks.net/)
3. Inventory management (Major Value Addition)
4. Help track token till order fulfilment (Minor value addition, some businesses "might" find it useful)

    {Queue/Pre-order → Processing → Billing → Done}

(Like a Kanban board, but for processing customers)

5. What else?

This seems like lot of work, and for a while, I want to focus on some personal stuff and spend more weekends doing other things. I will not be able to contribute much in terms of lines of code for at-least a few months.

That being said, if you see some potential in the project, or would like to execute on a feature, feel free to take ownership of the feature.

[mradenovic]

I would probably be able to help with some frontend for a while.

Features that would be easier to implement, and make the product more interesting for the potential business customer:

Persist joined queue status

If a client joins the queue and closes the browser, they will lose the link. For an inexperienced user, this would mean losing its spot in the line. Persist the queues that the client joined and display those when the client comes back.

One queue multiple server/clerk/window

Make it possible for more than one person to work on the same queue. Make it impossible for the clerk to skip the queue, aways offer the oldest waiting token.

Public Display

Public screen to show who is next in line and what clerk to go to.

[mradenovic]

We are still 0% when it comes to adaptation.

My case for simplifying things

In the last couple of weeks I have visited three locations that use some kind of queue management:

• City MD
• Specturm
• Muncan

Based on my observations, I believe that we should simplify things before getting more complicated (it's gonna get worse before it gets better).

The potential client here is Muncan. To adopt the idea, the solution has to be as simple as Specturm's.

• The phone number should not be mandatory. It is a privacy concern, and any serious adopter would be wary of providing his client number to some random website.
• Public display is not mandatory but is super easy to implement, and clients in line like to know what is going on.
• Phone features can be offered once the server security is in place, or if an easy in-house implementation can be done.

Use cases

CityMD

25-18 Queens Plaza S
Queens, NY 11101

Urgent care with multiple locations. Provider of COVID-19 cases.

When a customer gets in the office, the customer signs in with the name and phone number. The customer receives an SMS and can request status thru SMS. At this point, customers can leave and come back when the time comes. The staff will tell approximate wait time.

CityMD:
Welcome to CityMD - Long Island City.
You will receive a return to office message
30 minutes prior to your appointment.
If you'd like an update to your visit,
reply with 'S'. Reply STOP to opt out.

Customer:
S

CityMD:
There are 12 patients ahead of you in line.

Spectrum

37-35 82nd St
Jackson Heights, NY 11372

Spectrum cable company, one of the largest in the region, with multiply stores.

When a customer gets in the store, the customer signs in with the first name and last name initial. The name shows up in the queue on public display. The customer can look around what is on display, watch tv, or just chill in the chair while waiting.

The first available salesperson yells the name from the top of the queue, takes the next customer, and removes the name from the queue.

Muncan

43-09 Broadway
Astoria, NY 11103

Muncan Food Corporation, a butcher with multiple locations. It can be very busy! Busier than the previous two!?

When a customer gets in the store, the customer the number from the tape at the entrance similar to this one. The customer can look around what is on display, if there is any space to do so. Sometimes line extends far outside the store.

The first available salesperson yells the next missing number from the queue, takes the number from the next customer, and puts the number on the top of the queue (Check Spindle).

[daltonfury42]

@mradenovic We should handle this in two fronts:

Business (Not expert)

1. I don't know how big Muncan is or how things are generally done in US, but I am guessing that if they would be interested in using our software, they would want to get into a contract, sign an AMC etc. Are you interested in giving it a try?

2. Convince a smaller business to sign up might be easier. Even an intent to pay for it would do. If we could do that, we would get a strong idea/feature validation, or know what is the next thing we need to build. I am expecting payment directly to you in return for availability and support etc. If it is a feature that he badly wants (I am sure he would want custom branding etc), he might even be willing to pay you to support development?

Tech

Yes, they won't be comfortable giving away phone number of clients to a random website. I think an in-house setup for a fee might be something they would be happy with?

@chalx Has made good progress in this direction, so if ever we get an interested/willing customer, we can get this done.

What do you think?

[mradenovic]

Muncan is small, but even big guys like Spectrum need simple solutions. If you want any adoption it has to be free and simple for the small guy, and the big one, too. The website should be in production and separated from development.

• Free and simple: Sign in with name only and show display for customers should be enough.
• Paid services: Phone support, Custom branding, Multiple window support...
• In house or custom solution: The hardest to sell, but the sky is the limit. there is a lot of competition out there.

[daltonfury42]

The website should be in production and separated from development.

Yes, the frontend currently is. Backend is more stable, so I had stopped the prod server and pointed both dev and main site to single server to save some $$. As soon as we have a serious customer, we can go back to complete isolation between dev and prod.

---

These are all my inexperienced thoughts, I will be more than happy to be proven wrong:

Free and simple: Sign in with name only and show display for customers should be enough.

Agreeing mostly. We might be able to sell it as a simple solution, but I feel it's easier to sell for a fee than for free. If a business is going to adapt it, one thing he is going to look for is how much dependable you are.

If a random guy just walks to a store and sells a software for free, (one of the) last thing the owner wants to do is to train his staff and adapt it, customers start using it, and then find out tomorrow that the website is down and you are not picking up calls.

Either the software/website should have a good reputation / client base, or it should be through a company / contract which the businessman would be happy to get into and pay for.

He would want to pay $$ and have more control, than to take it for free and get screwed later on.

Businessmen think differently - my hypothesis.

Paid services: Phone support, Custom branding, Multiple window support...

Yes, we could have these as paid or free, I am open to both ways.

In house or custom solution: The hardest to sell, but the sky is the limit. there is a lot of competition out there.

Yes.

[mradenovic]

Backend is more stable, so I had stopped the prod server and pointed both dev and main site to single server to save some $$.

Dev server should be easy to run locally. No dev clients should point to production. Local dev environment should be set with .env files.

I feel it's easier to sell for a fee than for free.

I guess that depends on the market. I use WaveApps and Google Workspace for free for business. I pay just for add-on services (if ever).

If a random guy just walks to a store and sells a software for free, (one of the) last thing the owner wants to do is to train his staff and adapt it, customers start using it, and then find out tomorrow that the website is down and you are not picking up calls.

Make it simple, no training needed, no commitment, no guarantee. Maybe throw in some ads to support the server cost. Maybe limit to one queue per customer.

I would say, build a reputation on free and simple, and don't even try to build anything else if you don't have a paying customer or at least some adoption.

[Vishv07]

@daltonfury42 🥺

[daltonfury42]

I will not be able to contribute much in terms of lines of code for at-least a few months.

I'll be around, but want to be more passive. 😝

[promarcussmith]

I want to add 2 points over here for business use.

1. What I have in mind is of providing Queue management engine for different application. Here we would provide required web api's or web api's with UI, so the customer's application can embed it into their existing or new system easily and they don't have much worry about the notifying or sharing or maintaining.

2. Exporting the queue history in different formats such pdf, excel, csv etc.

Let me know what your thoughts on this ?

[daltonfury42]

Exporting the queue history in different formats such pdf, excel, csv etc.

This is a core feature that we should have. In the admin page sidepanel, we have a "Queue History" placeholder which we can use for this.

On clicking this, we can have a Modal in which we can render a table which shows the (Name, Mobile, Join Time, Leaving Time) of people who had visited, and there we can also have an export button.

I think currently backend doesn't return you deleted tokens, we can do that and get this rolling. We could split this into two tasks (1) Display queue history in tabular form (2) Export Data Functionality.

Queue management engine for different application

This is really interesting, it opens up a lot of possibilities for uses. For a start, the easiest thing we could do is to let other website owners add a "Join Queue" button to their page, which would take the user to our join queue page.

We should let the admin configure if he should collect email address of joiners. We could let the admin choose if we should collect mobile number, name or both. (I also have plans to let him set custom fields to ask) Then we should build email alerts for both admin and the joiners.

Admin would also set the URL to which the user is to be redirected once his turn is up.

This is a very similar product: https://queue-it.com/

Is this what you had in mind, or do you have other ideas regarding this. We could plan and take this up.

[promarcussmith]

Yes, it is something like, the organisation such as clinic, Banks etc. they would subscribe to this simplq application and queue infrastructure will be available to them in their application. One way is to provide the back-end service as api's to them, so their UI framework will call the simplq services and other way is providing the UI plugin kind of thing, something, if we need to embed google map, then first we need to subscribe by a google account and request for particular key, then we add canvas some js script to embed and its map data would be available to the hoisted site.

Something like that we need to do. Here the organization has to register with simplq as not an individual but an organization account, and an organization a/c would be provided and there could be some setting such as Max number people to add in queue and many more things would come in picture. This is a rough idea what I have in my mind. Also, data security would also come in picture and many more. 🤐

🤕 I know, this is kind of too much, but if we go step by step, we could achieve this thing. 🥳

PS: when writing this post, an tiny idea 💡 struck my mind, Do we notify the queue member that he is next member or is there something like "notify me when there is 1 member or 2 member ahead of me" and he/she will automatically be notified by the system.

What I have seen is admin can notify, but I am not sure, whether a queue member can add a "notify me before __ member"
If this is not present, we can include this as well.

[daltonfury42]

One way is to provide the back-end service as api's to them, so their UI framework will call the simplq services

I've thought about this before. Our backend is currently very straightforward CRUD over two resources (token and queue) which I wrote over a weekend. I don't think anyone will pay for API access and send their customer data to this. They are better off just building that service on their own. 😅

But yeah, it should get complex over time, maybe we could think in this direction. That's mostly why I would lean to this for now:

other way is providing the UI plugin kind of thing, something, if we need to embed google map, then first we need to subscribe by a google account and request for particular key, then we add canvas some js script to embed and its map data would be available to the hoisted site.

I am sold on this idea. Let us break this into small tasks and build this out incrementally. Think of the minimum we could do to support this feature, build, iterate on it.

Also, data security would also come in picture and many more.

Planning for established organisation customers right now is a good idea, but I want to keep it just at the back of my mind. They would need a lot of things outside of code to start using software, which I am unable to provide at the moment. But if someone ever gets interested in building a company around this, then we can think of this.

PS: when writing this post, an tiny idea 💡 struck my mind, Do we notify the queue member that he is next member or is there something like "notify me when there is 1 member or 2 member ahead of me" and he/she will automatically be notified by the system.

I want to keep these optimisations for the end. For now the queue manager has complete control over who to notify. If it's desirable in his environment for him to notify 3 people in advance, let him do that on the UI.

What I generally do to select a feature for development is, "If we build this, will we get customers due to this?"

[freez3fram3]

Hi there! Great concept here, I'd love to contribute. Is this project alive or dead, or moved somewhere else? :)