Imagine you have been appointed Technical Architect of a soon to be launched POEMs. Operators have charged you with maximizing profit from their concession. Amazon built the “Everything Store” for swift sales of barcoded items; you have to do the same for community services, rentals, skills, training, finance, and more within obligated Universal Service.
At the highest level, there should be 5 key parameters for POEMs’ technical architecture:
- Time-based services: Markets for selling items are simple and will of course be part of POEMs. But you really want resources rented for fixed periods of time. Transferring ownership of a lawnmower is just one transaction, for you and its owner. A grass cutter that’s hired when not needed offers summer-long recurring revenue, particularly if a work-seeker is seamlessly engaged to deliver and return it each time.
- Small transactions: You won’t structure purchases around general listings such as “funerals”. A Maximum Average Transaction Size drives design of markets around the smallest units of purchase; unbundling hours of mortuary time, collection, attendants, casket sales, or transfers. POEMs will mesh options together safely and seamlessly alongside conventional offers.
- Federal structure: The concession may compel you to have an autonomous franchisee running each market sector. So, you will need a kit-of-parts for front-end displays, regulatory compliance, and processes that each can assemble for their sector’s needs.
- New sectors: POEMs should create new markets. “Holders” for example are households where there is always someone home. POEMs allows them to trade as a drop-off point for neighbors’ deliveries. They are a more responsive, localized, and easily scalable alternative to space-consuming facilities like Amazon Lockers, but need functionality.
- Assistance: It is in operators’ interests to exploit their officially-bestowed benefits with a modernized social safety net integrated into their markets. That software could just as profitably support all sorts of interventions, and investment, in users’ development.
POEMs will have to make sophisticated use of mechanisms. E-markets match a buyer with potential sellers through a range of these devices. You have an attic full of Elvis memorabilia to shift? No-one knows what it’s worth, buyers aren’t in a hurry; an auction mechanism on sites like eBay allows price discovery.
But nobody auctions groceries; prices are known and customers just want to shop quickly. A fixed-price catalogue mechanism like the one at Walmart.com works best. Other mechanisms for online trade include; request-for-quote, bid/ask, classified adverts and aggregated buying.
High-volume markets for assets that are hired for precise blocks of time can exploit a powerful mechanism known as Stored Availability. You will likely know it from booking on Expedia, Booking.com or Trip Advisor. Consumer sites like this interact with an underlying database run by the travel industry. It knows details of each hotel room, flight seat, and rental vehicle; when it is available and how it is to be priced at any time. That underlying platform makes it instant, cheap, and reliable to purchase travel services. And it generates detailed data, allowing sellers to align with buyers’ evolving needs.
There will be other mechanisms to be built, including journey construction. A mature POEMs could pull together any A-to-B transition using combinations of seats on buses, one-way bike hire, carpools, motorbike express taxi’s, and any other form of moveable seat its eclectic seller base wants to offer. It’s up to each buyer what transportation modes they want.
And some travellers will need child seats, ski carriers, or pet transporters. POEMs will have rental markets for each. A mechanism has to then plot their convergence with the vehicle in each case, and the return to its owner after a booking. Trading in pick-up points – any location used as boarding or transfer points for passengers or goods – has to be integral. And functionality that constructs tailored multi-leg journeys could also handle deliveries of goods. POEMs needs to seamlessly flip between mechanisms based on a buyer’s need.
Any POEMs purchase, whatever the mechanism, may need to draw on support functions within the system. They will have to include:
- Dynamic pricing: POEMs isn’t allowed to impose prices. It needs inputs allowing each seller to set their own terms. That might include settings around compensation for travel, and escalating charges for short notice or short length demand.
- Reliability reward: POEMs can never make a user do anything, but it should objectively monitor whether buyers and sellers complete their transactions. Any user – person or organization – can then exploit a good track record as they wish. Within the system, proven reliability should lead to higher earnings, training, and cheaper insurance.
- Financial functions: Buyers have to transfer funds to sellers, so POEMs needs a payment system. It could also offer entry-level bank accounts, peer-to-peer lending, tax calculation and deduction on each transaction, welfare payments conditional on maintaining reliability, and more. With this set up, it’s no stretch to also then offer:
Insurance: This could include transaction cover so if a seller lets a buyer down, there is immediate funding to book a replacement. This hour-by-hour micro-insurance could come from an Allianz, China Life, or Berkshire Hathaway of course. But it could equally be someone with $100 to invest for a week choosing to pool it instantly to insure, say, rental of stud animals.
Portable Benefits: POEMs must calculate and deduct charges to cover sickness cover, pensions, or holiday pay. But there’s no one model or provider. Anyone can be part of a pool selling these services on competing terms to users. That could include co-operatives, or public provision.
Escrow functions: To keep trading reliable, POEMs should deduct funds from a buyer’s account then release them to the seller only once a transaction completes. Some buyers will need funds immediately, so there also has to be a market for seamlessly factoring future payments.
- Ringfenced markets: Some sellers need extra protections. POEMs can run markets curated by any licensed body where for instance, people with developmental disabilities are booked by supportive clients with a favored “work buddy” also scheduled by the system. Philanthropic or public funds for support workers may have to be accessed.
- Functions for intermediaries: Any legally permitted body can act as a middleman between sellers and buyers in POEMs, adding their own services and charges to be collected by the system. In territories like the US that could mean being an employer-of-record, with automated bureaucracy.
Bodies such as unions should have the tools to extend services and offer per-transaction micro-membership if they wish. Educators need functionality to target, populate, and endorse courses built around fluid workers. And if platforms like Uber want to use POEMs to book workers willing to also sell through external platforms, that will need a suite of API’s.
POEMs needs code for searching the granular, real-time, data it generates while preserving user confidentiality. Analytics tools that show any individual and organization where their evolving opportunities sit will grow usage.
Once the system can deliver everything on this page, it could provide further solutions like a convertible alternative currency that might be mandated in the legislation. We call this system-specific micro-currency POETs (Parallel Official Economy Tokens). They could differ from Bitcoin, Facebook Diem, or crypto-currency experiments by central banks in that:
- Tokens are a right of citzens: Tokens could be released to individual users with an initial tranche perhaps eked out over a first 6 months of POEMs’ use.
- Limits are controlled by market data: To preserve the main currency, POETs may only be eligible in sectors where shortage of “real” money is a demonstrable brake on activity within a radius of a user’s home. Childcare or local journeys are examples.
- Tokens can decay: A rule that each token expires if not transferred as part of a purchase within four weeks would drive velocity and activity.
Telecoms carriers have to enable free 911/999 calls as a condition of their license from government. Similarly, POEMs’ operators could be compelled to provide specified services at no-charge to users. They might include:
- Job transfers: System data and search tools would be invaluable for a hiring manager seeking full-timers. The consortium would rather keep users in its markets, so facilities that help hire of reliable flexible workers might be specifically mandated as an add-on.
- Volunteering: Any user wanting to donate their time could ensure for-pay activity remained their priority. (“I am available for work between 2PM and 6PM today, if I have no paid work by 1PM release those hours to any of my approved animal charities”).
- Voting: Individuals could have their say in local petitions, or formal elections, using their POEMs’ constantly re-authenticated ID.
- Social groups: These could be formed and administered by any verified user. Neighborhood forums might be used to give away surplus food, keep an eye on the vulnerable, and report issues, all backed by users’ POEMs’ reliability records.
- Resolution: If a purchase goes sour, buyer and seller need facilities like automated taking of affidavits, settlement suggestions, online adjudication, and enforcement of judgments. A dishonest party should expect to have their standing or activities on POEMs curtailed; just as a bad driver gets points on their license.
- Official interactions: Overrides that allow officials to redirect market activity in an emergency, crime reporting, license renewals and other non-financial interactions with government should also be built in to POEMs.
Transparency, accountability, and neutrality must be core for POEMs. So, the system has to publish its technical specifications and a copy of its code. An updating set of screens with this content won’t attract the average user. But allowing any conspiracy theorist free reign to probe for divergence from operators’ public statements offers reassurance to all users.
The operating consortium has to be a standalone entity with no preferential ties to any organization that might buy, sell, or invest through its markets. All its accounts, salaries, and operational records are published. The system generates only two categories of data: (a) private for a user (b) published openly. There is no “for operators only” fields. So, server capacity, and other normally commercially sensitive metrics have to be on show. Again, screens that facilitate skeptical poking of this content build trust.
There should be no cap on the returns possible for operators of a well run POEMs. But the greatest threat to their revenue must remain akin to a run on a bank: users start distrusting the system and – able to instantly download all their data – exit for alternative services. Your top priority as architect: The tech. has to constantly reinforce trustworthiness.