Meeting today with couple team members about the invitation system, good meeting!
Mentioned potential use-case for discourse as a delivery dispatch platform, for requests for restaurant take-out and/or moving furniture + building supplies. This platform seems to have great potential to work for that, however may not be ideal [1].
Starting this topic for if anyone would like to speak about if they have used discourse for delivery request management or similar use-case, lots to talk about for this!!
Hmmm, this is a rather vague and contradictory statement; on the one hand, you are saying that the platform has great potential to work for your stated needs, and on the other hand you say it may not be ideal. Can you please provide more clarity or reasoning behind what you mean here? I am curious about what about Discourse you think makes it ideal for a “potential use-case for discourse as a delivery dispatch platform”? But also, what is not ideal as such to you?
The intention of this topic is for general discussion about the discourse platform’s potential suitability for coordinating delivery requests.
What is potentially not-ideal about the platform is the complexity, which can be confusing and overwhelming for some people.
For my own use-case I have a discourse instance setup with a mail-receiver so anyone can send an e-mail to delivery@domain_address, and this will create a PM topic in the Delivery Group.
If there is a group member online and sees this request when it arrives, they can then write a reply in that PM topic and this will send an e-mail response.
In addition, group members can work either as dispatchers or delivery folk, in that when there is a delivery request say for a pizza they may need to call the pizzeria to make the pizza order and/or call the delivery person to dispatch the delivery.
To simplify the process for a pizzeria, staff members at a restaurant can become members of the discourse group so they can see and respond to delivery requests directly.
In conclusion, there is great potential for discourse to work perfectly for this.
At the end of the day Discourse can be technically and socially hacked to do pretty much anything but given there are platforms that were designed for this niche use case, I don’t think I’d bother.
There are a variety of general platforms that could be used to this end.
Sure customizations may not be as diverse. But that is where you use a main site for internet visibility.
Apps like Line, WhatsApp, for example may allow phone calling.
A friend long ago did a delivery company on par with what your aiming for. With Restaurants, auto etc…
At that time it was someone chained to a desk answering the phone and using a CB somewhat closed system. He had tried before using Cell system CBs. But when he had a tower was much better.
These days people all pretty much have cell phones. So text systems for dispatching can work easy enough at low cost.
A good dispatcher is key. As they can organize things. Ie 2 restaurants with orders. If the restaurants are close to one another and the delivery destinations are near each other. A driver can pick up both orders.
When I dispatched for him. I would get the drivers to keep me informed where they are and move markers on a map. Restaurant taking calls can be quite grueling with high volume of calls.
Things like scheduled weekly deliveries is much better as 1 or 2 calls per client/week is easier to manage and yields better. 1 call the company makes more per call then say a restaurant where it is maybe a couple bucks for the company with a lot of work.
NOTE: Be careful if supporting debit to ensure you understand fees. The last time that friend setup a delivery company for restaurants & booze he ended up making nothing as the debit transactions between paying for orders and the fees charged for being able to accept debit payments.
Iirc at that time to accept debit was similar to a credit card where the company accepting pays a percentage of the sale ie 3%. So his $8 per delivery was greatly impacted by the total the end customer paid. So $100 order would cost say $3 decreasing his deliver charge to $5.
That can be so, I worked as newspaper courier for about a year and it is much easier to have a consistent schedule rather than random food take-out orders.
To manage newspaper route could be better potential use-case for discourse, in that established routes have 100-200 subscribers, who could be invited to a discourse site or could be just given cards with site address in case they wanted to become members.
Then with discourse they can communicate both about delivery coordination and the actual printed news, most subscribers in this region are subscribed to the Seattle Times but distribution company I worked for also delivered The New York Times and Wall Street Journal, lots to talk about in what they print. Those are all printed by Sound Publishing here.
The Seattle Times customer service outsources to a call-center in The Philippines.
They also use this company to computer generate delivery route, but their A.I. is really bad.
Cool. If you would like to discuss more on lessons learned of running a food delivery service. We probably should move it to pm to keep your topic on track.
Basics as Hawk said discourse can be crafted to be used for a very wide number of per case uses. However with using as a dispatch system could be quite risky assets imho.
I would recommend doing a lot of controlled testing using call and/or text to verify info being received quickly and consistently.
You could do simulated delivery requests/dispatches.
Well as an example FB messenger I have sent a message with a pic and the pic was not received til a week later.
Delivery businesses of this scope rely heavily on reputation. If your dispatch system has hiccups in response times it can deeply damage reputation of the business.
Hence why you want to thoroughly test with dry runs then move to a limited live testing still using a backup.
Some of the business management aps like “Connect team” and QuickBooks team ap(not sure name) can help with ppl signing in for work & help track things for you.
Some of these work aps also have location sharing when the employee signs in.
If a client calls wondering where the delivery is. It can be hard to answer details you don’t have. Depending on how the ap works it might be possible to share real time location info with business client once a delivery has been picked up.
If there was already ppl using discourse as a dispatching service: you would have more of a baseline to work with.
I’m guessing this hasn’t been tried before, but depending on what you mean by a “delivery dispatch platform,” it seems like a reasonable idea to me.
Start by looking at what problems you’re trying to solve.
I’ve done (and still do) lots of work in the odd jobs space. The biggest problems are:
establishing trust and accountability (will the worker rob the employer, will the employer pay the worker… Will there be repercussions for either party if the don’t hold up their end?)
establishing the worker’s skill set
knowing the going wage for the work
In a small, close-knit, community, these problems can be solved without an app. (I was the odd jobs guy for a group of friends and acquaintances for ~10 years.) Discourse could help translate the kind of organic systems that form naturally in small communities into a larger community. Essentially, help make a larger community somewhat less atomized - bring some of the good parts of country living to the city.
Something similar to the marketplace category on Meta would be a good starting point. If I was doing this, I’d focus on odd jobs instead of just dealing with deliveries. Pickup/deliveries is a good use case though.
I don’t think trying to implement Uber/Doordash/Amazon types of tracking systems on Discourse would make a lot of sense. But I don’t think people need a map showing that the delivery is “5 minutes away” if they have a social connection to the person making the delivery.
For some context, I’m currently wondering how feasible it would be to get building materials delivered to an island that can only be accessed by boat. It would be great to have a place to ask about that.
The core though is Discourse as a dispatching service.
For pre scheduling a delivery it can work as there is not as much pressure. But for fast paced variable things like food delivery not too likely without a lot of work.
Amazon tracking is simply tied to the courier vs them having their own system.
Food delivery companies typically work by sub contracting the delivery to the driver taking a relatively small cut from the Delivery charge. Food deliveries of course don’t need any real tracking as that is in most cases very unnecessary bling
With scheduled deliveries where things like Building supplies if not using the Store’s delivery service.
In @Architect delivery company idea is not likely to be helpful with your island delivery of building materials. However he could potentially augment his income by being able to promote other Companies that would be able to help you if you’re within his region by using referrals links for added income.
However that is honestly a different topic to using discourse as a dispatching agent service imho.
As many business clients in that regard likely want to discuss more with the delivery management the Private Topics plugin likely would be a good consideration.
I will leave it at this. For fast paced restaurants’ delivery and similar(ie booze). I would not recommend using Discourse as a dispatching software service.
For scheduled deliveries set up in advanced where you will hire and fully get employees as bondable? Discourse could work. However on the business side you want to be able to have multiple ways to track the delivery; especially with expensive materials being picked up to delivered.
That would usually be entirely feasible, depending on location of Island + kind of materials + if those can be delivered to the beach or you need them moved far inland though a lot of jungle and/or mountains.
It’s easy access. Something like 200 feet across a channel from where I can get supplies dropped off In the long run, the cheapest solution would be to buy a row boat.
The point I was trying to make here is that to figure out if Discourse is an appropriate tool for solving a problem, it’s probably worth looking at what functionality Discourse provides out of the box. If Discourse’s existing functionality allows you to setup a prototype of the application, it might be worth looking into further.
Establishing trust is a common problem for applications that deal with buying and selling services. A Discourse community could help with this.
Out of the box discourse seems entirely capable of coordinating delivery requests, but can look into other platforms that may be better suited.
Plan to keep discourse instance running for now have that on 2gb memory San Francisco server. I can share the url / address if anyone wants to help with launching that, if it is succesful may be able to offer pay for dispatchers who could work remotely.
Don’t want this topic to be about just one use-case, thought there may be folks who had already launched discourse sites for this but guess not.
By the way if you’re talking about lumber less expensive than a boat would be to just buy some rope to tie the boards together into a raft and paddle that over.
I am preparing to get things setup to talk with local lumberyard for this project, they only charge a fee for delivery when there is less than $50 of material being purchased or they need to use a crane truck which costs $250/hour. Which is an amazingly low price for crane service considering their crane truck is worth about $2 million dollars.
For little materials orders I can deliver those with a light-duty truck for lower fee than they charge for standard delivery trucks/crane.
In the long run, the cheapest solution would be to buy a row boat.