Biblioteka briefówBiblioteka briefów
Jak wygląda brief, który przechodzi.
Każdy poniższy przykład został oceniony przez tę samą usługę, która ocenia twój – bez selekcji, bez poprawek podbijających wynik. Otwórz go w edytorze i zacznij od niego.
Przepracowane przykłady
Napisane, by uczyć. Ocenione na serio – liczba na każdej karcie pochodzi z bieżącego uruchomienia na otwartym zbiorze reguł.
Przeszukuje cały brief, nie tylko tytuł – wpisz słowa, których sam użyłbyś dla swojego problemu. Większość briefów jest napisana po angielsku, więc angielskie słowa znajdują najwięcej.
54 z 54 przykładów
- Handel i retail🇬🇧89/100
Turn our catalogue into a B2B ordering portal
Wholesale buyers order by email today. We want them self-serve.
Przeczytaj brief
# B2B ordering portal for wholesale buyers ## The problem Around 340 wholesale buyers order from us by email and messaging app, in free text, with their own names for our products. Three people on the order desk spend their days interpreting those messages and retyping them into our ERP — roughly 60 orders a day. Every retyped order is a chance to get a quantity or a variant wrong, and we do, a few times a week. Buyers cannot see whether something is in stock before they order, so a third of the email traffic is just asking. When one of the three is ill, orders queue. ## Who it's for - Buyers at independent shops and distributors, each with their own negotiated price list, ordering the same 40 lines again and again, often late in the evening after closing. - Three people on our internal order desk, who should be handling exceptions rather than transcription. ## What exists today Orders arrive by email and messaging app. The order desk retypes them into our ERP. Stock is visible only to us. Price lists are PDFs we email out when they change, so buyers regularly order against an old one. ## Scope - Authenticated accounts per buying organisation, with more than one user per account. - Customer-specific pricing driven from the ERP, not maintained twice. - Live stock indication per product, at a granularity we choose (in stock / low / lead time). - Order history, and reorder-from-a-previous-order in one action. - Order confirmation by email, and order status visible in the portal. - Two-way ERP sync: products and prices out, orders in. ## Out of scope Online payment — buyers are invoiced on terms and that does not change. A consumer-facing storefront. A native mobile app. Returns handling stays a phone call for now. ## What "done" means 1. A buyer can place a repeat order of 40 lines in under three minutes, from history, without typing product codes. 2. An order placed in the portal appears in the ERP with no human transcription, and the order desk sees only orders that failed validation. 3. A buyer sees their own negotiated prices and never another customer's — verified with two test accounts. 4. Stock indication is no more than 15 minutes stale. ## Constraints The ERP is the system of record for products, prices and stock, and it stays that way — the portal reads from it and writes orders into it through its API. That API is rate-limited and its order endpoint is slow, so order submission needs to be queued and acknowledged rather than synchronous. Buyers use old browsers on shop-floor machines; the portal must work without the newest browser features. ## Risks and assumptions We assume buyers will move off email if the portal is faster than writing a message — which means reorder-from-history is the whole product and everything else is support for it. The main technical risk is the price model: our negotiated prices have accumulated per-customer, per-product and per-volume exceptions, and we do not know until we look whether the ERP exposes all of them cleanly. ## Success looks like 70% of order lines arriving through the portal within six months. The order desk stops retyping and moves to exception handling. Order errors caused by transcription down to zero. ## Budget and timeline €45,000–70,000, live before the autumn buying season, so roughly five months.
Otwórz w edytorze →
- Handel i retail🇬🇧93/100
One stock number across shop, web and marketplace
Three systems, three answers. We oversell every week.
Przeczytaj brief
# A single source of truth for stock ## The problem Three systems each believe they own our stock levels: the e-commerce platform behind the web shop, the point-of-sale system in our two physical shops, and the marketplace channel. None of them tells the others when something sells. The result is 10–15 oversold orders a week that we cancel and refund, an apology each time, and a marketplace account rating that is slowly getting worse. Shop staff phone each other to ask whether the other branch has a size, because no screen can answer it. ## Who it's for Four people in the warehouse who pick and receive. Shop staff in two branches. Indirectly, every customer who currently gets an apology email instead of a parcel. ## What exists today An e-commerce platform, a retail point-of-sale system and a marketplace seller account, each holding its own stock figure. Reconciliation happens when someone notices a problem. ## Scope - A stock service that owns the authoritative quantity per SKU per location, with a documented API. - Connectors to all three channels: consume sales events, push available quantity. - Reservation logic, so stock is held between add-to-basket and payment rather than double-sold in the gap. - An admin view of discrepancies: where a channel disagrees with the service and by how much. - A daily reconciliation report and an alert when a SKU drifts beyond a threshold. ## Out of scope Warehouse hardware and scanners, replacing the point-of-sale system, purchasing and demand forecasting, and product data management. The stock service owns quantities only; product content stays where it is. ## What "done" means 1. A sale in any channel is reflected in every other channel within two minutes, verifiable by selling one unit of a one-unit SKU and watching the other two channels go to zero. 2. The reservation window prevents two customers in different channels from buying the last unit — demonstrable in a load test, not just in theory. 3. The discrepancy view shows a per-channel drift figure that a non-technical manager can read and act on. 4. Overselling drops below one order a week, measured from cancellation records. ## Constraints All three channels are existing systems we are not replacing; each has its own API with different rate limits, and the marketplace one is the strictest. The point-of-sale system pushes sales events with a delay of up to a minute, which puts a floor under how fresh the numbers can be. Everything runs in the EU. ## Risks and assumptions We assume the marketplace's rate limits allow near-real-time pushes at our SKU count — if not, we need a prioritisation strategy for fast-moving lines, and that changes the design. We also assume our current stock figures are wrong in ways we do not yet know; a physical count before go-live is probably unavoidable and should be in the plan. ## Success looks like Overselling below one order a week within three months of the second channel connecting. Stock visible in all channels within two minutes of a sale. Inter-branch phone calls about stock effectively gone. ## Budget and timeline €50,000–80,000. First channel live in eight weeks, all three within five months.
Otwórz w edytorze →
- Handel i retail🇬🇧93/100
A returns flow that doesn't need a human
Returns are 22% of orders and all of it is manual email.
Przeczytaj brief
# Self-service returns for an online fashion retailer ## The problem Returns are 22% of our orders — roughly 1,800 a month — and every single one starts with a customer writing an email. Two support people spend most of their day looking up orders, generating carrier labels by hand and triggering refunds one at a time. Customers wait nine days on average for their money back and write again to ask where it is, which generates more email. Nobody can tell us which products get returned most often, because the reasons only exist in prose inside a shared inbox. ## Who it's for Online customers returning one or two items from a larger order, usually within two weeks of delivery. Our two-person support team. The three people in the warehouse who physically receive the parcels. ## What exists today The customer emails support. Support looks up the order in our e-commerce platform, generates a label in the carrier's web portal, pastes it into a reply, then watches for the parcel and refunds manually in the payment provider's dashboard. Return reasons are typed into a spreadsheet when someone remembers. ## Scope - A returns portal the customer reaches with an order number and postcode — no account needed. - Item selection with structured reason codes, plus a free-text field. - Automatic label generation through our two carriers' APIs. - A warehouse check-in screen: scan the parcel, confirm condition, accept or flag. - Automatic refund trigger on acceptance, through our existing payment provider. - Reporting on return reason by product and by size. ## Out of scope Exchanges (we refund and let the customer reorder), international customs paperwork, store credit or loyalty mechanics, and any change to the checkout itself. ## What "done" means 1. A customer can go from order number to a printable label in under two minutes without contacting anyone. 2. Scanning an accepted parcel in the warehouse triggers a refund automatically within one hour, with no dashboard visit. 3. A monthly export shows return rate by product variant, sortable, downloadable as CSV. 4. Any return the system cannot handle is routed to support with the reason it was routed, rather than failing silently. ## Constraints It has to read orders from our existing e-commerce platform through its API — we are not migrating the shop. Labels must come from the two carriers we already have contracts with. Refunds must go back through the original payment method for compliance reasons. ## Risks and assumptions We assume customers will accept a structured reason code instead of writing a sentence; if the reasons come back mostly as "other", the reporting benefit disappears. The biggest technical risk is the carrier APIs, which are old and rate-limited — we would want that spiked in week one rather than discovered in week eight. ## Accessibility The customer-facing portal must meet WCAG 2.2 AA. It is a public page a distressed customer uses once, so clear error states matter more than polish. ## Success looks like 80% of returns started without contacting support within four months. Refund time down from nine days to three. Support headcount unchanged while order volume grows. ## Budget and timeline €35,000–55,000, three months, with the customer-facing portal live before the post-Christmas returns peak.
Otwórz w edytorze →
- Handel i retail🇬🇧86/100
Configurator for made-to-measure products
Every quote is a phone call and a spreadsheet.
Przeczytaj brief
# Product configurator with instant pricing ## What we want A configurator where a customer picks dimensions, material and options and gets a binding price and a PDF quote. ## Who it's for Homeowners and small builders buying made-to-measure blinds; our four-person sales team. ## What exists today A price list in Excel with 40 tabs. Sales quotes by phone; about 25 quotes a day, two-day turnaround. ## Scope Configurator UI, rules and pricing engine fed by our existing Excel logic, quote PDF, quote-to-order handoff, admin screen to edit rules without a developer. ## Out of scope 3D visualisation, installation scheduling, payments. ## Success looks like Half of quotes self-served; quote turnaround under five minutes. ## Budget & timeline €60–90k, 4 months.
Otwórz w edytorze →
- Handel i retail🇬🇧92/100
Loyalty that works in the shop and online
We have 12,000 email addresses and no reason for anyone to come back.
Przeczytaj brief
# Cross-channel loyalty for a six-shop bakery ## The problem We know our regulars by face and by nothing else. The paper stamp card in the shops and the 12,000-address newsletter list are two unconnected worlds: a customer who buys four times a week gets the same generic email as someone who came once in 2022, and the stamp card tells us nothing at all because it never leaves the customer's wallet. We have no way to recognise a good customer, no reason to give them, and no evidence about whether anything we do brings people back. ## Who it's for - Repeat customers in the shops, paying cash or card, in a queue, in a hurry. Many are over 60. - Shop staff at the till, for whom this must take under five seconds or it will quietly stop being used. - Online customers ordering celebration cakes and catering. ## What exists today A paper stamp card, and a newsletter tool with 12,000 addresses. No link between the two. Our till system is a standard EU point-of-sale product with a documented API. ## Scope - Customer identity that works at a till: a phone number typed on a keypad, or a QR code the customer shows. - A points ledger that is the single truth, written to from both the till and the website. - Reward rules configurable by us (points per euro, threshold rewards, a birthday reward) without a developer. - A till screen for staff: identify, show balance, redeem — three taps maximum. - A customer web wallet showing balance and history, no app install. - A one-way export of consenting customers to our newsletter tool. ## Out of scope A native mobile app, gift cards, payment processing (the till keeps that), and any change to the till hardware. ## What "done" means 1. Identifying a customer and awarding points at the till takes under five seconds, measured with a stopwatch during a real morning rush. 2. Points earned in a shop are visible in the customer's web wallet within one minute, and vice versa. 3. Staff can redeem a reward without a manager code, and every redemption is attributable to a till and a shift. 4. A customer can delete their account from the web wallet and their personal data is actually removed. ## Constraints It has to integrate with the existing till system through its API; replacing the tills is not on the table. Shop internet is a consumer line and occasionally drops — the till flow needs a sane degraded mode rather than blocking the queue. ## Personal data We are storing phone numbers and purchase history, which is personal data under GDPR. We need explicit consent captured at enrolment, a documented retention period, and a working deletion path. Marketing consent must be separate from programme membership. ## Risks and assumptions We assume customers will give a phone number at the till. If enrolment stalls below a few hundred, the whole thing is decoration — so we want the first shop treated as a real test with a go/no-go, not as phase one of a rollout. ## Success looks like 3,000 enrolled customers within three months of the pilot shop going live. Repeat purchase rate among enrolled customers up 10% against a non-enrolled baseline. The paper stamp card withdrawn. ## Budget and timeline €30,000–50,000. Pilot in one shop after six weeks, remaining five shops within four months if the pilot clears the enrolment bar.
Otwórz w edytorze →
- Handel i retail🇬🇧97/100
AI-drafted wholesale ordering for nine bakery shops
A pinned quality fixture assembled from one grounded intake paragraph.
Przeczytaj brief
# Wholesale ordering portal for nine bakery shops ## The problem The core problem: Wholesale orders arrive by email, staff retype them, stock is guessed, and reorders get lost across nine bakery shops. ## Budget Budget: €45,000 for the first working version. ## What we get What we get at the end: a responsive browser portal for wholesale buyers and shop managers, plus CSV export to the current ERP. ## Out of scope Out of scope: native apps, payments, and replacing the current ERP. ## What success looks like Success looks like this: cut order-entry mistakes by half within three months of launch. ## Timeline Timeline: live before September. ## Who it is for Daily users: wholesale buyers placing orders and shop managers checking and fulfilling them. ## The team Team setup: propose the team shape from the scope, budget and timeline. ## Technical constraints Hard constraint: keep the current ERP, exchange orders and stock through CSV, and host personal data in the EU. ## Personal data Personal-data scope: buyer names, email addresses, and order history are personal data and must stay in the EU. ## Assumptions and risks Biggest risk: the ERP stock export may be unreliable, so its accuracy must be tested before portal availability depends on it. ## Accessibility Needs to work for: WCAG 2.2 AA for user-facing interfaces; flag any additional needs.
Otwórz w edytorze →
- Handel i retail🇬🇧91/100
Promotions and prices without a developer
Every campaign needs a ticket, and the ticket takes a week.
Przeczytaj brief
# Campaign and pricing tooling for a retail marketing team ## The problem Our marketing team cannot change a price, launch a promotion or put a banner on the homepage without raising a ticket. The ticket takes about a week, which means we miss weather-driven opportunities entirely and we plan campaigns around development capacity rather than around customers. Two people on the development side spend a meaningful part of every sprint on what are, honestly, data changes. Nobody has an audit trail either: when a discount goes out wrong, we cannot say who asked for what. ## Who it's for Four people in a marketing team who are comfortable with spreadsheets and analytics but write no code. Two developers who would like their sprint back. Customer service, who need to see which promotion applied to a given order when a customer disputes a price. ## What exists today Prices and promotion rules are configuration in the shop's codebase. Changing one is a pull request, a review and a deploy. Homepage banners are hard-coded images. There is no preview: we find out how a campaign looks when it is live. ## Scope - A promotion rule builder covering the mechanics we actually use: percentage off, buy-X-get-Y, a threshold for free shipping, and a category-wide reduction with exclusions. - Scheduling with a start and end time, so a campaign can be prepared on Thursday and go live on Saturday morning without anyone present. - A preview that shows the storefront as it will look, against real catalogue data, before publishing. - Editable homepage banner slots with an image, a link and a schedule. - A full audit log: who changed what, when, and what it looked like before. ## Out of scope Personalised or per-customer pricing, loyalty mechanics, email campaign tooling, and the checkout logic itself. We are also not changing the underlying shop platform. ## What "done" means 1. A marketer can build, preview, schedule and publish a promotion without any developer involvement, demonstrated by one doing it unaided. 2. A scheduled campaign goes live and expires on time without a deploy. 3. Every published change is attributable to a person, with a viewable before-and-after. 4. An invalid rule (one that would price something below zero, or that overlaps an existing exclusive promotion) is refused at edit time with an explanation, not at checkout. ## Constraints It has to sit on top of the shop platform we already run and use its pricing API rather than replace it. Promotions must evaluate fast enough not to slow the basket; the platform's own rule engine is the fallback if ours cannot. Everything is hosted in the EU. ## Risks and assumptions Our assumption is that the four promotion mechanics above cover 90% of what we run. If marketing immediately wants a fifth, the builder must be extensible rather than a fixed form — worth confirming against a year of past campaigns during discovery. The second risk is that a self-serve tool makes mistakes cheaper to make as well as cheaper to fix, which is why the validation and audit log are in scope and not optional. ## Success looks like Campaign lead time from a week to under a day. Zero developer tickets for price or promotion changes after month two. Every pricing dispute answerable from the audit log in under five minutes. ## Budget and timeline €40,000–60,000 over three months, with the promotion builder before the autumn campaign season.
Otwórz w edytorze →
- Handel i retail🇬🇧93/100
Product data that is right in five languages
The same product has three different descriptions, depending where you look.
Przeczytaj brief
# Product information management for a multi-market retailer ## The problem We sell 6,000 products into five markets, and the same product has different descriptions, different dimensions and sometimes a different photo depending on which channel you look at. Product data starts in a supplier spreadsheet, gets edited by whoever loads it, then gets edited again per market. Nobody knows which version is right. Our returns from one market are noticeably higher and we suspect the reason is a measurement that was converted wrong two years ago and copied ever since. ## Who it's for Two product data editors who do the loading and translation coordination, five market managers who want local control over wording, and the warehouse, who need the physical attributes to be right because they drive packaging choice. ## What exists today A spreadsheet per supplier, imported into the shop platform, then edited in the shop's admin. Translations are commissioned ad hoc and pasted in. Photography lives on a shared drive with filenames as the only metadata. ## Scope - One product record per product, with a clear split between global attributes (dimensions, weight, materials, supplier code) and per-market attributes (name, description, marketing copy). - A translation workflow: mark a field as needing translation, export, import, review, publish — with the state visible per field. - Supplier import with mapping and validation, so a bad row is rejected with a reason rather than silently loaded. - Asset management: images attached to products with a defined role (main, detail, in-use) and a required minimum resolution. - Publication to the shop platform per market. ## Out of scope Pricing and stock, which stay in the systems that own them today. Order management. Any change to the shop front end. We are also not building a translation engine — we are building the workflow around whoever does the translating. ## What "done" means 1. Changing a global attribute once updates it in all five markets, verifiable on a test product. 2. A market manager can edit local copy without being able to change a physical attribute. 3. A supplier import with a malformed row reports which row, which column and why, and imports the rest. 4. Every product published to a market has a main image at or above the minimum resolution — the system refuses to publish otherwise. 5. Translation status is visible per field, so nobody has to ask "is the Dutch copy done". ## Constraints Supplier data arrives as spreadsheets in inconsistent formats and that will not change; the import mapping has to be configurable per supplier by our own team. The shop platform is the publication target through its API and is not being replaced. Image storage needs to handle around 40,000 assets. ## Risks and assumptions We assume our existing product data can be cleaned rather than re-entered — a sample audit early on would tell us, and if the answer is that 6,000 records need human review, that is a separate budget conversation we would rather have in week two than month four. We also assume market managers will accept losing the ability to edit dimensions; that is a governance change as much as a software one. ## Success looks like One description per product per market, with a visible owner. Returns attributable to wrong product data down by half within a year. Time to launch a product into a new market from days to hours. ## Budget and timeline €60,000–90,000 over four to five months, with the global product record and one market first.
Otwórz w edytorze →
- Handel i retail🇫🇷97/100
Stock unifié et retrait en magasin pour neuf points de vente
Nos vendeurs téléphonent aux autres magasins pour savoir si un article est en rayon.
Przeczytaj brief
# Stock unifié et retrait en magasin pour un réseau de quincailleries ## Le problème Nous sommes une entreprise familiale de distribution de quincaillerie et de matériaux, neuf magasins dans deux départements, 140 salariés, environ 28 000 références. Chaque magasin gère son stock dans sa propre instance du logiciel de caisse, et ces instances ne se parlent pas. Un vendeur qui n'a pas l'article en rayon appelle deux ou trois confrères pour le trouver : nos relevés internes donnent 40 appels par jour sur le réseau, soit trois heures de temps vendeur perdues quotidiennement. Une commande client sur cinq est abandonnée pendant cette recherche, alors que la marchandise est disponible à trente kilomètres. Nos clients professionnels commandent désormais chez un concurrent national parce qu'ils voient la disponibilité avant de se déplacer. Notre site vitrine n'affiche aucun stock et ne prend aucune commande. ## À qui cela s'adresse - Une quarantaine de vendeurs comptoir, debout, un client en face d'eux, qui n'accepteront pas une manipulation de plus de quelques secondes. - Les neuf responsables de magasin, qui restent maîtres de leurs commandes fournisseurs et de leurs implantations. - Les artisans et petites entreprises du bâtiment, qui préparent leur tournée depuis un téléphone avant l'ouverture des magasins. - Le service comptable au siège, qui facture les comptes professionnels une fois par mois. ## Ce qui existe aujourd'hui Neuf bases de stock séparées dans le logiciel de caisse, un fichier articles commun mais désynchronisé, un tableur partagé pour les transferts, un site vitrine statique, et un progiciel de gestion au siège qui centralise la comptabilité et les comptes clients. Les transferts inter-magasins se demandent par téléphone puis se notent sur un bon papier. ## Périmètre - Un référentiel articles unique, alimenté par le siège, avec libellé, unité de vente, photo et fiche technique. - Une consultation du stock temps réel des neuf magasins, accessible au comptoir et depuis le web. - Une réservation d'article pour retrait en magasin sous deux heures, avec confirmation au client. - Une demande de transfert inter-magasins tracée, remplaçant le bon papier. - Un compte professionnel en ligne : tarif négocié du client, historique des achats, réédition des factures. - Un paiement en ligne pour les clients particuliers, et le paiement à échéance conservé pour les comptes professionnels. ## Explicitement hors périmètre Nous ne remplaçons pas le logiciel de caisse ni le progiciel de gestion : ils restent la source de vérité pour les mouvements de stock et pour la comptabilité. Sont également exclus la livraison à domicile, les tournées de camion, le réapprovisionnement automatique et la vente sur les places de marché. La reprise de l'historique des commandes antérieures n'est pas demandée. ## Quand est-ce terminé 1. Un vendeur au comptoir voit le stock des neuf magasins pour une référence en moins de dix secondes, sans passer un appel. 2. Un artisan réserve un article depuis son téléphone à 6 h 30 et reçoit une confirmation de mise à disposition avant 8 h 30. 3. Une demande de transfert entre deux magasins est créée, suivie et clôturée dans l'outil ; le bon papier a disparu du processus. 4. Le stock affiché en ligne diffère de moins de quinze minutes du stock de la caisse, mesuré sur un échantillon de 200 références pendant une semaine. 5. Un client professionnel retrouve et réédite seul une facture des douze derniers mois, sans appeler la comptabilité. ## Contraintes techniques Le logiciel de caisse expose ses mouvements via une interface limitée à un appel toutes les cinq minutes par magasin : l'architecture doit vivre avec cette fréquence et l'assumer dans l'affichage. Trois magasins sont raccordés en ADSL et connaissent des coupures : le poste comptoir doit rester utilisable en mode dégradé. Les tarifs négociés proviennent du progiciel de gestion et ne sont jamais saisis deux fois. Hébergement dans l'Union européenne. ## Hypothèses et risques L'hypothèse la plus fragile est la qualité du fichier articles : les mêmes produits portent des codes différents selon les magasins, et nous estimons le taux de doublons entre 10 et 20 pour cent, sans l'avoir mesuré. Un audit des 3 000 références les plus vendues doit être mené dès le premier mois, car un stock unifié sur un référentiel faux est pire que pas de stock unifié. Le risque organisationnel est l'autonomie des responsables de magasin : trois d'entre eux voient le stock partagé comme une perte de contrôle sur leur chiffre d'affaires. Tant que la règle d'affectation de la marge sur un transfert n'est pas tranchée par la direction, l'outil sera contourné. ## Comment nous mesurons le résultat Appels inter-magasins de 40 par jour à moins de 10 en six mois. Commandes abandonnées faute de disponibilité de 20 pour cent à moins de 5 pour cent. Au moins 300 retraits réservés en ligne par mois à la fin de la première année. ## Données personnelles et accessibilité Le compte professionnel et le paiement en ligne traitent des données personnelles : conformité RGPD, hébergement européen, registre des traitements et durées de conservation définies avant la mise en service. Les interfaces client et comptoir visent le niveau AA du RGAA, la version française des WCAG 2.1. ## Budget et calendrier 45 000 – 70 000 €, quatre à cinq mois, avec la consultation du stock des neuf magasins en production dans deux magasins pilotes sous huit semaines.
Otwórz w edytorze →
- Handel i retail🇸🇪94/100
Inbytesflödet för begagnade möbler
Vi köper in begagnade möbler på känsla, och en tredjedel av dem står kvar efter ett halvår.
Przeczytaj brief
# Inbyte och andrahandsförsäljning i en möbelhandel med fyra butiker ## Problemet Vi är en fristående möbelhandel med fyra butiker och en webbutik, och sedan tre år tar vi emot kundens gamla möbel i inbyte vid nyköp. Affären är populär men styrs på magkänsla. Säljaren sätter ett inbytesvärde på plats utan underlag, och vi kan inte i efterhand se vad möbeln faktiskt såldes för. Just nu står 34 % av det inbytta lagret kvar efter sex månader och binder cirka 900 000 kr. Renoveringsverkstaden har ingen lista annat än vad som fysiskt står innanför porten. Kunden som lämnat in hör inte av oss förrän hen ringer och frågar. ## Vem det är till för - Säljarna i butik, som värderar med kunden framför sig och har fem minuter innan nästa kund. - De två snickarna i renoveringsverkstaden, som behöver se dagens kö utan att sätta sig vid en dator. - Lagerchefen, som ska veta i vilken butik en begagnad soffa blir såld. - Ekonomiansvarig, som ska hantera moms och avräkning mot kunden korrekt. - Kunden som lämnar in och vill veta vad hen får och när. ## Vad som finns i dag Kassa- och lagersystemet hanterar bara nya artiklar med artikelnummer; en begagnad möbel är unik och får i dag ett påhittat nummer. Inbytena skrivs på papper som skannas in i en delad mapp. Vad som sålts vet vi bara genom att jämföra kassarapporter för hand. Webbutiken kan inte visa artiklar som finns i ett enda exemplar utan att sortimentet blir fel. ## Omfattning - Värderingsstöd i butik: säljaren väljer möbeltyp och skick och ser vad liknande möbler sålts för hos oss senaste året. - Unikt objekt med foton, mått, skick, inköpsvärde och plats — ett objekt, ett exemplar, en historik. - Renoveringskö med status och tidsåtgång per objekt. - Publicering till webbutiken när objektet är klart, med avpublicering vid försäljning i butik. - Flytt mellan butiker med enkel kvittering. - Avräkning mot inlämnande kund och underlag till ekonomi. - Automatiskt sms till kunden vid mottagande, värdering och slutavräkning. ## Uttryckligen utanför omfattning Vi bygger ingen egen marknadsplats och integrerar inte mot externa annonsplatser i den här etappen. Kassasystemet byts inte ut, och vi bygger inte om det nya sortimentets produktdata. Transport och hemleverans hanteras som i dag, av speditören, utanför lösningen. Ingen automatisk prissättning: verktyget föreslår, människan bestämmer. ## När det är klart 1. En säljare registrerar ett inbyte med foton och prisförslag på under fyra minuter, på butikens surfplatta, med kunden kvar vid disken. 2. Ett objekt som säljs i butik försvinner från webbutiken inom fem minuter, utan manuellt arbete. 3. Snickaren ser dagens renoveringskö på en skärm i verkstaden och kvitterar klart utan lösenord. 4. Lagerchefen får varje måndag en lista per butik över objekt som stått över 90 dagar. 5. En kund följer sitt inlämnade objekt via länken i sms:et, utan konto. 6. Ekonomi får avräkningsunderlaget som fil i stället för att sammanställa det för hand. ## Tekniska förutsättningar Butikernas surfplattor är fyra år gamla och hamnar ibland på gästnätet, så laddtiderna måste hålla på svag uppkoppling. Kassasystemets API för försäljningstransaktioner får vi läsa men inte skriva till; kopplingen mellan såld artikel och unikt objekt måste därför göras på vår sida. Webbutiken är en standardplattform och tar emot produkter via sitt API. Drift inom EU. Kunduppgifter — namn, telefon, adress och kontouppgift för avräkning — behandlas enligt GDPR med gallring 36 månader efter slutavräkning, av bokföringsskäl. Kundens spårningssida ska uppfylla WCAG 2.1 AA. ## Antaganden och risker Vi antar att vår historik räcker för ett vettigt prisförslag. Den bygger på manuellt inskrivna kassarader där möbeltypen ofta är felklassad, så de första månadernas förslag kan bli sämre än säljarens gissning; det bör mätas innan vi litar på det. Den organisatoriska risken är att butikscheferna belönas på nyförsäljning och därför nedprioriterar begagnade objekt som tar golvyta. Ändras inte ersättningsmodellen står objekten kvar oavsett hur bra systemet är. ## Så mäter vi resultatet Andel inbytt lager äldre än sex månader från 34 % till under 15 % på ett år. Bundet kapital i begagnat från 900 000 kr till under 500 000 kr. Tid från inlämning till publicering från 24 dagar till under 10. Kundsamtal med frågan "vad hände med min soffa" ned till noll. ## Budget och tidplan 45 000–70 000 €, fyra månader, med inbyte och renoveringskö i drift i en butik som pilot efter åtta veckor.
Otwórz w edytorze →
- Handel i retail🇪🇸91/100
Sacar los pedidos de hostelería del WhatsApp
Cada mañana dos personas transcriben 180 pedidos de audios de WhatsApp, y de ahí salen los errores de reparto.
Przeczytaj brief
# Portal de pedidos para los clientes de hostelería de una distribuidora familiar ## El problema Somos una distribuidora familiar de alimentación y bebidas, 34 empleados, que sirve a unos 420 bares, restaurantes y hoteles en dos provincias. Los pedidos entran por WhatsApp (la mayoría en notas de voz), por teléfono al almacén y, algunos, por correo. Cada mañana entre las 7:00 y las 10:30 dos administrativas escuchan y transcriben alrededor de 180 pedidos al programa de gestión. El resultado es previsible: el 4,8% de las líneas servidas el año pasado tuvo alguna incidencia — referencia equivocada, cantidad mal entendida, formato de envase distinto del pedido — y cada abono nos cuesta de media 38 € entre producto, transporte y tiempo administrativo. En temporada alta, con un 60% más de pedidos, la transcripción no termina antes de la salida de las rutas y hay clientes que reciben lo suyo al día siguiente. Además, el cliente no sabe qué precio tiene hasta que le llega el albarán: las tarifas y los descuentos por volumen los conoce solo el comercial de la zona. ## Para quién es - Los responsables de compra de los bares y restaurantes, que hacen el pedido a las 23:30 después de cerrar, desde el móvil, cansados y con una mano. - Las dos administrativas de pedidos, que hoy transcriben y que deberían dedicarse a las incidencias y a los clientes nuevos. - Los seis comerciales de ruta, que visitan y necesitan ver y corregir el pedido del cliente antes del cierre de la jornada. - El jefe de almacén, que prepara las rutas de la mañana siguiente y necesita el pedido cerrado a una hora fija. ## Qué existe hoy Un programa de gestión propio donde viven artículos, tarifas por cliente, stock y facturación. Varios grupos y chats de WhatsApp por comercial. Una hoja de cálculo con las tarifas especiales que solo actualiza el gerente. Un catálogo en PDF de 96 páginas que se envía por correo dos veces al año y que ya nace desactualizado. No hay ninguna tienda ni portal. ## Alcance - Portal de pedidos accesible desde el móvil, con acceso por cliente y por punto de venta, sin instalar nada. - Catálogo con la tarifa real de cada cliente, incluidos sus descuentos, y disponibilidad orientativa del artículo. - Repetición del último pedido y plantillas de pedido habitual por local. - Aviso de cierre de pedido para la ruta del día siguiente y confirmación inmediata de lo pedido. - Histórico de pedidos y albaranes descargables por el propio cliente. - Vista para el comercial: pedidos de sus clientes en curso, con posibilidad de corregir antes del cierre. - Volcado del pedido al programa de gestión, sin transcripción manual. ## Fuera de alcance No cambiamos el programa de gestión: las tarifas, el stock y la facturación siguen viviendo allí y el portal solo lee y escribe pedidos. No entramos en la facturación electrónica ni en la adaptación a Verifactu, que se está resolviendo con el proveedor del programa de gestión. No hacemos venta a particulares, ni cobro con tarjeta en el portal, ni optimización de rutas de reparto, ni una aplicación nativa para las tiendas de aplicaciones. ## Cuándo está terminado 1. Un responsable de bar hace un pedido de veinte líneas desde el móvil en menos de tres minutos partiendo de su plantilla habitual. 2. El pedido aparece en el programa de gestión sin que nadie lo teclee, y coincide línea por línea con lo que el cliente ha confirmado. 3. El cliente ve, antes de confirmar, el precio que se le va a facturar, incluidos sus descuentos. 4. A la hora de corte, el jefe de almacén tiene el listado de preparación completo sin esperar a la transcripción. 5. Al menos el 60% de los clientes activos ha hecho su pedido por el portal durante un mes completo sin ayuda telefónica. 6. Las administrativas dejan de transcribir notas de voz: los pedidos por WhatsApp bajan a menos de 20 diarios, reservados a clientes que aún no se han incorporado. ## Restricciones técnicas El programa de gestión se comunica mediante su interfaz de servicios web y solo acepta un pedido cada dos segundos, con una ventana de mantenimiento nocturna de 02:00 a 03:00 en la que no responde: el portal debe encolar y reintentar sin perder pedidos ni duplicarlos. Los clientes usan móviles antiguos y conexiones móviles pobres en locales con paredes gruesas, así que la interfaz tiene que funcionar con poca señal y cargar en menos de tres segundos en una conexión lenta. Alojamiento en la Unión Europea. Interfaz en castellano y catalán. Accesibilidad conforme a WCAG 2.1 AA, con contraste y tamaño de objetivo pensados para un uso a una mano de noche. ## Supuestos y riesgos El supuesto más frágil es que las tarifas del programa de gestión están al día y coinciden con lo que los comerciales aplican de palabra. Sospechamos que hay acuerdos verbales que no están en ningún sitio, y si el portal muestra un precio distinto del que el cliente espera, la confianza se rompe la primera semana: hay que auditar las tarifas de los cincuenta clientes de mayor facturación antes de abrir. El riesgo organizativo está en los comerciales: el pedido por WhatsApp es su vínculo diario con el cliente y pueden vivirlo como una pérdida de relación, o seguir aceptando audios. Sin una decisión clara de la dirección sobre la fecha en la que WhatsApp deja de ser canal oficial, el proyecto se queda a medias. Tratamos datos personales de los contactos de clientes (nombre, teléfono, correo): necesitamos base jurídica, contrato de encargo de tratamiento con el proveedor de alojamiento y una política de conservación tras la baja. ## Cómo medimos el resultado Incidencias por línea servida del 4,8% al 2% en un año. Tiempo administrativo dedicado a transcribir pedidos de unas siete horas diarias a menos de una. Pedidos recibidos después de la hora de corte de un 12% a menos de un 4%. Pedido medio por cliente al menos un 5% superior, porque el catálogo completo pasa a estar visible. Cero pedidos perdidos por fallo de comunicación con el programa de gestión. ## Presupuesto y plazos 60.000–85.000 €, cinco meses. Primer hito: portal en pruebas con treinta clientes de una sola ruta a las diez semanas, manteniendo el canal de WhatsApp en paralelo durante ese piloto.
Otwórz w edytorze →
- Handel i retail🇪🇪95/100
Üks laoseis kolme kaupluse ja e-poe peale
E-pood müüs eelmisel kuul 130 korda kaupa, mida riiulil enam polnud.
Przeczytaj brief
# Ühine laoseis ja tellimuste vaade jaeketis ## Probleem Oleme pere-ettevõte kolme kauplusega ja e-poega, kokku umbes 6 000 artiklit. Laoseis on igas kaupluses eraldi kassasüsteemis ja e-poel on oma number, mida uuendatakse käsitsi kord ööpäevas. Tulemus on, et eelmisel kuul müüs e-pood 130 tellimusel kaupa, mida laos tegelikult ei olnud: 41 tellimust tühistati, ülejäänud viibisid keskmiselt üheksa päeva. Klienditeeninduse aeg kulub peamiselt nende kõnede peale. Vastupidine viga on kallim ja vaiksem: kaup seisab ühes kaupluses, samal ajal kui teises on see otsas, ja kaks korda kuus tellitakse tarnijalt juurde midagi, mida majas juba on. Hindame selle seisva kauba väärtuseks umbes 60 000 eurot. Kaupluste vahelist liigutamist tehakse telefoni teel ja seda ei kajastu kusagil. ## Kellele - Kolm kaupluse juhatajat, kes tellivad kauba juurde ja kelle ainus tööriist tööpäeva jooksul on kassaterminal leti taga, klientide järjekorra ees. - Kaheksateist müüjat, kes peavad kliendi ees minuti jooksul ütlema, kas kaupa on teises kaupluses. - E-poe haldaja, üks inimene, kes vastutab ka kliendipäringute eest. - Omanik, kes tellib tarnijatelt ja tahab teada, milline kaup seisab üle 180 päeva. - Raamatupidaja, kes soovib inventuuri ilma kolme päeva käsitsi lugemiseta. ## Mis on täna olemas Kolm kassasüsteemi, igaühel oma laoseis ja oma artiklinimetused, mis ei kattu täielikult. E-pood eraldi platvormil, mida toidab kord ööpäevas käsitsi tehtud CSV-fail. Tarnijate tellimused käivad e-kirjaga, hinnakirjad tulevad Exceli failidena ja laaditakse käsitsi sisse. Ostuarved liiguvad juba e-arvetena majandustarkvarasse, see osa töötab. Kaupluste vaheline liigutamine käib telefoni ja paberi peal. ## Maht - Ühtne artikliregister ühe tõeallikana: ühtsed koodid, nimetused, tarnija, ostuhind, müügihind. - Reaalajas laoseis asukoha kaupa, mida kassamüük ja e-poe tellimus vähendavad ühest ja samast numbrist. - Kaupluste vahelise liigutamise vormistamine kassaterminalis: saatja kinnitab, vastuvõtja kinnitab, laoseis liigub. - Müüja päring "kus seda on": artikli laoseis kõigis kolmes kaupluses ja e-poe laos, alla kümne sekundi. - Tellimuse ettepanek tarnijale müügikiiruse ja miinimumkoguse alusel, mille juhataja kinnitab või muudab. - E-poe tellimuste vaade koos komplekteerimise ja kättesaamise staatustega. - Aruanne seisvast kaubast: mis on lattu jäänud üle 90 ja üle 180 päeva, asukoha kaupa. - Inventuuri režiim telefoniga triipkoodi lugemiseks. ## Väljaspool mahtu Me ei ehita uut e-poodi ega vaheta kassasüsteemi välja — mõlemad jäävad alles ja neid ainult liidestatakse. Kliendiprogramm, kampaaniahinnad, kaupluse kaalukaubad ja tarnijate arvete töötlemine jäävad välja; ostuarved liiguvad edasi e-arvetena majandustarkvarasse nagu praegu. Prognoosimudeleid ega automaatset tellimist ilma inimese kinnituseta ei tehta. ## Millal on valmis 1. Müüja leiab leti taga artikli laoseisu kõigis kolmes kaupluses alla kümne sekundi, ilma et ta peaks kellelegi helistama. 2. E-poes ostetav kogus ei ületa tegelikku laoseisu: kuu jooksul ei tühistata ühtegi tellimust laoseisu vea tõttu. 3. Kaupluste vaheline liigutamine on süsteemis nähtav ja telefoni teel liigutamist ei toimu ühe kuu jooksul. 4. Seisva kauba aruande saab välja võtta alla ühe minuti ja see näitab artiklit, asukohta ja seisuaega. 5. Inventuur ühes kaupluses tehakse ühe õhtuga kahe inimesega, mitte kolme päevaga. 6. E-poe ja kliendi vaated vastavad WCAG 2.1 AA tasemele. ## Tehnilised piirangud Kassasüsteemil on olemas liides, kuid see on tehtud ainult müügiandmete väljalugemiseks, mitte laoseisu muutmiseks — see tuleb esimesena üle kontrollida. Ühes kaupluses on internetiühendus ebastabiilne, seega peab kassa müük toimima ka lühikese katkestuse ajal ja sünkroniseeruma hiljem. Töötajad sisenevad Smart-ID või Mobiil-ID-ga, mitte jagatud parooliga. E-pood suhtleb olemasoleva API kaudu. Andmed Euroopa Liidus. Liides eesti ja vene keeles. ## Eeldused ja riskid Kõige hapram eeldus on, et kolme kaupluse artiklikoodid on ühildatavad: teame juba, et sama toode on kahes kaupluses erineva koodi all, ja kui palju neid on, selgub alles siis, kui andmed kokku pannakse. See kaardistamine tuleb teha esimese kuu jooksul ja see on käsitsitöö, mida ei saa arendajale delegeerida. Teine risk on organisatsiooniline: seni on iga kaupluse juhataja tellinud iseseisvalt, ja ühine laoseis tähendab, et tema kaup võidakse teise kauplusesse liigutada. Kui selles eelnevalt kokku ei lepita, hakatakse laoseisu vääralt kajastama, et kaupa enda juurde hoida. Kolmas risk on, et kassasüsteemi tarnija ei toeta laoseisu kirjutamist liidese kaudu; sel juhul on vaja varuplaani ja see muudab eelarvet. ## Kuidas mõõdame Laoseisu vea tõttu tühistatud e-poe tellimused 41-lt nullini kuus. E-poe tellimuse keskmine täitmisaeg üheksalt päevalt alla kahe päeva. Üle 180 päeva seisnud kauba väärtus 60 000 eurolt alla 35 000 euro aasta jooksul. Klienditeeninduse laoseisu puudutavad kõned poole võrra vähemaks. Inventuurile kuluv aeg kolmelt päevalt ühele õhtule kaupluse kohta. ## Isikuandmed Süsteem puutub kokku e-poe klientide nime, aadressi ja tellimuse ajalooga ning töötajate sisselogimisandmetega. Vajame kirjalikult fikseeritud töötlemise alust ja säilitustähtaegu, tellimuste andmete kustutamist tähtaja möödudes ning selget rollipõhist ligipääsu — müüja ei pea nägema teiste klientide ostuajalugu. Arendaja on volitatud töötleja ja vajab lepingut. ## Eelarve ja ajakava 65 000–90 000 €, viis kuud, ning ühtne artikliregister ja ühe kaupluse reaalajas laoseis koos e-poega tööl kümne nädalaga.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧91/100
Digital job travellers for the shop floor
Every job carries a paper folder around the factory.
Przeczytaj brief
# Digital job traveller for a contract machining shop ## The problem Every job moves through the factory inside a paper folder. Planning prints the day's jobs each morning from our ERP; operators write quantities, scrap and times on the sheet; someone types it all back in during the evening. That means our planning data is always a day old, so when a customer calls at 14:00 to ask where their order is, the honest answer is "somewhere between yesterday's positions". Worse, drawings get printed once and revisions do not always chase the folder — we have scrapped batches made to a superseded revision. ## Who it's for 28 machine operators across three shifts, several of whom do not use a computer outside work and a few of whom read the shop's working language as a second language. Two planners. One quality lead who needs the scrap and rework record. ## What exists today Jobs are printed from our ERP every morning. Progress is handwritten and re-keyed in the evening. Drawings live on a network share, versioned by filename. ## Scope - A work-centre queue view on a wall-mounted tablet: what to run next, in order, with the reason for the order. - Job detail showing the current drawing revision, pulled live so a superseded revision cannot be opened. - Start, pause and finish with quantity good, quantity scrapped and a scrap reason. - A planner dashboard showing real positions and re-sequencing by drag. - Read and write back to the ERP. ## Out of scope Machine data collection from PLCs, maintenance scheduling, payroll and time-and-attendance, and anything that changes how quoting works. We are also not replacing the ERP. ## What "done" means 1. A planner can see every job's true work centre and quantity within 15 minutes of the operator touching the tablet — verified by walking the floor and comparing. 2. Opening a job on the tablet always shows the current drawing revision; opening a job whose drawing has been revised since it was released shows a blocking notice. 3. The evening re-keying task no longer exists — measured by it being removed from the shift handover checklist. 4. Scrap is attributable to a job, a work centre and a reason code, exportable for the quality lead. ## Constraints Wifi on the shop floor is patchy near the large machines, so the tablet view has to tolerate going offline for a few minutes and reconcile when it returns; losing an operator's entry is not acceptable. The ERP exposes a REST interface but writes are slow and rate-limited. Tablets are wall-mounted and operated with gloves on, so touch targets need to be large and the whole flow must work without a keyboard. ## Risks and assumptions Our biggest assumption is that operators will record scrap honestly on a screen when they were vague about it on paper. If they do not, the quality reporting is worthless — we would rather find that out in a pilot on one work centre than after a full rollout. Second risk: the ERP's write API may not support partial job progress the way we need, in which case the integration design changes materially. ## Success looks like Job status accurate within 15 minutes, from a day. Zero batches made to a superseded drawing revision in the first year. The evening data-entry shift gone. ## Budget and timeline €70,000–110,000. One work centre live in 10 weeks as a pilot, full floor within six months if the pilot holds.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧80/100
Quality checks with photos, on a tablet
Our audit trail is a binder. Customers keep asking for it.
Przeczytaj brief
# Quality inspection app ## What we want A tablet app for incoming, in-process and final inspection: checklists per product, measured values, photos, pass/fail, signed report. ## Who it's for Five QA inspectors and the quality manager who assembles customer documentation. ## What exists today Printed checklists in binders. Assembling documentation for one customer audit takes two days. ## Scope Checklist builder, inspection capture with photos and tolerances, non-conformance record with follow-up, PDF report per batch, search by batch or order number. ## Out of scope Calibration management, supplier portal, statistical process control. ## Success looks like Audit documentation produced in under an hour; every non-conformance traceable to a batch. ## Budget & timeline €40–65k, 3 months, ISO 9001 evidence requirements must be met.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧86/100
Know what a machine hour actually costs
We quote from gut feeling and find out later.
Przeczytaj brief
# Machine and job costing dashboard ## What we want A dashboard that shows the real cost and margin per job and per machine, using data we already have. ## Who it's for The owner, the plant manager and whoever writes quotes. ## What exists today Time bookings in our ERP, energy meters read monthly by hand, material costs in invoices. Nobody joins them up. ## Scope Data pipeline from ERP and energy meters, cost model per machine hour, margin per job, quote-versus-actual comparison, monthly export for the accountant. ## Out of scope Automated quoting, ERP replacement, forecasting. ## Success looks like Margin per job visible the day it closes; the ten worst-performing jobs identifiable each month. ## Budget & timeline €35–55k, first dashboard in 8 weeks.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧84/100
A supplier portal instead of 200 emails a week
Purchase orders, confirmations and delays all live in inboxes.
Przeczytaj brief
# Supplier portal ## What we want A portal where our 60 suppliers see open purchase orders, confirm dates, flag delays and upload documents. ## Who it's for Suppliers (mostly small, low-tech) and our three-person purchasing team. ## What exists today POs are emailed as PDFs from the ERP. Confirmations come back as free text. Purchasing chases by phone. ## Scope Supplier login, PO list and detail, confirm or propose a new date, delay reason, document upload (certificates, delivery notes), email notifications, ERP sync. ## Out of scope Invoicing, e-invoicing compliance, supplier scoring. ## Success looks like 80% of confirmations through the portal in six months; late deliveries known a week earlier. ## Budget & timeline €45–70k, 4 months.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧81/100
Maintenance requests from the floor, not from memory
Breakdowns get reported by shouting.
Przeczytaj brief
# Maintenance request and log system ## What we want A simple way for an operator to report a fault from a phone (QR code on the machine) and for maintenance to plan, log and close the work. ## Who it's for 30 operators, four maintenance technicians, the plant manager. ## What exists today Faults are reported verbally or on a whiteboard. There is no history, so we cannot see which machines cost us the most. ## Scope QR-per-machine reporting, photo and description, priority queue, technician mobile view, work log with parts used, machine history and downtime report. ## Out of scope Spare-parts inventory, preventive maintenance scheduling in phase one, sensor integration. ## Success looks like Every stoppage over 15 minutes recorded; downtime per machine reportable monthly. ## Budget & timeline €30–50k, 10 weeks.
Otwórz w edytorze →
- Produkcja i przemysł🇮🇹91/100
Manutenzione programmata senza fogli di calcolo
Sappiamo che un fermo macchina costa 4.000 € al giorno. Non sappiamo quando arriva.
Przeczytaj brief
# Gestione della manutenzione per uno stabilimento di trasformazione ## Il problema La manutenzione programmata dei nostri 60 impianti vive in un foglio di calcolo aggiornato da una persona sola. Quando quella persona è in ferie, gli interventi programmati semplicemente non partono. Gli interventi straordinari, invece, non vengono registrati affatto: si fanno e si raccontano a voce. Il risultato è che non sappiamo quali macchine ci costano davvero, non riusciamo a dimostrare a un auditor che una manutenzione obbligatoria è stata eseguita, e circa il 40% delle nostre ore di manutenzione è reattiva. Un fermo non programmato ci costa intorno ai 4.000 € al giorno. ## Per chi è - Sette manutentori, che lavorano in reparto con i guanti, spesso accanto alla macchina, con un tablet o un telefono aziendale. - Il responsabile di manutenzione, che pianifica la settimana e deve giustificare il budget. - Il responsabile qualità, che ha bisogno dello storico degli interventi per gli audit di certificazione. ## Cosa esiste oggi Un foglio di calcolo con lo scadenzario, un registro cartaceo in officina per i ricambi prelevati, e i manuali dei costruttori in un armadio. L'anagrafica degli impianti esiste anche nel gestionale, ma è ferma al 2019. ## Perimetro - Anagrafica impianti come unica fonte, con criticità, ubicazione e documentazione allegata. - Piani di manutenzione ricorrenti per calendario e per ore di funzionamento, con generazione automatica degli ordini di lavoro. - Segnalazione guasto dal reparto in meno di un minuto, con foto e codice macchina letto da QR. - Esecuzione dell'ordine di lavoro sul tablet: attività, tempo impiegato, ricambi utilizzati, esito. - Magazzino ricambi con scorta minima e avviso di riordino. - Storico completo per macchina, esportabile per gli audit. ## Fuori perimetro La raccolta dati direttamente dai PLC delle macchine, la manutenzione predittiva basata su modelli, la gestione degli acquisti e il collegamento con la contabilità. Il gestionale aziendale non viene sostituito: l'anagrafica impianti viene allineata una volta e poi mantenuta qui. ## Quando è finito 1. Un manutentore chiude un ordine di lavoro sul tablet in meno di due minuti, con i guanti, senza tastiera. 2. Ogni intervento — programmato o straordinario — risulta a sistema: l'officina non tiene più il registro cartaceo. 3. Per qualsiasi macchina si ottiene lo storico completo degli ultimi due anni in meno di un minuto, in formato esportabile per l'auditor. 4. Le manutenzioni obbligatorie in scadenza sono visibili con almeno due settimane di anticipo e nessuna scade senza che qualcuno sia stato avvisato. ## Vincoli tecnici La copertura wi-fi in reparto è discontinua vicino alle presse: l'applicazione deve funzionare offline e sincronizzare dopo, senza perdere dati. I tablet sono quelli già in dotazione, con schermi da sette pollici e uso obbligatorio dei guanti, quindi servono aree di tocco grandi. L'anagrafica iniziale va importata dal gestionale tramite la sua interfaccia. Hosting in UE. ## Ipotesi e rischi L'ipotesi più fragile è che i piani di manutenzione scritti nel foglio di calcolo corrispondano a quello che si fa davvero in officina: sospettiamo che diverse frequenze siano state adattate a voce negli anni. Una verifica sui dieci impianti più critici andrebbe fatta nelle prime due settimane. Il secondo rischio è l'adozione: se registrare un intervento è più lento che raccontarlo al collega, non verrà registrato, e il progetto fallisce senza che nessuno lo dica. ## Come misuriamo il risultato Ore di manutenzione reattiva dal 40% al 25% entro un anno. Zero manutenzioni obbligatorie scadute. Fermi non programmati sui dieci impianti critici ridotti di un terzo. Storico disponibile per l'audit di certificazione senza preparazione manuale. ## Budget e tempi 50.000–75.000 €, quattro mesi, con anagrafica e ordini di lavoro attivi su una linea come pilota entro dieci settimane.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧91/100
Spare parts ordering from a serial number
Customers phone us to ask which seal fits their machine.
Przeczytaj brief
# Spare parts portal for a machine builder ## The problem We have built around 4,000 machines over twenty years, in dozens of configurations, and the only reliable way for a customer to find the right spare part is to phone our service desk and read out a serial number. Two people answer that phone all day. When they are unavailable, a customer with a stopped machine waits — and a stopped machine is the most expensive thing in their week. About one order in eight is still the wrong part, because the configuration record was read from a scanned paper build sheet. ## Who it's for Maintenance technicians at customer sites, standing next to a stopped machine, on a phone, often with dirty hands and poor signal. Our two service desk staff. Distributors in three countries who order on behalf of their own customers. ## What exists today A parts catalogue as a PDF per machine family, a configuration history in our ERP for machines built after 2016, and scanned paper build sheets for everything older. Orders come by phone and email. ## Scope - Machine lookup by serial number, returning the actual configuration of that machine. - An exploded parts view per assembly, with part numbers, availability and price. - Add to basket and order, with the customer's agreed pricing. - Order history per machine, so a technician can see what was replaced last time. - A service desk view that can correct a machine's configuration record when reality differs from the file. ## Out of scope Service scheduling and dispatch, machine telemetry, warranty claims processing, and new machine sales. Payment stays on invoice terms. ## What "done" means 1. A technician can go from serial number to the correct part in the basket in under two minutes on a phone. 2. Parts shown for a serial number match that machine's configuration — checked against 50 known machines before launch, with the mismatch rate recorded. 3. Availability shown is no more than one hour stale. 4. A wrong configuration can be corrected by the service desk in the portal, and the correction is logged against the machine. ## Constraints The ERP holds configurations for post-2016 machines and is the source of truth for stock and pricing; the portal reads it through its API. Pre-2016 machines have no digital configuration at all — the portal has to degrade gracefully to a machine-family catalogue rather than show nothing. Site signal is often poor, so pages must be light and the parts view usable on a slow connection. ## Risks and assumptions The assumption we are least sure of is the quality of the ERP configuration data. If the mismatch rate against real machines is high, the portal will be blamed for a data problem it inherited, so measuring that rate early is part of the work rather than a nice-to-have. ## Success looks like Half of spare parts orders placed without contacting the service desk within six months. Wrong-part orders down from one in eight to under one in twenty-five. Service desk phone volume down enough that one of the two can move to field support. ## Budget and timeline €55,000–85,000, five months, with serial-number lookup and one machine family live at three months.
Otwórz w edytorze →
- Produkcja i przemysł🇬🇧91/100
Promise a delivery date we can keep
Sales promises six weeks. Production finds out later.
Przeczytaj brief
# Order promising for a made-to-order manufacturer ## The problem When a customer asks when they can have their order, sales gives a number based on habit and optimism. Production learns about the commitment when the order lands in the queue, by which point the promise is already made. We hit our promised date about 62% of the time. The cost of that is not just apology emails: we expedite, we run overtime, and we bump other customers' orders to rescue the loud one, which makes the next promise worse. ## Who it's for Five people in sales, quoting on the phone while a customer waits, who need an answer in seconds and will not use a tool that takes minutes. Two production planners who own the schedule. The works manager, who needs to see what a promise costs before it is given. ## What exists today Capacity lives in a planner's head and a large printed schedule. The ERP knows the order book but has no finite capacity model. Promised dates are typed into the order as free text. ## Scope - A capacity model per work centre, fed from the ERP's routing data and actual throughput. - An available-to-promise calculation: given a product, a quantity and today's load, what is the earliest realistic date and what is the confidence in it. - A quoting screen for sales: enter product and quantity, get a date, optionally reserve capacity for 48 hours while the customer decides. - A planner view showing committed versus available capacity per week, and which promises are at risk. - Recording of promised versus actual, so the model can be calibrated against reality. ## Out of scope Detailed shop-floor scheduling and sequencing, purchasing and materials planning, and replacing the ERP. We are also not automating the promise: a planner can always override, and the tool should make that override visible rather than prevent it. ## What "done" means 1. A salesperson gets a date in under five seconds during a live call. 2. A reserved slot actually removes that capacity from the next quote, so two salespeople cannot sell the same week twice. 3. The planner view shows at-risk promises at least two weeks before the due date. 4. Promised-versus-actual is recorded for every order and reportable, so the hit rate is measurable rather than remembered. ## Constraints The ERP holds routings and the order book and stays the system of record; the model reads from it. Routing times in the ERP are known to be optimistic, so the model must be able to apply a per-work-centre correction factor derived from actuals rather than trusting the standard times. It runs in the browser, on the machines sales already have. ## Risks and assumptions The core assumption is that our throughput is predictable enough to model at all — for some work centres it will be, for the two manual assembly cells it may not, and we would rather the tool say "low confidence" than give a false number. The second risk is behavioural: if sales can override the date without friction, they will, and the hit rate will not move. Making overrides visible to the works manager is part of the design for that reason. ## Success looks like On-time delivery against promised date from 62% to above 85% within a year. Expediting costs down. Sales able to answer a delivery question on the first call rather than "let me check and call you back". ## Budget and timeline €65,000–95,000 over four months, with one product family modelled and running alongside the current process before we switch.
Otwórz w edytorze →
- Produkcja i przemysł🇸🇪94/100
Spårbarhet och avvikelser i legotillverkningen
En reklamation tar oss tre dagar att utreda, och vi hittar sällan vilken charge det gällde.
Przeczytaj brief
# Spårbarhet från materialcharge till levererad detalj ## Problemet Vi är ett familjeägt legotillverkande verkstadsföretag med 45 anställda som skär, svetsar och ytbehandlar detaljer åt fordons- och energiindustrin. När en kund reklamerar ska vi kunna visa vilket material detaljen tillverkades av, vem som körde vilken operation och vilka mätvärden som togs. I dag tar en sådan utredning tre arbetsdagar, och i vart fjärde fall kan vi inte peka ut materialchargen alls — då svarar vi med en kreditnota i stället för ett svar. Förra året kostade det 380 000 kr i krediteringar vi inte kunde bestrida. Avvikelser skrivs på papperslappar som ibland når kvalitetsavdelningen: vi har uppenbart fler än de 60 som registrerades. ## Vem det är till för - Tolv operatörer, som står vid maskinen med handskar och inte kan lämna sin plats för att logga in på en dator. - Beredaren, som lägger upp arbetsordrar och i dag skriver ut följesedlar på papper. - Kvalitetsansvarig, som är ensam om att hålla ihop avvikelserna och svara kunden. - Platschefen, som varje måndag ska veta vad kassationerna kostade. ## Vad som finns i dag Affärssystemet innehåller arbetsordrar och lagersaldon men ingen koppling mellan charge och tillverkad detalj. Materialintygen kommer som pdf i en delad mapp, sorterad på leverantörens ordernummer. Mätprotokoll skrivs för hand och skannas in en gång i veckan. Avvikelser lever i papperslappar och i kvalitetsansvarigs eget kalkylblad. ## Omfattning - Materialchargen registreras vid godsmottagning genom att intyget kopplas till chargenumret, en gång, med skanning av leverantörens etikett. - Arbetsordern följs digitalt genom verkstaden: varje operation kvitteras med operatör, tidpunkt och maskin. - Operatören kopplar den charge hen faktiskt tar ur stället, inte den som var planerad. - Mätvärden och egenkontroll registreras direkt i operationen, med möjlighet att fotografera. - Avvikelse kan skapas från maskinen på under en minut, med foto och orsakskod. - Spårbarhetsrapport per levererad detalj eller per charge, som pdf. ## Uttryckligen utanför omfattning Vi byter inte affärssystem: kalkylering, inköp, fakturering och lönerapportering ligger kvar. Vi hämtar inte data direkt ur maskinernas styrsystem i den här etappen, och vi bygger ingen kundportal — kunden får sin rapport som fil, av en människa. ## När det är klart 1. En operatör kvitterar en operation och kopplar en charge på under 30 sekunder, med handskar på, utan tangentbord. 2. För en godtycklig levererad detalj från de senaste 24 månaderna får kvalitetsansvarig fram materialintyg, operationshistorik och mätvärden på under fem minuter, utan att fråga någon. 3. Alla avvikelser registreras i systemet; verkstaden har slutat använda papperslappar och kalkylbladet är avvecklat. 4. Platschefen får varje måndag en sammanställning av kassationer och avvikelser för föregående vecka utan manuellt arbete. 5. Arbetsordrar och artiklar läses in från affärssystemet automatiskt varje natt, och en ny order syns i verkstaden dagen efter att den lagts upp. ## Tekniska förutsättningar Wi-fi är svagt vid ytbehandlingen, så lösningen måste fungera offline och synkronisera efteråt utan att tappa kvitteringar. Terminalerna är de industripaneler som redan sitter vid maskinerna; touchytorna måste träffas med handskar. Integration mot affärssystemet sker via dess API, läsning i den här etappen. Drift inom EU. Personuppgifterna är anställdas namn och tidpunkter; kvitteringar får inte användas för individuell prestationsmätning, vilket ska framgå av behandlingen enligt GDPR och vara förankrat med facket. Gränssnittet ska uppfylla WCAG 2.1 AA, med särskild vikt vid kontrast i verkstadsbelysning. ## Antaganden och risker Det bräckligaste antagandet är att operatörerna tar materialet ur det ställ arbetsordern anger. Vi misstänker att man ofta tar det som ligger överst, och hela spårbarheten faller om kopplingen görs på planerad i stället för verklig charge. Den organisatoriska risken är att kvitteringar uppfattas som övervakning; om skyddsombudet inte är med från början står terminalerna oanvända, och ingen kommer att säga det högt. ## Så mäter vi resultatet Utredningstid vid reklamation från tre dagar till under en halv dag. Andel reklamationer där chargen inte går att spåra från 25 % till noll. Krediteringar utan teknisk grund från 380 000 kr till under 100 000 kr på ett år. Registrerade avvikelser går upp från 60 till minst 200 — det är avsikten, inte ett misslyckande. ## Budget och tidplan 60 000–85 000 €, fem månader, med spårbarhet och avvikelser i drift på en av tre produktionslinjer som pilot efter tio veckor.
Otwórz w edytorze →
- Produkcja i przemysł🇵🇱92/100
Kontrola jakości bez papierowych kart pomiarowych
Reklamacja przychodzi po trzech miesiącach, a my szukamy karty pomiarowej w segregatorze przez dwa dni.
Przeczytaj brief
# Rejestracja kontroli jakości i identyfikowalności partii w zakładzie obróbki metali ## Problem Jesteśmy rodzinną firmą produkcyjną, 85 osób, obróbka skrawaniem i spawanie komponentów dla motoryzacji i maszyn rolniczych. Każda partia ma kartę pomiarową wypełnianą długopisem przez operatora i podpisywaną przez kontrolera. Karty trafiają do segregatorów w biurze jakości. Kiedy klient zgłasza reklamację — a zgłasza średnio 14 razy w roku — odnalezienie kart dla wskazanej partii zajmuje od kilku godzin do dwóch dni, a w mniej więcej co piątym przypadku karta jest nieczytelna albo jej po prostu nie ma. W ubiegłym roku dwie reklamacje przyjęliśmy bez dyskusji tylko dlatego, że nie potrafiliśmy udowodnić, że pomiar w ogóle został wykonany. Kosztowało nas to około 60 000 zł i jeden audyt klienta zakończony zaleceniem. Nie wiemy też, które operacje generują najwięcej braków, bo braki liczymy raz w miesiącu, zbiorczo, z kartek zbieranych z hali. ## Dla kogo - Dwunastu operatorów na trzech zmianach, którzy wpisują pomiary przy maszynie, w rękawicach, często z zaolejonymi dłońmi i bez dostępu do biurka. - Trzech kontrolerów jakości, którzy zwalniają partię i muszą mieć pewność, że komplet pomiarów istnieje, zanim wyrób pojedzie do klienta. - Kierownik jakości, który przygotowuje dokumentację na audyty klienckie i na recertyfikację systemu zarządzania jakością. - Kierownik produkcji, który chce wiedzieć, na której operacji tracimy materiał. ## Co mamy dziś Papierowe karty pomiarowe w segregatorach z ostatnich pięciu lat, arkusz kalkulacyjny z miesięcznym zestawieniem braków, wewnętrzny system ERP, w którym są zlecenia produkcyjne i indeksy wyrobów, oraz suwmiarki i mikrometry z odczytem cyfrowym, których nikt nie podłącza do niczego. ## Zakres - Elektroniczna karta kontrolna powiązana ze zleceniem produkcyjnym pobieranym z ERP, z listą punktów pomiarowych i tolerancjami dla danego indeksu. - Wprowadzanie pomiaru na tablecie przy stanowisku, z natychmiastową informacją, czy wynik mieści się w tolerancji. - Rejestracja braku z przyczyną wybieraną ze słownika i zdjęciem detalu. - Blokada zwolnienia partii, jeżeli brakuje wymaganych pomiarów. - Wyszukanie pełnej historii partii po numerze zlecenia lub numerze partii materiału wsadowego. - Eksport dokumentacji partii do pliku PDF na potrzeby reklamacji i audytu. - Raport braków według operacji, maszyny i zmiany. ## Poza zakresem Nie automatyzujemy odczytu z przyrządów pomiarowych, nie robimy statystycznego sterowania procesem z kartami regulacyjnymi, nie ruszamy planowania produkcji ani gospodarki magazynowej. ERP zostaje: zlecenia i indeksy nadal powstają tam, a nowe narzędzie tylko je czyta. Nie zajmujemy się też e-fakturowaniem w KSeF — to osobny temat po stronie księgowości. ## Kiedy uznajemy projekt za zakończony 1. Operator wprowadza komplet pomiarów dla jednej sztuki w mniej niż 90 sekund, w rękawicach, bez używania klawiatury sprzętowej. 2. Dla dowolnej partii z ostatnich dwunastu miesięcy pełna dokumentacja pomiarowa powstaje jako plik PDF w mniej niż jedną minutę, bez udziału biura jakości. 3. Żadna partia nie może zostać zwolniona, jeśli brakuje choćby jednego wymaganego pomiaru; próba takiego zwolnienia zostaje odrzucona i odnotowana. 4. Hala przestaje wypełniać papierowe karty pomiarowe — przez pełny miesiąc do biura jakości nie trafia ani jedna. 5. Raport braków według operacji i zmiany jest dostępny w każdej chwili, bez ręcznego przepisywania danych. ## Ograniczenia techniczne Zasięg sieci bezprzewodowej na hali zanika przy stanowiskach spawalniczych, więc aplikacja musi działać w trybie offline i synchronizować dane po odzyskaniu połączenia, bez utraty wpisów. Tablety mają ekrany ośmiocalowe i są obsługiwane w rękawicach, co wymusza duże pola dotykowe. Zlecenia i indeksy pobieramy z interfejsu naszego ERP, który udostępnia dane tylko w sieci lokalnej. Hosting w Unii Europejskiej. Interfejs w języku polskim i ukraińskim, ponieważ część operatorów nie posługuje się swobodnie polskim. Dostępność co najmniej na poziomie WCAG 2.1 AA, ze szczególną uwagą na kontrast w oświetleniu hali. ## Założenia i ryzyka Najbardziej kruche założenie: że tolerancje zapisane w dokumentacji technicznej odpowiadają temu, co kontrolerzy faktycznie mierzą. Podejrzewamy, że dla części indeksów punkty pomiarowe były zmieniane ustnie i nigdy nie trafiły do rysunku. Weryfikację dwudziestu najczęściej produkowanych indeksów trzeba zrobić w pierwszych trzech tygodniach. Ryzyko organizacyjne jest oczywiste: jeśli wpisanie pomiaru na tablecie potrwa dłużej niż zapisanie go długopisem, operatorzy będą notować na kartce i przepisywać na koniec zmiany, a wtedy dane stracą wiarygodność i projekt się przewróci, choć formalnie zostanie odebrany. Dane osobowe ograniczamy do imienia, nazwiska i identyfikatora pracownika przy wpisie; rejestr czynności przetwarzania i okres retencji trzeba uzgodnić z inspektorem ochrony danych, a system nie może służyć do oceny wydajności poszczególnych osób. ## Jak mierzymy efekt Czas skompletowania dokumentacji reklamacyjnej z dwóch dni do jednej godziny. Udział reklamacji przyjętych z powodu braku dowodu pomiaru z dwóch rocznie do zera. Braki wewnętrzne z obecnych 3,1% do 2,2% w ciągu roku od wdrożenia, dzięki temu, że wreszcie zobaczymy, gdzie powstają. Zero niezgodności dokumentacyjnych na najbliższym audycie klienta. ## Budżet i harmonogram 55 000–80 000 €, pięć miesięcy. Pierwszy kamień milowy: elektroniczna karta pomiarowa działająca na jednym gnieździe obróbczym na dwóch zmianach po dziesięciu tygodniach, z papierem prowadzonym równolegle przez ostatnie dwa tygodnie pilotażu.
Otwórz w edytorze →
- Produkcja i przemysł🇫🇮92/100
Työmääräin ja tuntien seuranta alihankintakonepajaan
Tarjoamme työn tunneilla, joita kukaan ei mittaa, ja huomaamme virheen vasta tilinpäätöksessä.
Przeczytaj brief
# Työmääräimet ja todelliset tunnit ohutlevykonepajassa ## Ongelma Teemme ohutlevyosia alihankintana, noin 900 työmääräintä vuodessa, ja hinnoittelemme ne arvioiduilla tunneilla. Todellisia tunteja ei kirjata työvaiheelle vaan päivälle, joten emme tiedä, mikä työ oli kannattava. Viime tilikaudella kolme suurinta asiakastyötä osoittautuivat tilinpäätöksessä tappiollisiksi yhteensä noin 40 000 eurolla, eikä kukaan pysty jälkikäteen sanomaan, meninkö arvio pieleen särmäyksessä vai hitsauksessa. Työmääräin kulkee tuotannossa paperilappuna, joka häviää keskimäärin kerran viikossa, ja silloin työ tehdään uudestaan tai piirustuksen versio arvataan. Asiakkaan kysyessä toimitusajankohtaa vastaus perustuu työnjohtajan muistiin. ## Keille tämä on - Neljätoista koneistajaa, särmääjää ja hitsaajaa, jotka työskentelevät seisten, hanskat kädessä ja kuulosuojaimet päässä, ja joilla ei ole omaa työasemaa. - Työnjohtaja, joka jakaa työt vuoron alussa ja lupaa toimituspäivät. - Laskennasta vastaava, joka tekee tarjoukset ja tarvitsee toteutuneita tunteja seuraavaan tarjoukseen. - Laatuvastaava, joka tarvitsee jäljitettävyyden materiaalieräkohtaisesti asiakkaan auditointia varten. ## Mitä on tänään Toiminnanohjaus, jossa tilaukset, ostot ja verkkolaskutus ovat kunnossa, mutta jonka tuotannonohjausosaa ei ole koskaan otettu käyttöön. Käytännössä työjono on tulostettu lista työnjohtajan pöydällä, työmääräin on paperi työn mukana, tunnit kirjataan päivän lopuksi paperiselle tuntilistalle ja siirretään taulukkolaskentaan palkanlaskentaa varten. Piirustukset ovat verkkolevyllä kansiorakenteessa, jossa on sekä vanhoja että voimassa olevia versioita. ## Laajuus - Digitaalinen työmääräin: työvaiheet järjestyksessä, materiaali, määrä, voimassa oleva piirustusversio liitteenä. - Työpistepääte tuotannossa: työvaiheen aloitus ja lopetus kahdella painalluksella, työmääräin luetaan QR-koodilla. - Vaihekohtainen tuntikirjaus, joka erottaa asetusajan ja ajoajan. - Työjonon näkymä työnjohtajalle: mikä on koneella, mikä odottaa, mikä on myöhässä. - Jälkilaskenta työmääräimelle: arvioidut tunnit vastaan toteutuneet, vaiheittain. - Materiaalierän ja sulatusnumeron kirjaus työmääräimelle jäljitettävyyttä varten. - Tuntien vienti palkanlaskentaan hyväksyttynä koosteena. ## Rajaus Emme rakenna kapasiteetin automaattista optimointia emmekä äärellisen kapasiteetin ajoitusta — työnjohtaja päättää järjestyksen jatkossakin. CAM-ohjelmien, koneiden ohjausjärjestelmien tai mittalaitteiden liittäminen, tarjouslaskennan automatisointi ja varaston täydellinen hallinta jäävät ulkopuolelle. Toiminnanohjausta ei korvata: tilaukset ja nimikkeet luetaan sieltä ja jälkilaskennan tulos palautetaan sinne. ## Milloin työ on valmis 1. Työntekijä aloittaa ja lopettaa työvaiheen alle kymmenessä sekunnissa hanskat kädessä, ilman kirjautumista salasanalla. 2. Paperisia työmääräimiä ei ole tuotannossa kuukauden ajan, eikä yksikään työ jää tekemättä kadonneen lapun takia. 3. Minkä tahansa valmistuneen työmääräimen arvioidut ja toteutuneet tunnit näkee vaiheittain alle minuutissa. 4. Työnjohtaja näkee myöhässä olevat työt yhdeltä näytöltä ilman, että hän kysyy tilannetta koneelta. 5. Mille tahansa toimitetulle erälle löytyy materiaalin sulatusnumero alle kahdessa minuutissa auditoinnissa. 6. Työpistepäätteen käyttöliittymä täyttää WCAG 2.1 AA -tason ja on luettavissa kolmen metrin päästä hallin valaistuksessa. ## Tekniset reunaehdot Hallin langaton verkko katkeaa hitsauspaikkojen lähellä, joten päätteen on jonotettava kirjaukset ja lähetettävä ne yhteyden palattua. Päätteinä käytetään halpoja kosketusnäyttöjä, joita voi puhdistaa; kirjautuminen tapahtuu henkilökortin RFID-tunnisteella, ei näppäimistöllä. Toiminnanohjauksen rajapinta on olemassa, mutta sitä on käytetty vain lukemiseen. Palvelinympäristö EU:ssa. Kaksi vanhinta CNC-konetta ei ole verkossa eikä niitä liitetä. ## Oletukset ja riskit Hauraimmat oletus on, että nykyiset työvaiheet toiminnanohjauksessa vastaavat sitä, mitä hallissa oikeasti tehdään: epäilemme, että vaiheita on yhdistetty ja ohitettu vuosien varrella, ja tämä on tarkistettava viidellä yleisimmällä tuoterakenteella ensimmäisen kuukauden aikana. Organisatorinen riski on ilmeinen: tuntikirjaus koetaan helposti valvonnaksi. Jos siitä ei sovita luottamusmiehen kanssa etukäteen ja jos kirjaus kestää kauemmin kuin paperilista, tunnit kirjataan päivän lopuksi arvaamalla ja jälkilaskennan luvut ovat yhtä hyödyttömiä kuin nyt. Kolmas riski on piirustusversiot: jos verkkolevyn siivousta ei tehdä, väärä versio päätyy työmääräimelle. ## Miten mittaamme Tarjouksen ja toteutuman ero kolmen suurimman tuoteryhmän osalta alle 10 prosenttiin nykyisestä yli 30 prosentista vuoden sisällä. Kadonneet työmääräimet noin 50:stä nollaan vuodessa. Tuntilistojen käsittelyyn kuluva toimistotyö kuudesta tunnista alle tuntiin viikossa. Toimitusvarmuus 82 prosentista 93 prosenttiin. ## Henkilötiedot Järjestelmä käsittelee työntekijöiden työaikatietoa. Käsittelyperuste, säilytysaika ja se, kuka näkee yksittäisen työntekijän tunnit, on määriteltävä kirjallisesti ja käsiteltävä yhteistoimintamenettelyssä. Tuotannon näytöillä ei näytetä henkilökohtaisia tehokkuuslukuja. ## Budjetti ja aikataulu 60 000–85 000 €, neljä kuukautta, ja kaksi työpistettä sekä särmäyssolu pilotissa oikeilla työmääräimillä kahdeksassa viikossa.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧84/100
Proof of delivery without paper notes
Drivers hand back a stack of signed slips every evening.
Przeczytaj brief
# Driver app with proof of delivery ## What we want A driver app showing the day's stops, with signature, photo and reason-for-failure capture, plus a live view for dispatch. ## Who it's for 18 drivers with mixed Android phones; two dispatchers; customers who ask where their delivery is. ## What exists today Routes are printed. Signed delivery notes are scanned the next morning. Disputes take days to resolve. ## Scope Route list, stop detail, signature and photo capture, failure reasons, offline queue with sync, dispatch dashboard, delivery confirmation email with proof attached. ## Out of scope Route optimisation, telematics, customer tracking page (phase two). ## Success looks like Proof available within minutes of delivery; scanning work eliminated; disputes resolved same day. ## Budget & timeline €50–80k, pilot with three drivers in 8 weeks.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧82/100
Schedule 20 technicians without a whiteboard
Dispatch is one person, one Excel file and a phone.
Przeczytaj brief
# Field service scheduling ## What we want A scheduling board for installation and repair jobs, with skills and travel taken into account, and a technician mobile view. ## Who it's for 20 heating technicians, one dispatcher, the office team booking appointments. ## What exists today An Excel week grid. Rescheduling means a round of phone calls. Roughly 90 jobs a week. ## Scope Job intake, drag-and-drop scheduling board, skill and region matching, technician app with job detail and time logging, customer SMS confirmation, weekly utilisation report. ## Out of scope Parts inventory, invoicing (goes to our accounting package), route optimisation algorithms. ## Success looks like Rescheduling takes minutes, not an afternoon; travel time per job down 15%. ## Budget & timeline €60–95k, 4 months.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧77/100
Book a slot at the loading dock
Trucks queue for two hours because everyone arrives at nine.
Przeczytaj brief
# Dock and yard slot booking ## What we want A booking system where hauliers reserve a loading slot, and the yard sees arrivals and delays live. ## Who it's for Around 120 haulier contacts, the yard team and two warehouse shift leads. ## What exists today Slots are agreed by phone and written on a whiteboard. Average waiting time is 95 minutes; we pay demurrage. ## Scope Slot calendar per dock, haulier self-booking with reference number, check-in (QR or gate screen), yard live board, no-show and delay handling, weekly waiting-time report. ## Out of scope Gate hardware and barriers, ANPR cameras, WMS changes. ## Success looks like Average waiting time under 30 minutes; 70% of arrivals pre-booked within four months. ## Budget & timeline €40–70k, 3 months.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧79/100
One page that tells customers where their order is
Half our support calls are 'where is it?'
Przeczytaj brief
# Order tracking page ## What we want A tracking page per order that pulls status from our ERP and our two carriers, reachable from a link in the confirmation email. ## Who it's for Customers (about 400 orders a week) and our three-person support team. ## What exists today Customers call or email. Support checks three systems to answer. Around 60% of tickets are status questions. ## Scope Status model, ERP and carrier integrations, public tracking page, proactive email or SMS on status change, support view with the same data. ## Out of scope Account area, returns, marketing content. ## Success looks like Status tickets down by half within three months. ## Budget & timeline €25–40k, 8 weeks.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧79/100
Site diaries and photos, filed automatically
Foremen send photos over WhatsApp and we lose them.
Przeczytaj brief
# Construction site diary ## What we want A mobile site diary: daily entry per site with weather, crew, work done, photos and issues, filed against the project. ## Who it's for Nine site foremen, two project managers, the office administrator preparing client reports. ## What exists today WhatsApp groups and a Word template nobody fills in. Client reports are reconstructed from memory at month end. ## Scope Site and project setup, daily entry form, photo capture with automatic project tagging, issue log with assignee, weekly PDF report per project, offline capture. ## Out of scope Cost tracking, timesheets for payroll, BIM or CAD integration. ## Success looks like A diary entry for every site every working day; client reports generated, not written. ## Budget & timeline €35–60k, 3 months.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧89/100
Customs paperwork ready before the truck leaves
Every export shipment waits on a document somebody types twice.
Przeczytaj brief
# Export documentation and declarations ## The problem Every export shipment we handle needs the same set of documents, and every one of them is assembled by hand from the same source data typed into three different places. A shipment that is physically ready sits on the dock because a document is wrong or missing. Corrections cost us roughly two hours each and about one shipment in twelve needs one. Worse, when a customs authority queries a declaration months later, reconstructing what we submitted means searching a mailbox. ## Who it's for Six people in our documentation team, who currently spend most of the day re-keying. Operations staff on the dock who need to know whether a load is cleared to move. Customers, who want to see the status of their own shipment without emailing us. ## What exists today Shipment data lives in our transport management system. Documents are produced in a word processor from templates, and declarations are typed into the customs authority's own web portal separately. Copies are emailed and archived in mailbox folders. ## Scope - One shipment record as the single source for all documentation data. - Automated generation of the standard document set from that record. - Validation before generation: missing commodity codes, weight mismatches and incomplete consignee data are flagged with the specific field, not a generic error. - Submission to the customs authority through its electronic interface rather than by re-typing. - A document archive per shipment with what was submitted, when, and by whom. - A read-only customer view of shipment and clearance status. ## Out of scope Tariff classification advice, duty calculation and payment, warehouse management, and the transport management system itself, which stays as the source of shipment data. ## What "done" means 1. A complete shipment record produces the full document set with no manual typing, verifiable end to end on a real shipment. 2. An incomplete record is refused with the exact missing field named, before anything is generated. 3. A declaration submitted electronically is archived with its acknowledgement reference, retrievable in under a minute for any shipment in the last five years. 4. A customer can see clearance status without contacting us. ## Constraints The customs authority's electronic interface is the mandatory submission channel and its schema changes on a published schedule, so the integration has to be versioned and updated rather than written once. The transport management system exposes shipment data through an API. Archive retention is legally mandated at several years, which shapes storage and export. ## Risks and assumptions We assume the shipment data in the transport system is complete enough to drive documents; our suspicion is that documentation staff have been quietly filling gaps from memory for years, and those gaps will surface as validation failures on day one. That is the point of the tool, but it will feel like a regression for a fortnight and the plan should say so out loud. ## Success looks like Document preparation time per shipment down by two thirds. Corrections down from one shipment in twelve to under one in fifty. Any past declaration retrievable in under a minute. ## Budget and timeline €60,000–90,000, four to five months, with document generation before the electronic submission integration.
Otwórz w edytorze →
- Logistyka i praca w terenie🇬🇧90/100
Route planning that survives a bad morning
One van breaks down and the whole day is replanned on a whiteboard.
Przeczytaj brief
# Daily route planning and re-planning for a regional distributor ## The problem We run 22 vans out of one depot on fixed-ish routes planned the evening before in a spreadsheet. That works until something goes wrong, which is most mornings: a van does not start, a driver calls in sick, or a customer moves a delivery window. Then one dispatcher rebuilds the day on a whiteboard while drivers wait in the yard, and the reallocation is guesswork — we regularly send a van past a stop that another van covered forty minutes later. Customers get a delivery window we cannot honour because nothing recalculates when the plan changes. ## Who it's for One dispatcher and a backup, planning the evening before and firefighting from 06:00. 22 drivers who need their day on a phone and need it to update when it changes. Customer service, who field the "where is my delivery" calls. ## What exists today A spreadsheet per day, printed run sheets handed out in the morning, and a whiteboard for changes. Delivery windows are promised by customer service from a static route map that is three years old. ## Scope - Import of the day's orders from our order system, with delivery windows and service times. - Route optimisation across the fleet accounting for vehicle capacity, driver hours and time windows. - Re-planning during the day: remove a vehicle, add an urgent stop, and get a revised plan in minutes. - A driver view on a phone: the stop list, updating live, with proof of delivery capture. - Estimated arrival windows pushed to customer service and, later, to customers. ## Out of scope Telematics and vehicle tracking hardware, fuel and maintenance management, warehouse picking, and long-haul or inter-depot movements. We are not replacing the order system. ## What "done" means 1. A full day's plan for 22 vehicles is produced in under ten minutes. 2. Removing a vehicle at 06:15 produces a valid revised plan for the remaining fleet before 06:30, with every stop still covered or explicitly flagged as undeliverable today. 3. A driver's phone reflects a change within two minutes without them calling the depot. 4. Estimated arrival windows are accurate to within 30 minutes for 80% of stops, measured against actual proof-of-delivery timestamps. ## Constraints Orders come from our existing order system through a nightly export and an intraday API. Drivers use company phones on mobile data with patchy rural coverage, so the stop list must work offline and sync when signal returns. Driver hours rules are legally binding constraints in the optimisation, not preferences. ## Personal data Driver location and timing data is personal data about employees. We need a stated purpose limited to operations, a short retention period, access restricted to dispatch, and agreement with the works council before launch — this must be designed as an operational tool, not a surveillance one, and the data model should make that difficult to abuse. ## Risks and assumptions We assume our service times per customer are roughly right; they are currently a single flat number and are certainly wrong for the larger accounts, which will make early plans optimistic. Measuring real service times in the first weeks and feeding them back is part of the work. The bigger risk is driver trust: if the app tells them to do something obviously silly once, they will go back to the printed sheet. ## Success looks like Morning replanning from 45 minutes of whiteboard to under 15 minutes. Kilometres per delivery down 10%. "Where is my delivery" calls down by half. ## Budget and timeline €70,000–110,000 over five months, with planning and the driver view first and customer-facing arrival windows last.
Otwórz w edytorze →
- Logistyka i praca w terenie🇳🇱100/100
Ritplanning en temperatuurregistratie voor koeltransport
Onze planning staat in een spreadsheet, de temperaturen op papier, en de klant belt de chauffeur rechtstreeks.
Przeczytaj brief
# Ritplanning en temperatuurregistratie voor een gekoeld distributiebedrijf ## Het probleem Wij zijn een familiebedrijf met 34 gekoelde trekkers en twee distributiecentra en rijden verse zuivel en vlees naar horeca en speciaalzaken. De dagplanning wordt elke avond met de hand in een spreadsheet gezet en daarna via een berichtenapp naar de chauffeurs gestuurd. Zodra er 's ochtends iets verandert — een geannuleerde lossing, een storing, een chauffeur die zich ziek meldt — klopt die planning niet meer en wordt de rest van de dag telefonisch gerepareerd. De planners zijn ongeveer twee uur per dag bezig met bellen. Erger is de registratie: de temperaturen worden per rit op een papieren formulier genoteerd en pas dagen later ingescand. Bij de laatste audit konden we van 11 van de 40 gecontroleerde ritten de koelketen niet aantonen, en één klant heeft daarop een lading van ruim 6.000 euro afgekeurd. ## Voor wie is het - Drie planners op kantoor, die tussen 05.30 en 08.00 uur de dag rechtzetten terwijl de telefoon doorlopend gaat. - Ongeveer veertig chauffeurs, die op de bok werken met handschoenen aan, vaak in de vrieszone, en die geen tweede apparaat willen naast de boordcomputer. - De kwaliteitsmanager, die de HACCP-registratie moet kunnen overleggen aan de nationale voedselautoriteit en aan klantauditoren. - De klantenservice, die nu geen antwoord heeft op de vraag "waar is mijn zending". ## Wat er nu is Een spreadsheet met de dagplanning, berichtenappgroepen per regio, papieren temperatuurformulieren, en een transportadministratie waarin ritten pas achteraf worden vastgelegd voor de facturatie. De koelmotoren loggen zelf, maar die logs worden alleen uitgelezen als er een klacht is. ## Scope - Eén planbord waarop de dagplanning wordt gemaakt en gewijzigd, met de wijziging direct zichtbaar bij de chauffeur. - Een chauffeursapp met de ritlijst, adressen, laad- en losinstructies en digitale aftekening bij ontvangst. - Temperatuurregistratie per zending: uitlezing van de koelmotor waar mogelijk, handmatige meting waar dat niet kan, met tijdstip en locatie. - Automatisch afwijkingsalarm bij overschrijding van de ingestelde bandbreedte, met melding aan planner en kwaliteitsmanager. - Een exportbestand per klant, per periode, met alle temperatuurregistraties en afleverbewijzen. - Doorgifte van de gereden ritten naar de transportadministratie voor de facturatie. ## Nadrukkelijk buiten scope Automatische routeoptimalisatie, tariefberekening, loonadministratie en rittenregistratie voor de belastingdienst. Wij vervangen de bestaande transportadministratie niet: die blijft leidend voor facturen en debiteuren. Ook de planning van het wagenparkonderhoud valt erbuiten. ## Wanneer is het klaar 1. Een planner verplaatst een lossing naar een andere rit en de betrokken chauffeur ziet die wijziging binnen dertig seconden op zijn scherm, zonder telefoontje. 2. Een chauffeur tekent een levering af en legt een temperatuur vast in minder dan één minuut, met handschoenen aan, zonder toetsenbord. 3. Van elke rit van de afgelopen achttien maanden is binnen één minuut een temperatuurrapport te downloaden dat een auditor zonder toelichting accepteert. 4. Een temperatuuroverschrijding van meer dan dertig minuten leidt tot een melding bij de planner terwijl de vrachtwagen nog onderweg is. 5. De papieren temperatuurformulieren zijn uit het proces verdwenen. ## Technische randvoorwaarden Op de route valt het mobiele netwerk regelmatig weg, onder andere in de aanrijroutes van twee grote distributiecentra: de app moet offline werken en later synchroniseren zonder registraties te verliezen. De boordcomputers zijn er al en blijven; koppeling gebeurt via de bestaande interface van de leverancier. De transportadministratie ontsluit ritten via een API. Hosting binnen de EU. ## Aannames en risico's De kwetsbaarste aanname is dat de koelmotoren van alle 34 trekkers hun data op dezelfde manier beschikbaar stellen — ons wagenpark bestaat uit drie generaties en wij vermoeden dat de oudste tien dat niet doen. Dat moet in de eerste drie weken op echte voertuigen worden getest, niet op documentatie. Het organisatorische risico is de acceptatie bij de chauffeurs: de gemiddelde leeftijd is 52 en de berichtenappgroepen werken in hun beleving prima. Als vastleggen langer duurt dan even bellen, gebeurt het niet. ## Hoe we het resultaat meten Telefonische planwijzigingen van ongeveer twee uur per planner per dag terug naar een half uur. Ritten zonder complete temperatuurregistratie van 27 procent naar minder dan 2 procent binnen zes maanden. Geen afgekeurde ladingen meer wegens niet aantoonbare koelketen. Doorlooptijd van een klantvraag over een levering van een dag naar een minuut. ## Privacy en toegankelijkheid Locatie- en rijtijdgegevens zijn persoonsgegevens van chauffeurs: bewaartermijnen, doelbinding en inzagerecht worden vooraf vastgelegd in overleg met de ondernemingsraad, conform de AVG. De kantoorschermen voldoen aan WCAG 2.2 niveau AA. ## Budget en planning € 60.000 – € 90.000, vijf maanden, met één regio en tien voertuigen als pilot live binnen tien weken.
Otwórz w edytorze →
- Logistyka i praca w terenie🇩🇰94/100
Styr på returemballagen mellem lager og kunde
Vi køber 4.000 nye rullecontainere om året, fordi ingen ved hvor de gamle står.
Przeczytaj brief
# Sporing af paller og rullecontainere i en grossistvirksomheds distribution ## Problemet Vi distribuerer kølevarer og kører knap 40 daglige ruter fra to lagre ud til omkring tusind butikker og storkøkkener. Varerne kører på rullecontainere og europaller, som skal komme retur. Det gør de kun delvist. Sidste år købte vi 4.000 nye rullecontainere for cirka 2,4 mio. kr., ikke fordi flåden voksede, men fordi vi ikke kan gøre rede for, hvor de står. Chaufføren noterer udvekslet emballage på følgesedlen med kuglepen, og tallet indtastes — når nogen har tid — i et regneark tre dage senere. Afstemningen med kunderne sker kvartalsvis og ender næsten altid i en diskussion, vi taber, fordi vores eget tal er skrevet i hånden. Vi ved ikke, hvilke kunder der står for hovedparten af svindet. ## Hvem det er til for - 38 chauffører, der læsser af på rampe eller fortov, ofte i regn og med handsker, og har under fem minutter pr. stop. - Modtageren i butikken, som skal kvittere uden en app og uden at kende os. - To lagerformænd, der tæller tomme enheder ved returporten om aftenen. - Kundeservice, der skal svare på en emballagereklamation, mens kunden er i røret. - Økonomi, der skal fakturere manglende emballage og i dag ikke tør, fordi dokumentationen ikke holder. ## Hvad der findes i dag Følgesedler i tre gennemslag, et regneark pr. lager med emballagekonti, og chaufførernes håndholdte terminaler, som i dag kun scanner varelinjer og registrerer ankomsttid. Transportstyringssystemet kender ruter, stop og leverancer, men har intet begreb om emballage. Kvartalsafstemningen laves i hånden af én person over tre dage. ## Omfattning - Registrering af udvekslet emballage på stoppet: leveret og retur antal pr. emballagetype, på chaufførens eksisterende terminal. - Digital kvittering fra modtageren på terminalens skærm, med navn og tidspunkt. - Emballagekonto pr. kunde, der opdateres samme dag, ikke pr. kvartal. - Selvbetjeningsoversigt, hvor kunden ser sin saldo og 12 måneders bevægelser via et link, uden brugeroprettelse. - Optælling ved returporten om aftenen, der afstemmer flådens fysiske antal mod summen af konti. - Afvigelsesrapport, der udpeger de kunder og ruter, hvor svindet er størst. - Fakturagrundlag for manglende emballage, klar til vores økonomisystem. ## Udtrykkeligt uden for opgaven Vi skifter ikke transportstyringssystem, og ruteplanlægning, temperaturlogning og varefakturering ligger uden for. Vi sætter ikke elektroniske mærker på emballagen i denne etape — den beslutning skal træffes på de data, løsningen giver os. Der bygges ingen app, kunden skal installere, og ingen integration mod kundernes varemodtagelsessystemer. ## Hvornår er det færdigt 1. En chauffør registrerer emballageudveksling og får kvittering på under 45 sekunder, stående udenfor med handsker på, uden at skrive tekst. 2. Registreringen virker uden mobildækning og synkroniserer af sig selv, når terminalen igen har net. 3. En kundes emballagesaldo er opdateret senest kl. 23 samme dag som leveringen. 4. Kundeservice kan under en telefonsamtale fremvise kvitteringen med modtagerens underskrift på under 30 sekunder. 5. Kvartalsafstemningen gennemføres på under fire timer, og opgørelsen er den samme, kunden selv kan se. 6. Det gamle regneark er ude af drift, og ingen emballagetal indtastes manuelt. ## Tekniske forudsætninger Terminalerne er robuste håndholdte enheder fra 2021 med 4 tommers skærm; der indkøbes ingen nye. Store trykflader er et krav, da registreringen sker med handsker. Kølelagre og mange bagerum har ingen mobildækning, så offline-drift med senere synkronisering er en forudsætning, ikke en forbedring. Transportstyringssystemet leverer stop og leverancer via en natlig eksport, hvis format vi ikke kan ændre. Fakturagrundlaget skal kunne indlæses af vores økonomisystem, og fakturaer til offentlige storkøkkener skal dannes i det obligatoriske danske e-fakturaformat. Drift i EU. Modtagerens navn og underskrift er personoplysninger og behandles efter GDPR med sletning efter 24 måneder, som er vores reklamationsfrist. Selvbetjeningsoversigten skal opfylde WCAG 2.1 AA. ## Antagelser og risici Den skrøbeligste antagelse er, at modtageren i butikken vil kvittere på en skærm. I dag skriver mange slet ikke under, og chaufføren kører videre for at nå ruten; bliver kvittering frivillig i praksis, får vi de samme usikre tal, blot hurtigere. Det bør prøves af på én rute med ærlige tal, før vi ruller ud. Den organisatoriske risiko er, at chaufførerne aflønnes efter antal stop. Ethvert ekstra sekund går fra deres tid, og justeres akkorden ikke, bliver registreringen udfyldt med standardtal frem for de faktiske. ## Sådan måler vi resultatet Indkøb af nye rullecontainere fra 4.000 til under 1.500 om året. Uafklaret emballagedifference ved kvartalsafstemning fra 11 % til under 3 % af flåden. Tid brugt på afstemning fra tre dage til under fire timer pr. kvartal. Emballagereklamationer, hvor vi ikke kan fremlægge dokumentation, til nul. ## Budget og tidsplan 35.000–55.000 €, fire måneder, med registrering og kundekonti i drift på seks ruter fra det ene lager som pilot efter ni uger.
Otwórz w edytorze →
- Logistyka i praca w terenie🇫🇮97/100
Sähköinen rahtikirja ja ajojärjestely jakelukuljetuksiin
Toimituksen kuittaus on paperilla, ja asiakas näkee tilanteen vasta seuraavana aamuna.
Przeczytaj brief
# Jakelukuljetusten kuittaus ja ajojärjestely ilman paperia ## Ongelma Ajamme kolmesta terminaalista noin 140 kappaletavaratoimitusta päivässä, ja toimituksen kuittaus tapahtuu edelleen paperisella rahtikirjalla. Kuljettaja palauttaa paperit illalla, ja ne kirjataan seuraavana aamuna, joten asiakas näkee toimituksen tilan noin vuorokauden myöhässä. Reklamaatioita tulee keskimäärin 25 kuukaudessa, ja joka kolmannessa tapauksessa kuittausta ei löydy lainkaan tai nimi ei ole luettavissa — silloin hyvitämme rahdin riitelemättä, mikä on noin 1 800 € kuukaudessa. Ajojärjestelijä rakentaa reitit aamulla taulukkolaskennassa ja välittää päivän muutokset puhelimitse: kiireisenä päivänä puheluita kertyy yli 60, ja kaksi kertaa viime vuonna sama kuorma ajettiin kahdesti. ## Keille tämä on - Kaksikymmentäkaksi kuljettajaa, jotka työskentelevät ajoneuvon ohjaamossa, usein hanskat kädessä ja kiireessä, ja joiden työaikaa säätelee ajo- ja lepoaikalainsäädäntö. - Kolme ajojärjestelijää, jotka jakavat kuormat aamulla kello viiden ja seitsemän välillä ja korjaavat suunnitelmaa koko päivän. - Asiakaspalvelun kaksi henkilöä, jotka vastaavat "missä kuormani on" -kysymyksiin ja käsittelevät reklamaatiot. - Terminaalityönjohtaja, joka päättää lastausjärjestyksen ja tarvitsee tiedon poikkeamista ennen lähtöä. ## Mitä on tänään Toiminnanohjaus, jossa tilaukset ja laskutus ovat kunnossa — verkkolaskutus toimii ja on ollut käytössä vuosia — mutta jossa ei ole kuljettajan käyttöliittymää. Reittisuunnittelu on taulukkolaskennassa, kuljettajien ohjeet paperinipussa, kuittaukset paperilla ja poikkeamat WhatsApp-ryhmässä. Asiakkaille lähetetään toimitusvahvistus käsin sähköpostilla vain pyydettäessä. ## Laajuus - Kuljettajan mobiilisovellus: päivän kuormat, tehtäväjärjestys, navigointiin siirtyminen, lastaus- ja purkukuittaus. - Sähköinen toimituskuittaus: vastaanottajan allekirjoitus näytöllä tai valokuva, aikaleima ja sijainti. - Poikkeaman kirjaaminen kuvineen: vaurio, puuttuva kolli, vastaanottaja ei paikalla. - Ajojärjestelijän näkymä, jossa kuormat siirretään auton ja vuoron välillä ja muutos näkyy kuljettajalla ilman puhelua. - Asiakkaan seurantalinkki tilauksen tilasta ja arvioidusta toimitusajasta. - Kuittausten haku tilausnumerolla asiakaspalvelun käyttöön. ## Rajaus Emme rakenna optimoivaa reitinlaskentaa emmekä ennustemallia: reitit suunnitellaan jatkossakin ihmisen toimesta, järjestelmä vain esittää ne. Palkanlaskenta, polttoaineraportointi, kaluston huolto ja tullaus jäävät ulkopuolelle. Toiminnanohjausta ei korvata — tilaukset luetaan sieltä ja kuittaukset kirjoitetaan sinne takaisin sen rajapinnan kautta. ## Milloin työ on valmis 1. Kuljettaja kuittaa toimituksen alle 30 sekunnissa hanskat kädessä, ilman että ohjaamosta tarvitsee poistua kirjoittamaan. 2. Kuittaus näkyy asiakaspalvelun haussa alle viidessä minuutissa toimituksesta, myös silloin kun kuljettaja on ollut katvealueella. 3. Paperisia rahtikirjoja ei enää palauteta terminaaliin: kaikki kolme terminaalia toimivat kuukauden ilman paperinippua. 4. Ajojärjestelijä siirtää kuorman autolta toiselle ja molemmat kuljettajat näkevät muutoksen ilman puhelua. 5. Vastaanottaja saa seurantalinkin, joka toimii puhelimen selaimessa ilman kirjautumista ja täyttää WCAG 2.1 AA -tason. ## Tekniset reunaehdot Verkkoyhteys katkeaa säännöllisesti haja-asutusalueiden reiteillä ja terminaalien peltihallien sisällä, joten sovelluksen on toimittava offline-tilassa ja synkronoitava jälkikäteen kadottamatta kuittauksia. Laitteina käytetään olemassa olevia Android-puhelimia, joista vanhimmat ovat neljän vuoden ikäisiä. Tilaukset ja kuittaukset kulkevat toiminnanohjauksen olemassa olevan rajapinnan kautta. Konesalin on sijaittava EU:ssa. ## Oletukset ja riskit Hauraimmat oletus on, että toiminnanohjauksen rajapinta pystyy vastaanottamaan kuittaukset ja liitetiedostot — tätä ei ole koskaan kokeiltu, ja se pitää todentaa ensimmäisten kahden viikon aikana. Toinen riski on organisatorinen: osa kokeneimmista kuljettajista pitää paperia nopeampana, ja jos kuittaus kestää minuutin, se tehdään illalla muistista tai jää tekemättä. Kolmas riski on, että vastaanottajan allekirjoitus näytöllä ei kelpaa kaikille asiakkaille sopimusteknisesti; kolmen suurimman asiakkaan kanta on selvitettävä ennen käyttöönottoa. ## Miten mittaamme Kuittauksen puuttumisesta johtuvat hyvitykset 1 800 eurosta alle 300 euroon kuukaudessa. Asiakaspalvelun "missä kuormani on" -yhteydenotot puoleen nykyisestä. Ajojärjestelijän puhelut kuljettajille yli 60:stä alle 20:een päivässä. Toimituksen tilatieto asiakkaalle vuorokaudesta alle viiteen minuuttiin. ## Henkilötiedot Käsittelemme vastaanottajan nimen, allekirjoituksen ja toimituspaikan sijainnin sekä kuljettajan sijaintitiedon työaikana. Tarvitsemme käsittelyn perusteen ja säilytysajat kirjattuna, kuljettajan sijainnin näkyviin vain työvuoron aikana, ja kuittausaineiston poiston määräajan päätyttyä. GDPR:n mukainen rekisterinpitäjän vastuu on meillä. ## Budjetti ja aikataulu 70 000–95 000 €, viisi kuukautta, ja yksi terminaali sekä kahdeksan autoa pilotissa oikeilla toimituksilla kymmenessä viikossa.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧90/100
Replace the spreadsheet that runs the company
One file, twelve people editing it, nobody trusts it.
Przeczytaj brief
# Internal operations tool for a twelve-person consultancy ## The problem One shared spreadsheet with fourteen sheets and a layer of macros nobody living understands is the operational truth of this company: projects, who is assigned to what, capacity, and what has been invoiced. Twelve people edit it. We get merge conflicts weekly and silently lose edits. Because invoicing is driven from it, a lost edit is a lost invoice — we have found unbilled work months later. Everyone can see everyone's rates and margins because a spreadsheet has no permissions. Preparing a month's invoicing takes our administrator two days of cross-checking. ## Who it's for Three partners who need a portfolio and capacity view. Six project leads who need to see their own projects and staff them. One finance administrator who runs invoicing and needs the numbers to be right. Two associates who just need to know what they are on next week. ## What exists today A single shared spreadsheet on a cloud drive, with macros, manual colour coding as status, and a monthly copy taken as a snapshot. Time tracking lives in a separate tool and stays there. ## Scope - Clients, projects and phases, with a budget and a status per project. - Assignments of people to projects over time, and a weekly capacity view across the team. - Invoicing status per project phase: what is ready to bill, what is billed, what is overdue. - A permission model: finance sees money, project leads see their own projects, associates see their own assignments. Rates are not visible to everyone. - A one-off import of the current spreadsheet. - An export of the billing basis to our accounting tool's import format. ## Out of scope Time tracking, which stays in the tool we already use and is read-only here. CRM and pipeline. Document management. Payroll. We are not building an ERP. ## What "done" means 1. The spreadsheet is retired within one month of launch, verifiable by it being made read-only and nobody asking for it back. 2. A month's invoicing basis is produced in a morning rather than two days, measured on the first full month. 3. An associate logging in cannot see any rate or margin figure — checked by an actual associate account, not by an admin toggling a view. 4. Two people editing the same project at the same time both keep their changes. 5. The historical spreadsheet imports without manual re-keying of project history. ## Constraints It has to export in the import format our accounting tool accepts, and read assignments and actuals from our existing time-tracking tool's API. We are a distributed team, so it is a browser tool with no VPN requirement. EU hosting. ## Risks and assumptions The biggest assumption is that our fourteen sheets encode a model that can be normalised — spreadsheets accumulate exceptions, and we expect the import to surface a dozen "well, except when…" rules that nobody has written down. We would rather that be an explicit discovery week than a surprise. Second risk: partner adoption. If the partners keep a private sheet, the tool has failed regardless of quality. ## Success looks like Spreadsheet retired within a month. Invoicing prepared in a morning. Zero unbilled work discovered after the fact in the first year. ## Budget and timeline €45,000–70,000 over three months, with the invoicing view first because that is where the money is leaking.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧94/100
Client onboarding without ten emails
Every new client starts with the same document chase.
Przeczytaj brief
# Guided client onboarding for a tax practice ## The problem Onboarding a new client takes three to four weeks, and almost none of that is work — it is waiting. We send a template email with a PDF form, the client fills in half of it, we ask for the missing documents, they send a photo of the wrong page, we ask again. Four account managers each keep their own mental list of who owes what. When a client asks "what do you still need from me?", nobody can answer without opening a mailbox. ## Who it's for - New clients, about 200 a year: mostly owner-managed businesses and freelancers, not finance professionals, filling this in on a phone in the evening. - Four account managers who need to see, at a glance, which of their thirty in-flight onboardings is stuck and on whom. ## What exists today An email template, a fillable PDF, a shared drive folder per client created by hand, and a lot of chasing. Identity documents arrive as email attachments, which we are not comfortable with. ## Scope - A structured questionnaire with conditional branches, so a sole trader is not asked about shareholders. - A document checklist that is generated from the answers, with upload from a phone camera. - Identity document capture handled to a standard we can defend to our regulator. - E-signature on the engagement letter. - An internal dashboard: every onboarding, its stage, what it is waiting on, how long it has been there. - Automated reminders on a schedule we control. ## Out of scope Integration with our accounting software, billing and invoicing, and an ongoing client portal for work after onboarding. Those are a second project; this one ends when the engagement letter is signed. ## What "done" means 1. A client who starts on a phone can finish in one sitting or resume later from a link, without an account and without losing answers. 2. The dashboard shows, for any client, the single next thing blocking them — verifiable by picking any in-flight case at random. 3. No account manager writes a chasing email by hand; reminders go out on their own and are logged. 4. An uploaded identity document is never delivered by email, and access to it is logged. ## Personal data This handles identity documents, tax identifiers and financial data. GDPR compliance is not optional: we need a documented lawful basis, data minimisation (we should not keep an ID scan longer than the verification needs), encryption at rest and in transit, EU-only hosting, access logging, and a defined retention and deletion schedule. Privacy by design should be visible in the architecture, not bolted on at the end. ## Risks and assumptions We assume clients will complete a structured questionnaire more readily than a PDF. That is our core bet and it may be wrong for our older clients — we would want a paper fallback path that reception can key in. The regulatory requirements around identity verification may also tighten during the build. ## Accessibility WCAG 2.2 AA on the client-facing questionnaire. It is the first thing a new client sees of us. ## Success looks like Median onboarding time under 10 days, from 24 today. Zero identity documents arriving by email six months after launch. ## Budget and timeline €40,000–65,000 over three months.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧84/100
Make our reports something clients can click
We deliver 60-page PDFs that get skimmed once.
Przeczytaj brief
# Interactive client reporting ## What we want Turn our recurring analysis reports into an interactive web deliverable clients can filter, share and export. ## Who it's for Around 80 client-side readers, plus five analysts who produce the reports monthly. ## What exists today Analysts build charts in Excel and paste them into InDesign. Producing one report takes four days. ## Scope Data model and upload pipeline, chart components, report builder for analysts, client access with permissions, PDF export for archiving, branded templates. ## Out of scope Data collection, predictive modelling, white-labelling for resellers. ## Success looks like Production time per report under a day; measurable client usage after delivery. ## Budget & timeline €60–90k, 4 months.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧94/100
A booking page that respects our real availability
Double bookings, every week.
Przeczytaj brief
# Appointment booking for a multi-practitioner clinic ## The problem Availability lives in three places that disagree: a paper diary at reception, six personal calendars, and the room plan on the wall. Reception cannot see all three at once, so we double-book a treatment room roughly once a week and one of the two parties gets phoned and moved. Patients cannot book outside opening hours at all, and 15% of them simply do not turn up because nothing reminds them. ## Who it's for - Patients booking for themselves, mostly on a phone, mostly in the evening. A meaningful share are over 70 or have limited mobility. - Six practitioners, who each want to control their own hours without asking reception. - Two people on reception, who need one screen showing today. ## What exists today Bookings are taken by phone and written into a paper diary, then copied by hand into each practitioner's calendar. Rooms are allocated in the morning. Nobody can answer "is next Tuesday at 16:00 free" without three lookups. ## Scope - A treatment catalogue where each treatment carries a real duration, a room type and the practitioner skills it needs. - Availability as a rule set: practitioner working hours, room capacity, buffer/cleaning time between treatments. - Patient self-booking, reschedule and cancel, without an account (a booking reference and a date of birth is enough). - Automated reminders 48 and 3 hours ahead. - A reception day view with drag-to-move. - Two-way sync with the practitioners' existing calendars over CalDAV. ## Out of scope Medical records of any kind, insurance billing, taking payment online, and a native mobile app. We will keep using our practice management software for clinical notes; this tool must never store them. ## What "done" means A third party should be able to verify each of these: 1. Booking a treatment that needs a room makes that room unavailable to every other practitioner for the treatment duration plus buffer — attempting an overlapping booking is refused with a reason. 2. A practitioner blocking two hours in their own calendar removes those slots from the public page within five minutes. 3. Cancelling from the reminder link frees the slot immediately and it becomes bookable again. 4. Reception can move a booking to another practitioner and room without retyping the patient's details. ## Constraints Availability must sync with the calendars the practitioners already use (CalDAV); a bespoke calendar they have to check separately will not be adopted. Reminders go by SMS as well as email — a third of our patients do not read email. The reception machines are old and run a browser only, so nothing gets installed locally. ## Accessibility The public booking page must meet WCAG 2.2 AA: usable with a keyboard alone, readable at 200% zoom, and screen-reader friendly on the date picker in particular. Given who our patients are, this is a requirement and not a nice-to-have. ## Personal data Names, contact details, date of birth and the treatment booked are personal data, and treatment type is close enough to health data that we want to treat it as such. We need GDPR-compliant handling documented: lawful basis, a retention period after which bookings are deleted, encryption at rest, and a data processing agreement with whoever hosts it. EU hosting only. ## Risks and assumptions - We assume our practitioners will actually keep their own calendars up to date. If they do not, the tool is worse than the diary. Mitigation: the day view shows who has not touched their calendar this week. - The biggest risk is the availability rule engine: treatment durations and buffers vary more in practice than our price list suggests, and we may not know all the exceptions until we start. - We assume no-shows fall when reminders arrive. If they do not, the money is still worth it for the double bookings alone. ## Success looks like - Half of all bookings self-served within four months of launch, measured as bookings created without reception touching them. - Double bookings down to zero — the system should make them impossible, not rare. - No-show rate below 8%, from 15% today. ## Budget and timeline €30,000–50,000. Ten weeks to launch, with the reception day view usable internally from week six so we can shadow-run it against the paper diary.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧79/100
Turn our method into a product people log into
We sell workshops. We want a tool that sells itself.
Przeczytaj brief
# Productise our assessment method ## What we want A subscription web app that delivers the assessment method we currently run as a workshop: questionnaire, scoring, benchmark, action plan. ## Who it's for HR leads at mid-size companies; internally, two consultants who maintain the content. ## What exists today A facilitated workshop, a scoring spreadsheet and a slide deck per client. We can serve four clients a month at most. ## Scope Multi-tenant accounts, questionnaire engine, scoring and benchmark against anonymised aggregate data, action-plan output, admin for editing content, Stripe subscription billing. ## Out of scope Mobile app, integrations with HR systems, multi-language (phase two). ## Success looks like 25 paying accounts within six months of launch; content editable without a developer. ## Budget & timeline €80–120k, MVP in 4 months.
Otwórz w edytorze →
- Usługi profesjonalne🇬🇧93/100
A quoting tool that stops us underpricing
Half our quotes are guesses, and we only find out on the invoice.
Przeczytaj brief
# Quoting and scoping tool for a technical consultancy ## The problem Every quote we send is assembled from scratch in a document, with hours estimated from memory by whoever is free. We win work at prices that turn out to be below cost, and we only discover it at the end when the actual hours land. Three projects in the last financial year lost money, and none of them were flagged as risky at quote time. We also cannot answer basic questions — what our average margin is by work type, or whether our estimates are systematically low for a particular kind of job. ## Who it's for Six senior consultants who write quotes between other work, none of whom will use anything that takes longer than the document they use today. Two approvers who sign off anything above a value threshold. One administrator who turns an accepted quote into a project. ## What exists today A document template, a rate card in a spreadsheet that is out of date, and estimates typed in freehand. Actual hours are recorded in our time-tracking tool but never compared to what was quoted. ## Scope - A quote builder from reusable work packages, each with a default effort range and the roles it needs. - A rate card with role rates and a cost basis, so gross margin is calculated as the quote is built, not after. - Estimate ranges rather than single numbers, with the quote showing the risk-adjusted figure. - An approval step above a configurable value or below a configurable margin. - Comparison of quoted versus actual hours per work package, fed from the time-tracking tool, so the default ranges improve over time. - Generation of the client-facing quote document. ## Out of scope Invoicing, contract management and e-signature, CRM and pipeline tracking, and resource scheduling. The time-tracking tool stays where it is and is read-only here. ## What "done" means 1. A senior consultant can build and send a typical quote in under 30 minutes, from a standing start, without a template document. 2. Every quote shows a gross margin figure before it is sent, and one below the threshold cannot be sent without a director's approval — verified by trying. 3. Quoted versus actual is reported per work package with at least six months of history, and the default ranges can be updated from it. 4. The rate card has a single owner and a version history; nobody quotes off an old one. ## Constraints It has to read actual hours from our existing time-tracking tool's API. The client-facing document must remain something the team can restyle without a developer, since its layout is part of how work is presented. Everything is EU-hosted and access is per-user, since the cost basis and margins are commercially sensitive. ## Risks and assumptions We assume our work decomposes into reusable packages. For roughly two thirds of what we do that is clearly true; for bespoke advisory work it may not be, and the tool should allow a free-form package rather than force a fiction. The main behavioural risk is that people keep quoting in documents because it is familiar — which is why the 30-minute target above is an acceptance condition rather than an aspiration. ## Success looks like Zero projects sold below cost in the first year. Average gross margin visible per work type, monthly. Estimate accuracy improving measurably as the quoted-versus-actual history builds. ## Budget and timeline €40,000–65,000 over three months.
Otwórz w edytorze →
- Usługi profesjonalne🇩🇪100/100
Beratungsprotokolle, die sich fast von selbst schreiben
Nach jedem Termin eine Stunde Nacharbeit — und trotzdem fehlt am Ende die Hälfte.
Przeczytaj brief
# Dokumentation und Nachbereitung für eine Energieberatung ## Das Problem Nach jedem Vor-Ort-Termin sitzen unsere Beraterinnen und Berater etwa eine Stunde am Schreibtisch und tippen ein Protokoll aus handschriftlichen Notizen und Handyfotos ab. Bei acht Terminen pro Woche und Person sind das rund zwanzig Prozent der bezahlbaren Arbeitszeit, die keine Beratung ist. Weil die Nacharbeit oft erst Tage später passiert, fehlen Details, und die Fotos lassen sich im Nachhinein nicht mehr eindeutig einem Bauteil zuordnen. Kundinnen und Kunden warten im Schnitt neun Tage auf ihren Bericht, obwohl sie ihn für die Förderanträge brauchen. ## Für wen es ist - Elf Beraterinnen und Berater, die im Keller, auf dem Dachboden und im Heizungsraum arbeiten — mit einer Hand am Gerät, oft ohne Mobilfunkempfang. - Zwei Personen im Innendienst, die Berichte formal prüfen und versenden. - Die Kundinnen und Kunden selbst, meist Eigentümerinnen und Eigentümer von Ein- und Zweifamilienhäusern, häufig über 60, die den Bericht als Grundlage für Förderanträge verwenden. ## Was es heute gibt Handschriftliche Notizen auf einem Klemmbrett, Fotos auf dem privaten Diensthandy, ein Textverarbeitungsdokument als Vorlage und ein Ordner pro Kunde auf einem Netzlaufwerk. Die Berechnung der Kennzahlen passiert in einer Tabellenkalkulation, die eine Kollegin vor Jahren gebaut hat. ## Umfang - Eine Erfassungsmaske für den Termin, strukturiert nach Gebäudeteilen, offline nutzbar auf dem Handy oder Tablet. - Fotos, die direkt beim Aufnehmen dem jeweiligen Bauteil und Raum zugeordnet werden. - Übernahme der Stammdaten aus unserem bestehenden Auftragssystem, damit vor Ort nichts abgetippt wird. - Automatische Erzeugung des Berichtsentwurfs aus den erfassten Daten, inklusive der Kennzahlen. - Freigabeschritt im Innendienst mit Kommentaren, danach Versand als PDF. - Kundenzugang zum eigenen Bericht über einen Link, ohne Registrierung. ## Nicht im Umfang Die eigentliche Förderantragstellung, die Buchhaltung und Rechnungsstellung, die Terminplanung sowie jede Form von Fernauslesung an Heizungsanlagen. Das bestehende Auftragssystem wird nicht ersetzt, sondern angebunden. ## Wann es fertig ist 1. Ein vollständiger Termin ist vor Ort erfasst; die Nacharbeit am Schreibtisch dauert höchstens fünfzehn Minuten statt einer Stunde — nachgemessen an zwanzig echten Terminen. 2. Die Erfassung funktioniert vollständig ohne Netz und synchronisiert später, ohne dass ein einziger Datensatz verloren geht. 3. Jedes Foto ist eindeutig einem Bauteil zugeordnet und im Bericht an der richtigen Stelle eingebunden. 4. Der Berichtsentwurf entsteht ohne manuelles Kopieren; der Innendienst prüft nur noch. ## Technische Rahmenbedingungen Kein Mobilfunkempfang in Kellern und Heizungsräumen — die Anwendung muss offlinefähig sein und Konflikte beim Synchronisieren sauber auflösen. Die Stammdaten liegen im bestehenden Auftragssystem, das eine dokumentierte Schnittstelle hat. Die Endgeräte sind vorhandene Android-Tablets, teilweise mehrere Jahre alt. Hosting ausschließlich in der EU. ## Personenbezogene Daten Erfasst werden Adressen, Gebäudedaten und Fotos aus privaten Wohnräumen — das sind personenbezogene Daten nach DSGVO. Wir brauchen eine dokumentierte Rechtsgrundlage, Verschlüsselung der Fotos, ein Löschkonzept mit klarer Aufbewahrungsfrist nach Abschluss der Beratung sowie einen Auftragsverarbeitungsvertrag mit dem Hoster. ## Barrierefreiheit Der Kundenzugang zum Bericht muss WCAG 2.2 AA erfüllen. Ein großer Teil unserer Kundschaft ist über 60; Kontrast, Schriftgröße und ein Dokument, das sich auch mit Tastatur und Vorlesefunktion erschließt, sind hier praktische Anforderungen. ## Annahmen und Risiken Wir nehmen an, dass sich unsere Beratungsleistung so weit strukturieren lässt, dass ein Bericht überwiegend generiert werden kann. Für die Standardfälle stimmt das sicher; bei denkmalgeschützten Gebäuden vermutlich nicht, und dort muss weiterhin frei geschrieben werden können. Das größte Risiko ist die Akzeptanz im Team: Wenn die Erfassung vor Ort auch nur zwei Minuten länger dauert als das Klemmbrett, wird sie nicht genutzt. ## Woran wir Erfolg messen Nacharbeit pro Termin von einer Stunde auf unter fünfzehn Minuten. Zeit bis zum versendeten Bericht von neun Tagen auf zwei. Zwei zusätzliche Beratungstermine pro Person und Woche bei gleichem Personalbestand. ## Budget und Zeitrahmen 45.000–70.000 €, vier Monate, mit einer nutzbaren Erfassung für zwei Beraterinnen nach acht Wochen als Pilot.
Otwórz w edytorze →
- Usługi profesjonalne🇳🇱97/100
Roosterplanning en routes voor de wijkverpleging
Een planner maakt het rooster in een spreadsheet; de reistijd tussen twee cliënten staat er niet in.
Przeczytaj brief
# Roosterplanning en routeplanning voor een thuiszorgorganisatie ## Het probleem Wij leveren wijkverpleging in vier gemeenten met ongeveer 140 verzorgenden en 1.100 cliënten. Het weekrooster wordt door twee planners in een spreadsheet gemaakt en op donderdag per e-mail verstuurd. In dat rooster staat wel wie waar komt, maar niet hoe lang je erover doet om er te komen: de reistijd is een aanname. Het gevolg is dat een verzorgende die om 09.00 uur bij de ene cliënt weggaat structureel te laat bij de volgende aankomt, en dat de zorgtijd wordt ingekort om het schema te halen. Vorig jaar is 9 procent van de geplande bezoeken alsnog verzet of afgezegd, meestal op de dag zelf en telefonisch. Het ziekteverzuim onder verzorgenden is 8,4 procent en in de exitgesprekken wordt de planning consequent als eerste reden genoemd. Daarnaast lopen wij declaratieverschillen op, omdat de daadwerkelijk geleverde tijd pas achteraf uit losse briefjes wordt gereconstrueerd. ## Voor wie is het - Ongeveer 140 verzorgenden en wijkverpleegkundigen, die op de fiets of in de auto werken, met één hand een telefoon bedienen en soms in een portiek zonder bereik staan. - Twee planners, die per week ongeveer 3.500 bezoeken moeten beleggen binnen contractuele arbeidstijden en cao-rusttijden. - De teamleiders van de vier wijkteams, die vervanging regelen bij ziekmeldingen voor 07.00 uur. - De administratie, die de geleverde uren maandelijks bij de zorgverzekeraar en de gemeente declareert. ## Wat er nu is Een spreadsheet per wijkteam, een gedeeld postvak voor ziekmeldingen, papieren zorgleefplannen bij de cliënt thuis, en een elektronisch cliëntdossier dat wij houden en dat leidend blijft voor de zorginhoud. De koppeling tussen dat dossier en het rooster bestaat niet: cliëntgegevens worden met de hand overgetypt. ## Scope - Eén planning voor alle vier de teams, met beschikbaarheid, bevoegdheden en contracturen per medewerker als harde randvoorwaarde. - Reistijd tussen twee bezoeken als expliciete post in het rooster, berekend op afstand en vervoermiddel. - Een app voor de verzorgende: dagoverzicht, aankomst en vertrek registreren, korte rapportage per bezoek. - Ziekmelding voor 07.00 uur die de betrokken bezoeken direct als open zet, met een voorstel voor vervanging binnen het team. - Overname van cliëntadressen, indicaties en zorgmomenten uit het cliëntdossier, eenrichtingsverkeer. - Maandelijkse export van geleverde tijd per cliënt, geschikt voor de declaratie. ## Nadrukkelijk buiten scope De zorginhoud zelf: rapportage in het zorgleefplan, medicatie en het cliëntdossier blijven waar ze zijn. Ook salarisverwerking, verlofaanvragen, werving en de facturatie aan verzekeraars vallen erbuiten. Wij bouwen geen eigen routenavigatie, maar geven het adres door aan de kaartapplicatie op de telefoon. ## Wanneer is het klaar 1. Een planner maakt het weekrooster voor één wijkteam in minder dan vier uur, tegen twee dagen nu. 2. Elk gepland bezoek heeft een berekende reistijd; er staat geen enkel bezoek meer in het rooster dat volgens die berekening niet haalbaar is. 3. Een verzorgende registreert aankomst, vertrek en een korte rapportage in minder dan dertig seconden, staand, op één telefoon. 4. Een ziekmelding om 06.45 uur leidt vóór 07.30 uur tot een ingevuld of expliciet als open gemarkeerd rooster, zonder dat een teamleider handmatig lijsten vergelijkt. 5. De maandelijkse declaratie wordt uit één export samengesteld, zonder dat iemand losse briefjes natelt. ## Technische randvoorwaarden De app moet offline werken: in portieken, liften en kelderboxen is er geen bereik, en registraties mogen niet verloren gaan. De telefoons zijn de bestaande toestellen van de organisatie, deels vier jaar oud. Het cliëntdossier ontsluit gegevens via een API van de leverancier; het schrijven daarnaartoe doen wij niet. Hosting en verwerking uitsluitend binnen de EU, met een verwerkersovereenkomst per partij. ## Aannames en risico's De kwetsbaarste aanname is dat de zorgmomenten in het cliëntdossier actueel zijn. Wij vermoeden dat een aanzienlijk deel van de indicaties in de praktijk stilzwijgend is aangepast en alleen in de hoofden van de vaste verzorgenden bestaat. Een steekproef op honderd cliënten in de eerste maand moet dat uitwijzen, want een planning op verkeerde zorgmomenten is erger dan geen planning. Het organisatorische risico is dat registratie van aankomst en vertrek als controle wordt ervaren. Dat moet met de ondernemingsraad en de teams besproken zijn voordat er één regel code wordt geschreven, anders wordt er structureel achteraf en onjuist geregistreerd. ## Privacy en toegankelijkheid Het systeem verwerkt gezondheidsgegevens van cliënten en locatiegegevens van medewerkers: AVG, dataminimalisatie, rolgebaseerde toegang, logging van inzage en een vooraf vastgelegde bewaartermijn. De app en de planschermen voldoen aan WCAG 2.2 niveau AA, met voldoende contrast bij buitenlicht en bedienbaarheid met één hand. ## Budget en planning € 70.000 – € 110.000, zes maanden, met één wijkteam van 30 verzorgenden volledig live binnen twaalf weken.
Otwórz w edytorze →
- Usługi profesjonalne🇩🇰94/100
Beboerhenvendelser uden en fælles indbakke
Fire hundrede henvendelser om måneden lander i én postkasse, og ingen ved hvem der svarer.
Przeczytaj brief
# Sagsstyring af beboerhenvendelser i en ejendomsadministration ## Problemet Vi administrerer omkring 3.200 lejemål for andelsboligforeninger og private udlejere. Alle beboerhenvendelser — vandskader, varme der ikke virker, varmeregnskab, fraflytning — lander i én fælles postkasse med cirka 400 mails om måneden plus telefon. Ingen sag har en ejer, før nogen tilfældigt tager den, og vi kan ikke se, hvor længe en beboer har ventet. Vores egen stikprøve viste, at 18 % fik første svar efter mere end fem hverdage, og at 9 % aldrig fik svar. To gange sidste år blev en vandskade først opdaget ved tredje rykker, og forsikringssagen blev tilsvarende dyrere. Bestyrelsernes ønske om en sagsoversigt for deres egen ejendom kan vi kun opfylde i hånden. ## Hvem det er til for - Fem ejendomsadministratorer med 400-900 lejemål hver, som sidder med telefonen i den ene hånd. - To viceværter, der er ude hele dagen og kun har en telefon, ofte i kælderrum uden dækning. - Bestyrelsesmedlemmerne, som er frivillige, arbejder om aftenen og ikke skal oplæres i et fagsystem. - Beboerne selv, i alle aldre, som skal kunne melde en fejl uden at oprette en bruger. - Bogholderiet, som skal se, hvilke sager der udløser en udgift for foreningen. ## Hvad der findes i dag En fælles postkasse med mapper efter ejendom, et regneark over igangværende skadesager og viceværternes egne sedler i bilen. Administrationssystemet indeholder lejemål, beboerstamdata og økonomi, men ingen sagsstyring. Håndværkere bestilles telefonisk, og fakturaen er ofte det første skriftlige spor af, at et arbejde er udført. ## Omfattning - Beboeren melder en fejl fra mobilen via et link eller en QR-kode i opgangen, uden login, med foto. - Hver henvendelse bliver en sag med én navngiven ejer, en frist og en synlig status. - Sagen hænger sammen med lejemålet, hentet fra administrationssystemet, så adressen ikke skal skrives ind. - Viceværten får sine opgaver på telefonen og kvitterer med foto, også uden dækning. - Bestilling af håndværker fra sagen, med skriftligt spor og forventet beløb. - Bestyrelsesoversigt pr. ejendom: åbne sager, gennemsnitlig svartid og årets udgifter. - Automatisk kvittering til beboeren med sagsnummer og forventet svartid. ## Udtrykkeligt uden for opgaven Vi skifter ikke administrationssystem, og hverken huslejeopkrævning, varmeregnskab eller bogføring flytter. Vi bygger ingen beboer-app, der skal installeres, og ingen chat. Fraflytningssyn og istandsættelsesopgørelser holdes udenfor i denne etape. Vi integrerer ikke mod håndværkernes egne systemer; en bestilling er en mail med et sagsnummer. ## Hvornår er det færdigt 1. En beboer melder en fejl med foto på under to minutter fra en telefon, uden at oprette en konto, og får et sagsnummer med det samme. 2. Hver sag har en navngiven ejer inden for fire arbejdstimer, og ingen sag står uden ejer natten over. 3. En administrator kan på under et minut svare på, hvor mange åbne sager over 10 dage der er i en given ejendom. 4. En vicevært kvitterer med foto i en kælder uden dækning, og kvitteringen ligger i sagen, når telefonen igen har net. 5. Et bestyrelsesmedlem henter selv ejendommens sagsoversigt uden at kontakte os. 6. Den fælles postkasse er tom ved arbejdsdagens slutning, fordi hver mail er blevet en sag. ## Tekniske forudsætninger Administrationssystemet stiller lejemål og beboerstamdata til rådighed via et API, som vi kun må læse fra. Viceværternes app skal fungere offline og synkronisere bagefter, da kældre og teknikrum er uden dækning. Bestyrelsesadgang sker med et nationalt digitalt erhvervs-ID, ikke med et delt kodeord. Drift i EU, og persondata må ikke forlade EU. Henvendelser indeholder personoplysninger og undertiden helbredsoplysninger, når en beboer forklarer, hvorfor varmen er kritisk; behandlingen følger GDPR med databehandleraftale pr. forening, sletning efter fem år og adgangsstyring, så en administrator kun ser sine egne ejendomme. Fejlmeldingssiden og bestyrelsesoversigten skal opfylde WCAG 2.1 AA, da mange beboere er over 70 år. ## Antagelser og risici Den skrøbeligste antagelse er, at lejemålsdata er korrekte nok til automatisk at koble en henvendelse til det rigtige lejemål. Flere ejendomme har lejlighedsnumre, der ikke matcher opgangens skiltning; det bør efterprøves på tre ejendomme i de første to uger. Den organisatoriske risiko er, at synlige frister opleves som kontrol af administratorer, der i forvejen er pressede. Bruges tallene til at hænge folk ud i stedet for at fordele arbejdet, bliver sager lukket for tidligt, og statistikken bliver pænere end virkeligheden. ## Sådan måler vi resultatet Andel uden første svar inden for to hverdage fra 18 % til under 5 % på seks måneder. Henvendelser helt uden svar fra 9 % til nul. Sagsbehandlingstid på skadesager fra 21 til under 12 dage. Tid brugt på enkeltsager til bestyrelsesmøder halveret. ## Budget og tidsplan 40.000–60.000 €, fire måneder, med fejlmelding og sagsstyring i drift på 300 lejemål som pilot efter otte uger.
Otwórz w edytorze →
- Usługi profesjonalne🇪🇸94/100
Agenda e historia clínica compartidas entre seis clínicas de fisioterapia
Un paciente que cambia de centro llega sin historia, y el fisioterapeuta empieza la valoración desde cero.
Przeczytaj brief
# Agenda única e historia clínica compartida para un grupo de clínicas de fisioterapia ## El problema Somos un grupo familiar de seis clínicas de fisioterapia y rehabilitación en una misma provincia, con 28 fisioterapeutas y unas 1.100 sesiones a la semana. Cada centro lleva su propia agenda: cuatro en un programa instalado en el ordenador de recepción, dos en cuadernos y una hoja de cálculo. La historia clínica es papel en cinco de los seis centros. Cuando un paciente pide cita en otro centro porque le viene mejor de horario — pasa unas 60 veces al mes — su historia no viaja y el fisioterapeuta repite la valoración inicial: veinte minutos de sesión que el paciente ya pagó una vez. Las ausencias sin avisar fueron el 11,4% de las citas el año pasado, unas 125 sesiones semanales perdidas, porque el recordatorio se hace por teléfono cuando a la recepcionista le da tiempo. Y no sabemos cuántos pacientes abandonan el tratamiento antes de terminarlo: nadie puede contarlo sin abrir carpetas una a una. ## Para quién es - Los 28 fisioterapeutas, que escriben la evolución entre paciente y paciente, de pie, con cinco minutos entre sesiones y las manos recién lavadas. - Las siete recepcionistas, que atienden el mostrador y el teléfono a la vez y hoy no pueden ver los huecos de otro centro. - La responsable clínica, que revisa altas y derivaciones y necesita saber qué tratamientos se están alargando. - La gerencia, que decide horarios y contrataciones y hoy no tiene ni un dato fiable de ocupación por centro. - El paciente, que quiere pedir o cambiar su cita sin llamar en horario de trabajo. ## Qué existe hoy Cuatro instalaciones independientes de un programa de agenda antiguo, sin conexión entre sí y sin copia de seguridad automática en dos de los centros. Dos agendas en papel. Una hoja de cálculo con los pacientes de mutuas. Historias clínicas en carpetas físicas por centro, con consentimientos firmados en papel. Un programa de facturación en la oficina central al que se envían los partes cada semana en un correo. ## Alcance - Agenda única con los seis centros, sala y profesional, visible desde cualquier mostrador. - Ficha de paciente compartida entre centros, con valoración inicial, objetivos y evolución por sesión. - Registro de evolución en menos de un minuto, con plantillas por tipo de tratamiento. - Recordatorio automático de cita por mensaje al móvil con confirmación o cancelación en un toque. - Reserva y cambio de cita por el propio paciente desde el móvil, dentro de los huecos que cada centro habilite. - Consentimiento informado y consentimiento de tratamiento de datos firmados digitalmente y guardados con la historia. - Bonos de sesiones y su consumo, con volcado semanal al programa de facturación. - Cuadro de ocupación por centro, profesional y franja horaria. ## Fuera de alcance No sustituimos el programa de facturación ni entramos en la emisión de facturas ni en la adaptación a Verifactu, que corresponde a nuestra asesoría y al proveedor actual. No conectamos con las plataformas de las mutuas: seguimos enviando los partes como hasta ahora. No incluimos telerrehabilitación, vídeos de ejercicios ni aplicación nativa. No digitalizamos el archivo en papel anterior a la puesta en marcha, salvo la valoración vigente de los pacientes en tratamiento activo. ## Cuándo está terminado 1. Un fisioterapeuta registra la evolución de una sesión en menos de sesenta segundos desde una tableta, de pie, sin teclado físico. 2. Un paciente atendido en un centro distinto del habitual aparece con su historia completa en la pantalla del fisioterapeuta antes de que empiece la sesión, sin llamadas entre centros. 3. Cualquier recepcionista ve y ocupa huecos de los seis centros desde su mostrador. 4. El recordatorio sale automáticamente 24 horas antes de cada cita y la respuesta del paciente actualiza la agenda sin intervención humana. 5. Un paciente pide, cambia o cancela una cita desde el móvil sin llamar, y el hueco liberado queda disponible al instante. 6. Los seis centros trabajan sin agenda en papel durante un mes completo. 7. Los consentimientos de los pacientes en tratamiento activo están firmados digitalmente y asociados a su ficha. ## Restricciones técnicas Alojamiento en la Unión Europea, con cifrado en reposo y en tránsito y copia de seguridad diaria verificada. La conexión en dos de los centros es una línea móvil que se cae varias veces al día, así que la aplicación del fisioterapeuta debe permitir registrar la evolución sin conexión y sincronizar después sin duplicar sesiones. Las tabletas son las que ya tenemos, de diez pulgadas. Salida semanal de bonos y sesiones al programa de facturación en el formato de fichero que ya acepta hoy. Control de acceso por perfil: un fisioterapeuta ve solo los pacientes de los centros donde trabaja, y todo acceso a una historia queda registrado. Accesibilidad WCAG 2.1 AA en la parte de pacientes, con especial atención a personas mayores: tamaño de texto, contraste y un recorrido de reserva de tres pasos como máximo. ## Supuestos y riesgos Damos por hecho que los datos de las cuatro agendas informatizadas se pueden exportar en un formato utilizable; el proveedor lleva años sin dar soporte y quizá solo tengamos acceso a la base de datos por debajo. Hay que comprobarlo la primera semana, antes de comprometer la fecha de migración. El segundo riesgo es de organización: cada centro ha construido su forma de citar y de nombrar los tratamientos, y una agenda única obliga a acordar un vocabulario común de tipos de sesión. Si esa decisión no la toma la responsable clínica antes de empezar, la tomará el software por defecto y cada centro seguirá apuntando a su manera. Tratamos datos de salud, que son categoría especial: necesitamos evaluación de impacto, contrato de encargo del tratamiento con el proveedor de alojamiento, registro de accesos, conservación acorde con la normativa de documentación clínica y un procedimiento para atender derechos de acceso y supresión. ## Cómo medimos el resultado Ausencias sin avisar del 11,4% al 6% en seis meses. Valoraciones iniciales repetidas por cambio de centro de unas 60 al mes a cero. Tiempo de recepción dedicado a recordar citas por teléfono de unas diez horas semanales por centro a menos de dos. Ocupación media de sala del 68% al 78% al reasignar huecos cancelados. Y, por primera vez, un dato medido de abandono de tratamiento, con el objetivo de bajarlo un 20% el año siguiente. ## Presupuesto y plazos 70.000–95.000 €, seis meses. Primer hito: agenda única y ficha de paciente funcionando en dos centros a las once semanas, con la agenda antigua mantenida en paralelo durante las dos primeras.
Otwórz w edytorze →
- Usługi profesjonalne🇪🇪91/100
Hooldustööde graafik ja tööleht objektil
Kohustuslikud hooldused elavad ühes tabelis ja iga neljas jääb tähtajast mööda.
Przeczytaj brief
# Ventilatsiooni- ja küttesüsteemide hoolduse töökorraldus ## Probleem Hooldame lepingu alusel ligikaudu 400 objekti ventilatsiooni- ja soojuspumbasüsteeme. Hooldusgraafik on ühes tabelis, mida haldab üks inimene, ja lepingujärgsetest hooldustest jääb tähtajast mööda umbes veerand — eelmisel aastal 96 hooldust. Kliendile selgub see tavaliselt siis, kui ta ise küsib. Tehnik täidab objektil paberil töölehe, kliendi esindaja allkirjastab selle, ja paber jõuab kontorisse keskmiselt üheksa päeva hiljem; kolmel korral aastas ei jõua üldse, mistõttu tööd jäävad arveldamata. Möödunud aastal jäi nii välja arveldamata umbes 14 000 eurot. Kui klient küsib, mida tema seadmega kolme aasta jooksul tehtud on, kulub vastuse kokkupanekuks pool päeva. ## Kellele - Kaksteist hooldustehnikut, kes töötavad katusel, katlaruumis või tehnokorrusel, sageli kinnastega ja halva mobiililevi tingimustes, ning kellel on ainult telefon. - Hooldusjuht, kes planeerib nädala töögraafiku ja jagab avariiväljakutsed jooksvalt. - Kliendihaldur, kes vastutab lepingute täitmise eest ja peab kliendile tõendama, et kohustuslik hooldus on tehtud. - Raamatupidaja, kes koostab kuu lõpus e-arved tehtud tööde põhjal. ## Mis on täna olemas Tabelarvutus hooldusgraafikuga, paberist töölehtede plokk igas autos, seadmete andmed osalt lepingudokumentides ja osalt tehnikute peas, ning majandustarkvara, kus arved koostatakse käsitsi ja saadetakse e-arvena. Objektide skeemid ja seadmete kasutusjuhendid on kontori võrgukettal kaustades. Avariiväljakutsed tulevad telefonile ja kirjutatakse märkmikku. ## Maht - Objektide ja seadmete register ühe tõeallikana: asukoht, seadme andmed, hoolduse sagedus, ligipääsu erisused. - Korduvate hooldusgraafikute automaatne genereerimine töökäskudeks kalendri alusel. - Nädalagraafiku vaade hooldusjuhile, kus töö liigub tehnikult tehnikule. - Mobiilne tööleht objektil: tehtud toimingud, kulunud aeg, vahetatud varuosad, fotod enne ja pärast, mõõtetulemused. - Kliendi esindaja allkiri ekraanil ja töölehe automaatne saatmine tema e-posti aadressile. - Rikketeade objektilt koos fotoga, mis tekitab eraldi töökäsu. - Kuu tehtud tööde koond majandustarkvarasse arveldamiseks. - Kliendi vaade, kuhu ta siseneb Smart-ID või Mobiil-ID-ga ja näeb oma objektide hoolduslugu. ## Väljaspool mahtu Me ei ehita seadmete kaugseiret ega andurite andmete kogumist automaatikakontrolleritest, samuti mitte ennustavat hooldust. Ladu ja varuosade ostuprotsess, palgaarvestus ja pakkumiste koostamine jäävad välja. Majandustarkvara ei asendata: arve koostatakse endiselt seal, siia jääb ainult tehtud tööde koond. ## Millal on valmis 1. Tehnik sulgeb töölehe objektil alla kolme minuti, kinnastega, ilma klaviatuurita. 2. Klient saab allkirjastatud töölehe e-postiga viie minuti jooksul pärast töö lõppu, ka siis, kui tehnik oli katlaruumis levita. 3. Paberist töölehti ei kasutata ühelgi objektil ühe kuu jooksul. 4. Iga seadme kolme aasta hooldusloo saab välja võtta alla ühe minuti ja PDF-ina kliendile saata. 5. Lepingujärgne hooldus, mille tähtaeg läheneb, on graafikus nähtav vähemalt kolm nädalat ette ja ükski ei aegu ilma hoiatuseta. 6. Kliendivaade vastab WCAG 2.1 AA tasemele ja töötab telefoni brauseris. ## Tehnilised piirangud Katlaruumides ja tehnokorrustel mobiililevi sageli puudub, seega peab rakendus töötama võrguühenduseta ja sünkroniseerima hiljem, kaotamata fotosid ega allkirju. Kasutatakse olemasolevaid Android-telefone, millest vanimad on viieaastased. Kliendi tuvastamine käib Smart-ID ja Mobiil-ID kaudu, mitte parooliga. Tehtud tööde koond liigub majandustarkvarasse selle olemasoleva liidese kaudu. Serverid Euroopa Liidus. Kasutajaliides eesti keeles, tehnikute hulgas on vene emakeelega töötajaid, seega on vaja ka venekeelset liidest. ## Eeldused ja riskid Kõige hapram eeldus on, et tabelis olevad hooldussagedused vastavad kehtivatele lepingutele — kahtlustame, et osa on aastate jooksul suuliselt muudetud. Kolmekümne suurima objekti lepingud tuleb esimese kuu jooksul üle kontrollida, enne kui graafik süsteemi laaditakse. Teine, organisatsiooniline risk: kogenumad tehnikud peavad paberit kiiremaks, ja kui töölehe täitmine võtab kauem kui paberil, täidetakse see õhtul mälu järgi või jäetakse tegemata, ning projekt kukub läbi ilma et keegi seda ütleks. Kolmas risk on seadmete andmete kvaliteet: register tuleb esimesel aastal objektikülastuste käigus täita, mitte eeldada, et see on juba olemas. ## Kuidas mõõdame Tähtajast möödunud lepingujärgsed hooldused 96-lt alla viie aastas. Arveldamata jäänud tööd 14 000 eurolt alla 1 000 euro aastas. Töölehe jõudmine kontorisse üheksalt päevalt alla ühe tunni. Kliendi päringule "mida te mu seadmega teinud olete" vastamine poolelt päevalt alla viie minuti. ## Isikuandmed Töötleme kliendi esindaja nime, allkirja ja e-posti aadressi ning tehniku asukohta tööajal. Vajame kirjalikku töötlemise alust ja säilitustähtaegu, tehniku asukoha nähtavust ainult töövahetuse ajal ning võimalust töölehtede andmed tähtaja möödudes kustutada. Vastutav töötleja oleme meie, arendaja on volitatud töötleja ja vajab lepingut. ## Eelarve ja ajakava 55 000–80 000 €, neli kuud, ning kolm tehnikut ja sada objekti päris töölehtedega pilootkasutuses üheksa nädalaga.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧77/100
Book classes from a phone, one live view for staff
Sign-up sheets by the door, and a WhatsApp group.
Przeczytaj brief
# Class booking for a sports club ## What we want Members book classes from their phone; staff see one live view of who is coming and what is full. ## Who it's for 900 members (wide age range, so it has to be simple) and six staff. ## What exists today Paper sign-up sheets and a WhatsApp group. Classes are overbooked or half empty; membership status is in a separate spreadsheet. ## Scope Member accounts, class schedule and booking, waiting list, cancellation window, staff live view and check-in, membership status import, no-show tracking. ## Out of scope Payments and direct debit, personal training plans, native app. ## Success looks like 70% of bookings made online within three months; empty seats per class down by half. ## Budget & timeline €30–50k, live before the new season (3 months).
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧93/100
Take table orders without a third-party commission
We pay 12% to someone else for our own regulars.
Przeczytaj brief
# Own-channel ordering for a four-site restaurant group ## The problem We pay a delivery platform 12% commission on orders from customers who already know us and would come anyway — regulars who found the platform easier than our phone line. That is our entire net margin on those orders. Inside the restaurants, orders go from table to kitchen on paper tickets, which get lost on busy Saturdays and cannot be read by the new chef. And our menus are updated by emailing a PDF to whoever maintains each channel, so a sold-out dish stays on sale for two days. ## Who it's for - Guests at four locations, ordering at the table from their own phone without installing anything, plus pickup customers ordering ahead. - Kitchen staff, who need a legible ticket and nothing else. - The operations manager, who maintains menus for four sites and currently does it four times. ## What exists today A delivery platform taking 12%. Paper tickets in-house. Menus maintained as a PDF that gets emailed around. A card terminal at the counter and an existing payment provider account. ## Scope - Menu management per location, with availability toggles and scheduled sections (lunch, evening). - QR ordering at the table: scan, order, pay, ticket to kitchen. - Pickup ordering from our own site with collection time slots and a capacity cap per slot. - Payment through our existing payment provider. - Kitchen ticket printing to the printers already installed. - A daily sales report per site and per channel. ## Out of scope Delivery logistics and drivers — we are not becoming a delivery company. Table reservations, loyalty, and stock or recipe costing. ## What "done" means 1. A guest can scan, order and pay in under three minutes on their own phone with no install and no account. 2. A paid order prints in the kitchen within ten seconds, and a printer failure raises a visible alert rather than losing the order. 3. Marking a dish sold out removes it from every channel for that location in under a minute. 4. The daily report reconciles to the payment provider's settlement without manual adjustment. ## Constraints Tickets must print to the thermal printers already in the kitchens. Payments go through our existing provider — we are not opening a new merchant account. In-restaurant wifi is guest-grade; the ordering flow runs over the guest's mobile data, so pages must be small and fast. Menus exist in German and English. ## Accessibility The guest ordering page must meet WCAG 2.2 AA. Guests use it in low light with one hand while others are talking; contrast, tap target size and a form that survives an interruption are practical requirements here. ## Risks and assumptions The core assumption is that guests will scan a QR code rather than wave at a server. Table ordering has failed in restaurants where the staff quietly discouraged it, so the rollout has to include the floor teams, not just the software. The other risk is menu maintenance: if it is not genuinely faster than the PDF, the operations manager will keep the PDF and we will have two sources of truth again. ## Success looks like 30% of order value moved to our own channel within six months, measured against platform commission paid. Menu changes live in under five minutes. Lost paper tickets at zero. ## Budget and timeline €45,000–70,000. One location live in eight weeks as a pilot, all four within four months.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧89/100
One calendar for rooms, cleaning and keys
Two booking sites, one cleaner, endless confusion.
Przeczytaj brief
# Operations calendar for a 14-apartment holiday letting ## The problem Our 14 apartments are listed on two large booking platforms, each with its own dashboard and its own calendar. Nobody sees all bookings in one place, so twice a year we double-book an apartment and have to move a guest at our own cost. Cleaning is coordinated entirely by phone: three cleaners call one of us each morning to ask what needs doing, and we call back to confirm it was done. Key handover instructions are sent manually to each guest, and when they are not, the guest calls at 22:00. ## Who it's for - The two owners, who run this alongside other work and need it to answer questions without them logging in. - Three cleaners, on their own phones, who do not want an app and are not all comfortable with software. - Guests, who need arrival instructions in the right language at the right time. ## What exists today Bookings arrive into two separate platform dashboards. A wall calendar is the closest thing to a single view, kept up to date about half the time. Cleaning coordination is phone calls. Arrival messages are copied and pasted. ## Scope - Channel import over iCal from both platforms, polled frequently, plus manual entry for direct bookings. - One unified calendar across all 14 apartments with conflict detection. - Automatic cleaning task generation on every checkout, assignable to a cleaner. - A mobile checklist for cleaners: mark done, photograph any damage, flag missing inventory. - Automated guest arrival message with door code and directions, sent on a schedule. - A monthly occupancy and cleaning-cost report. ## Out of scope Dynamic pricing, a direct booking engine with payments, smart-lock hardware, and guest reviews. We will keep taking direct bookings by email for now. ## What "done" means 1. A booking created on either platform appears in the unified calendar within 30 minutes, and an overlapping booking raises a visible conflict rather than being silently accepted. 2. Every checkout produces a cleaning task automatically; no task is created by a human. 3. A cleaner can complete a checklist with photos on their own phone, over mobile data, without installing anything. 4. Guest arrival messages go out on schedule with the correct per-apartment door code, verified across a full week without an owner touching anything. ## Constraints The two platforms only give us iCal feeds, not real-time webhooks, so there is an inherent sync delay we have to design around rather than pretend away. Cleaners are on their own devices, mixed Android and iOS, mostly older handsets — this has to be a web page, not an app store install. ## Risks and assumptions The known weakness is iCal polling: a booking made minutes before another on a different platform can still collide, so the tool must make conflicts loud and easy to resolve rather than promise they cannot happen. We also assume the cleaners will use the checklist; if they do not, we have replaced phone calls with nothing. ## Success looks like Zero double bookings in the first year. Cleaning status visible without a phone call, measured by the owners' call volume to cleaners dropping to near zero. Arrival questions from guests down by half. ## Budget and timeline €30,000–45,000, ten weeks, with channel import and the unified calendar in the first four so we stop double-booking before the season.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧93/100
Memberships and door access that agree with each other
People who cancelled six months ago still get in.
Przeczytaj brief
# Membership and access management for a co-working space ## The problem Who is a member and who can open the door are two different lists maintained by two different people, and they have drifted. People who cancelled six months ago still have working door codes. New members occasionally cannot get in on their first morning. Nobody can answer "who was in the building last Tuesday evening" without reading the controller's raw log, and nobody can answer "does this member's plan include weekend access" without opening a spreadsheet and interpreting it. ## Who it's for Around 600 members on five different plans, from full-time desks to a ten-days-a-month card. Two community managers who currently do the reconciliation by hand. Whoever prepares the books each month, who needs a clean billing basis. ## What exists today Memberships in a spreadsheet. Invoices in an off-the-shelf accounting tool. Door codes managed by hand in the access controller's own vendor software. Three sources, no sync. ## Scope - Member records and plan definitions, with join, upgrade, downgrade and cancel flows that carry a date. - Access rules derived from the plan: which doors, which time windows, how many days a month. - Integration with our existing door controller through its API so access follows membership automatically. - An entry audit log, queryable by member and by date. - A monthly billing basis export for the accountant. - Self-service for members: see your plan, your remaining days, and cancel. ## Out of scope Room and desk booking, community and messaging features, and payment collection — which stays with the existing bank mandate and accounting tool. We are not replacing the door hardware. ## What "done" means 1. Cancelling a membership with an end date revokes door access at 23:59 on that date, automatically, with no human step — verifiable by cancelling a test member and trying the door. 2. A community manager never edits a door code by hand again. 3. The monthly billing export reconciles to the member list without manual adjustment. 4. An entry log query for any member and any date range returns in seconds and can be exported. ## Constraints The door controller is existing hardware with a documented but limited HTTP API — it can be told about credentials and time profiles but has a cap on the number of profiles, which will shape the access-rule model. The building has a single controller; there is no cloud service in front of it, so whatever we build has to reach it on the local network. ## Personal data Entry logs are personal data and slightly sensitive: they show when an individual was in a building. GDPR handling needs a stated purpose (security and billing), a short retention period for raw entry events, restricted access, and a documented deletion routine. Members should be told this exists. ## Risks and assumptions The main assumption is that the controller's API is good enough to be driven programmatically at this scale — if its profile cap is lower than our plan matrix needs, the access model has to be simplified and that is a scoping conversation, not a bug. We also assume our five plans are actually five plans and not five plans plus twenty historical exceptions; the data migration will tell us. ## Success looks like Access revoked automatically on 100% of cancellations. Zero manual door-code edits after month one. Monthly billing basis produced in under an hour instead of a day. ## Budget and timeline €35,000–55,000, three months, with the access-sync piece first because it is where the risk and the pain both are.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧93/100
Take our shop online in a way we can maintain
We're good at the product, not at websites.
Przeczytaj brief
# Website and small shop for a farm producer ## The problem Our website was built in 2014 and nobody can edit it — the person who made it is long gone and the admin login no longer works. So our prices are wrong online, seasonal products are invisible, and every order comes by phone during working hours, which means we miss the ones that would have come at 21:00. Restaurants who buy from us wholesale have to ring for a price list. We are two people who make food; we are not going to learn a complicated system, and we have been burned once already by a site we could not maintain. ## Who it's for - Local customers ordering a weekly pickup box, mostly on a phone. - Restaurant buyers ordering wholesale quantities against agreed prices, on a laptop, during the day. - The two of us, with no technical background, needing to change a price or mark something sold out in under ten minutes. ## What exists today A 2014 site on an abandoned content management system that nobody can log into. A social media account we post to. Orders by phone, written on a pad. ## Scope - A brand refresh: cleaning up the logo, a colour palette and typography we can apply ourselves. - A site with our story, the farm, and product pages. - A shop with pickup slots and a small local delivery radius. - A wholesale price list behind a login, with buyer-specific pricing. - Content we can edit: prices, availability, a seasonal note on the front page. - A half-day training session and a one-page written guide for the two of us. ## Out of scope Subscription boxes, marketplace listings, integration with any accounting or farm-management software, and shipping outside our delivery radius. No app. ## What "done" means 1. Either of us can change a price and mark a product sold out, unaided, in under ten minutes — tested by watching us do it at the end of training, not by being told it is possible. 2. A customer can place and pay for a pickup order on a phone in under three minutes. 3. A wholesale buyer sees their own agreed prices and nobody else's. 4. The site scores well enough on core web vitals to load usably on a rural mobile connection. ## Constraints Our internet at the farm is slow, and so is our customers'. Whatever is built must be maintainable by non-technical owners without a support contract — that constraint outranks feature count. We would rather have a small site we control than a large one we do not. ## Accessibility WCAG 2.2 AA on the public site and shop. A good share of our local customers are elderly, so text size, contrast and a form that works without precise tapping are practical concerns rather than compliance box-ticking. ## Risks and assumptions We assume our phone customers will move online. They may not, and the honest measure of success is total orders, not online orders. The other risk is us: if the editing experience is even slightly intimidating, the site will rot again exactly as the last one did, so the training and the simplicity of the admin matter more than anything on the front end. ## Success looks like We publish a product change ourselves within ten minutes, every week, six months after launch. 40 online orders a week by month three. No phone call from a restaurant asking for a price list. ## Budget and timeline €20,000–35,000, eight weeks, live before the summer season.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇬🇧90/100
Rotas the team can swap themselves
The rota goes up Friday and is wrong by Sunday.
Przeczytaj brief
# Shift planning for a five-site hospitality group ## The problem A manager builds each site's rota in a spreadsheet, prints it and pins it up on Friday. By Sunday it is wrong: someone has swapped a shift by text message, someone else is ill, and the printed version no longer matches reality. Staff find out about changes by group chat or by turning up. We have been short-staffed on a Saturday evening because two people each believed the other was covering. Payroll is then reconstructed from the marked-up printout, which is how we end up paying for hours nobody can verify. ## Who it's for - Around 90 staff across five sites, many part-time, many students, all on their own phones, several working across more than one site. - Five site managers who build the rota and approve changes. - One person who runs payroll from whatever the rotas ended up being. ## What exists today A spreadsheet per site per week, printed and pinned up. Swaps by text message. Absence by phone call. Payroll built by hand from the annotated printouts. ## Scope - Rota building per site, with roles and minimum cover per hour, and templates for a typical week. - Publication to staff phones, with a notification when the rota changes. - Staff-initiated swaps: offer a shift, another qualified person claims it, a manager approves — the rota updates once, everywhere. - Absence reporting, and a visible list of open shifts needing cover. - Availability declared by staff in advance, respected by the builder. - An export of actual worked shifts as the payroll basis. ## Out of scope Payroll calculation and payment, recruitment and onboarding, till and sales integration, and forecasting demand to size the rota. Managers decide how many people they need; this tool helps them staff it. ## What "done" means 1. A published rota change reaches the affected staff member's phone within one minute. 2. A swap between two qualified staff completes without a manager writing anything, only approving — and the rota never shows two people believing they cover the same shift. 3. Minimum cover per role per hour is enforced at build time: a rota that leaves a gap cannot be published without an explicit override. 4. The payroll export reconciles to the published rota plus approved changes, with no manual reconstruction. ## Constraints Staff are on their own phones, mixed and often old devices, so this is a web app with no store install and it has to be usable on a small screen with one hand. Some staff work at more than one site, so the model is one person across sites, not one record per site. Working time rules — rest between shifts, hours for staff under 18 — are hard constraints the builder must enforce. ## Personal data Rotas, availability and absence are personal data about employees, and absence in particular is sensitive. We need a documented lawful basis, access limited to a person's own site managers, no health details recorded against an absence, a defined retention period, and a deletion routine when someone leaves. ## Risks and assumptions We assume staff will declare availability honestly and in advance; if they do not, the builder is no better than the manager's memory. Our second assumption is that staff-led swapping will not be abused — it needs manager approval precisely because we are not sure yet, and that approval step should be easy to relax later if it turns out to be unnecessary friction. ## Success looks like Zero uncovered shifts caused by a miscommunicated swap in the first six months. Rota-building time per site down from three hours a week to under one. Payroll prepared from an export rather than from paper. ## Budget and timeline €35,000–55,000, three months, one site as a pilot after six weeks.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇩🇪92/100
Tischreservierung, die mit dem Service mitdenkt
Das Reservierungsbuch weiß nichts davon, dass Tisch 12 noch zwanzig Minuten braucht.
Przeczytaj brief
# Reservierung und Tischdisposition in der Gastronomie ## Das Problem Reservierungen laufen bei uns über ein Papierbuch am Empfang und über eine Plattform, die uns pro Gast eine Gebühr berechnet. Beides weiß nichts vom tatsächlichen Zustand des Raums: Ob ein Tisch gerade abgeräumt wird, ob eine Vierergruppe seit zwei Stunden beim Dessert sitzt, ob draußen zehn Leute warten. Also überbuchen wir aus Vorsicht nicht — und lassen an einem vollen Samstag rechnerisch etwa fünfzehn Prozent unserer Plätze leer stehen, während wir gleichzeitig Gäste wegschicken. Bei Nichterscheinen ohne Absage, im Schnitt sieben Prozent der Reservierungen, verlieren wir den Tisch komplett. ## Für wen es ist - Gäste, die abends vom Handy aus reservieren, oft kurzfristig und häufig auf dem Weg. - Der Service im Restaurant, der das Werkzeug in Bewegung bedient, mit einer Hand, unter Zeitdruck. - Die Betriebsleitung, die wissen will, wie ausgelastet die Häuser wirklich sind. ## Was es heute gibt Ein Papierbuch am Empfang, eine kostenpflichtige Reservierungsplattform, ein Telefon und ein Tischplan, der als laminierte Zeichnung an der Wand hängt. Kassensystem und Reservierung haben nichts miteinander zu tun. ## Umfang - Reservierung über die eigene Website, ohne App und ohne Konto, mit Bestätigung per SMS und E-Mail. - Ein Tischplan pro Haus mit Zuständen: frei, reserviert, besetzt, wird abgeräumt. - Verweildauer-Schätzung je Tischgröße, aus tatsächlichen Daten gelernt statt fest eingestellt. - Wartelistenfunktion für Gäste ohne Reservierung, mit Benachrichtigung per SMS. - Erinnerung am Vortag mit einem Ein-Klick-Absagelink, um Nichterscheinen zu senken. - Auslastungsauswertung pro Haus, Wochentag und Uhrzeit. ## Nicht im Umfang Bestellung und Bezahlung am Tisch, Warenwirtschaft, Personaleinsatzplanung, Gutscheine und Veranstaltungsverwaltung. Das Kassensystem bleibt unverändert; eine Anbindung ist ausdrücklich erst ein späterer Schritt. ## Wann es fertig ist 1. Eine Reservierung vom Handy dauert unter einer Minute, ohne Konto und ohne App. 2. Der Service kann einen Tischzustand in höchstens zwei Antippern ändern, im Gehen, auf einem Tablet. 3. Die Warteliste benachrichtigt den nächsten Gast automatisch, sobald ein passender Tisch frei wird. 4. Die Nichterscheinen-Quote ist messbar, pro Haus und pro Zeitfenster, und lässt sich vor und nach Einführung der Erinnerung vergleichen. ## Technische Rahmenbedingungen Das WLAN in beiden Häusern ist Gastnetz-Qualität, die Anwendung muss also mit kurzen Aussetzern umgehen können, ohne den Tischplan zu verlieren. Bedient wird auf zwei vorhandenen Tablets. SMS-Versand über einen europäischen Anbieter. Betrieb ausschließlich in der EU. ## Personenbezogene Daten Wir speichern Namen, Telefonnummern und Besuchshistorie. Nach geltendem Datenschutzrecht brauchen wir dafür eine dokumentierte Rechtsgrundlage, eine Aufbewahrungsfrist, eine getrennte Einwilligung für alles, was nach Marketing aussieht, und einen funktionierenden Löschweg. Notizen des Service zu Gästen sind heikel und sollten technisch begrenzt sein. ## Annahmen und Risiken Wir nehmen an, dass genug Gäste direkt bei uns reservieren, wenn der eigene Weg spürbar einfacher ist als der über die Plattform. Sicher ist das nicht — die Plattform bringt auch neue Gäste, und wir wollen sie zunächst parallel weiterlaufen lassen statt sie sofort zu kündigen. Das zweite Risiko liegt beim Service: Ein Tischplan, der nicht sekundengenau gepflegt wird, ist schlechter als das Papierbuch, weil man ihm dann nicht mehr glaubt. ## Woran wir Erfolg messen Auslastung an Spitzenabenden um zehn Prozentpunkte höher. Nichterscheinen von sieben auf unter drei Prozent. Die Hälfte aller Reservierungen über den eigenen Kanal innerhalb von sechs Monaten, gemessen an den gesparten Plattformgebühren. ## Budget und Zeitrahmen 30.000–50.000 €, zehn Wochen, ein Haus als Pilot nach sechs Wochen.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇮🇹92/100
Prenotazioni di gruppo che non si incastrano da sole
Camere, ristorante e visite guidate: tre agende che non si parlano.
Przeczytaj brief
# Prenotazioni e attività per un agriturismo con dodici camere ## Il problema Vendiamo tre cose che dipendono l'una dall'altra — dodici camere, un ristorante da settanta coperti e le visite guidate in cantina — e le gestiamo su tre agende separate. Quando arriva un gruppo di venticinque persone, qualcuno deve tenere a mente che quel gruppo occupa otto camere, mezza sala il sabato sera e la visita delle 17. Regolarmente qualcosa salta: abbiamo accettato una cena per esterni che non stava in sala perché il gruppo non era segnato, e abbiamo venduto una visita guidata in un orario in cui l'unica persona che la conduce era altrove. Ogni preventivo di gruppo richiede almeno tre telefonate interne. ## Per chi è - Chi prenota per un gruppo: agenzie, aziende, famiglie allargate. Scrivono via e-mail e vogliono una risposta con un prezzo, non un modulo. - Le due persone alla reception, che gestiscono tutto e non hanno tempo per un sistema complicato. - Il personale di sala e la persona che conduce le visite, che devono sapere cosa succede domani senza chiedere. ## Cosa esiste oggi Un gestionale per le camere, collegato a due portali di prenotazione. Un quaderno per il ristorante. Un calendario condiviso per le visite. I preventivi di gruppo si scrivono a mano in un documento e si inviano via e-mail. ## Perimetro - Una vista unica del giorno e della settimana: camere, coperti in sala, visite guidate. - Prenotazione di gruppo come unico oggetto che occupa risorse diverse contemporaneamente, con verifica automatica dei conflitti. - Generazione del preventivo di gruppo dal listino, con opzioni e scadenza dell'opzione. - Disponibilità delle visite guidate legata a chi le conduce, non solo all'orario. - Conferma automatica agli ospiti e promemoria il giorno prima. - Vista di domani, stampabile e leggibile su telefono, per sala e cantina. ## Fuori perimetro Il canale di vendita online delle camere, che resta sui portali e sul gestionale esistente. La cassa del ristorante, il magazzino cantina, la fatturazione e le vendite di prodotti online. Non sostituiamo il gestionale camere: lo leggiamo. ## Quando è finito 1. Una richiesta di gruppo si trasforma in preventivo completo in meno di dieci minuti, senza telefonate interne. 2. Un conflitto tra gruppo, cena esterna e visita guidata viene segnalato al momento dell'inserimento, non scoperto il sabato. 3. La vista di domani è corretta e consultabile da telefono da sala e cantina, verificata per due settimane consecutive. 4. Ogni ospite riceve conferma e promemoria automatici, senza che nessuno li scriva. ## Vincoli tecnici Il gestionale camere resta la fonte per le camere e ha un'interfaccia documentata, quindi la disponibilità va letta da lì e non duplicata. La connessione in cantina è debole: la vista di domani deve funzionare anche offline. Interfaccia in italiano e inglese. ## Dati personali Trattiamo nomi, contatti, e per i gruppi anche liste di partecipanti. Servono base giuridica documentata, tempi di conservazione definiti, cancellazione effettiva su richiesta e conservazione dei dati in UE. Nessuna nota sugli ospiti oltre a quanto serve al servizio. ## Ipotesi e rischi Diamo per scontato che il gestionale camere esponga la disponibilità in tempo utile: se l'aggiornamento è lento, la vista unica mostrerà dati vecchi proprio nei momenti in cui serve di più, e va verificato subito. Il rischio maggiore però è organizzativo: se la reception continua a segnare il ristorante sul quaderno "perché è più veloce", torniamo al punto di partenza. ## Come misuriamo il risultato Zero sovrapposizioni tra gruppi, cene esterne e visite nella prima stagione. Tempo per un preventivo di gruppo da mezza giornata a dieci minuti. Almeno il 30% di richieste di gruppo in più gestite senza aggiungere personale. ## Budget e tempi 30.000–45.000 €, tre mesi, con la vista unica e il rilevamento dei conflitti pronti prima dell'apertura di stagione.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇫🇷94/100
Devis et planning des salles de séminaire
Une demande de séminaire met cinq jours à recevoir un devis, et deux commerciaux vendent parfois la même salle.
Przeczytaj brief
# Devis et planning des espaces séminaires pour trois hôtels-restaurants ## Le problème Nous exploitons trois hôtels-restaurants indépendants en région, 210 chambres, onze salles de réunion et deux salles de banquet, 95 salariés. L'activité séminaires représente 34 pour cent de notre chiffre d'affaires et c'est la seule que nous gérons encore entièrement par courriel. Une demande arrive dans une boîte partagée, un commercial reconstitue à la main la disponibilité des salles, des chambres et de la cuisine, puis rédige un devis dans un traitement de texte. Le délai moyen de réponse est de cinq jours ouvrés ; nos concurrents répondent en vingt-quatre heures et nous perdons environ 30 pour cent des demandes avant même d'avoir chiffré. Deux fois cette année, une même salle a été vendue à deux clients pour la même date, ce qui a coûté un déclassement et un geste commercial de 4 200 euros. Personne ne sait, un lundi matin, ce qui est réellement bloqué et ce qui est seulement en option. ## À qui cela s'adresse - Quatre commerciaux séminaires, souvent en déplacement chez le client, qui doivent chiffrer depuis un ordinateur portable ou un téléphone. - Les trois directeurs d'établissement, qui arbitrent entre une réservation groupe et le remplissage individuel des chambres. - Les chefs de cuisine, qui ont besoin des effectifs et des régimes alimentaires soixante-douze heures avant, et les réceptions, qui doivent savoir le matin même quelles salles sont occupées et dans quelle configuration. - Les assistantes de direction des entreprises clientes, qui organisent ces réunions en plus de leur travail et n'ouvriront pas de compte pour une simple demande. ## Ce qui existe aujourd'hui Un logiciel de gestion hôtelière par établissement, qui connaît les chambres mais ignore les salles. Un tableur mensuel par hôtel pour les salles, imprimé et affiché en réception. Une boîte de courriels partagée. Des modèles de devis en traitement de texte, avec des tarifs qui datent de deux saisons. Les options posées par téléphone ne sont notées nulle part. ## Périmètre - Un planning unique des onze salles et des deux espaces de banquet, sur les trois établissements, avec configurations et capacités. - La distinction explicite entre option datée et réservation ferme, avec expiration automatique des options. - Un devis structuré composé à partir d'un catalogue de prestations et de tarifs saisonniers : salle, restauration, pauses, chambres, matériel. - L'envoi du devis avec acceptation en ligne et signature électronique, sans création de compte. - Une fiche de fonction générée pour la cuisine et la réception : horaires, effectifs, configuration, régimes alimentaires. - La transmission du bloc de chambres au logiciel hôtelier concerné. ## Explicitement hors périmètre Nous ne remplaçons pas le logiciel de gestion hôtelière : il reste maître des chambres, du séjour et de la facturation. Sont exclus la caisse du restaurant, la paie, les plannings du personnel, les achats alimentaires et la réservation de tables individuelles. Le site public reste tel quel : pas de réservation de salle en libre-service à ce stade. ## Quand est-ce terminé 1. Un commercial produit un devis complet pour un séminaire de 40 personnes avec hébergement en moins de vingt minutes, depuis un ordinateur portable en clientèle. 2. Une salle ne peut pas être posée deux fois en ferme pour le même créneau : la tentative est refusée par le système, pas par la vigilance d'un collègue. 3. Une option non confirmée expire seule à la date convenue et libère la salle, sans intervention humaine. 4. Le client accepte le devis en ligne et l'acceptation est horodatée et opposable, sans échange de pièce jointe signée à la main. 5. Chaque matin, la réception et la cuisine impriment ou consultent une fiche de fonction issue du même dossier, sans ressaisie. 6. Le bloc de chambres apparaît dans le logiciel hôtelier de l'établissement dans l'heure suivant la confirmation. ## Contraintes techniques Les trois établissements utilisent la même solution hôtelière mais en instances séparées ; l'éditeur expose une interface facturée à l'appel, ce qui interdit toute synchronisation en boucle courte. Le réseau du plus ancien hôtel est instable en sous-sol, où se trouvent deux salles : le planning doit rester consultable sur un téléphone en 4G. Les tarifs saisonniers doivent être modifiables par la direction sans intervention technique. Hébergement dans l'Union européenne. ## Hypothèses et risques L'hypothèse la plus fragile est que nos trois établissements vendent le séminaire de la même manière. Nous soupçonnons que chacun applique ses propres règles de remise et de gratuité accompagnateur, jamais écrites. Il faut les relever sur trente dossiers récents avant de figer le catalogue tarifaire, sinon le devis généré sera systématiquement corrigé à la main et l'outil abandonné. Le risque organisationnel est la concurrence entre établissements : un commercial qui ne peut plus garder une salle « au chaud » verbalement perdra un levier de négociation, et la direction devra trancher la règle d'attribution avant le déploiement. ## Comment nous mesurons le résultat Délai moyen de réponse de cinq jours ouvrés à moins de vingt-quatre heures. Taux de transformation des demandes séminaires de 22 pour cent à 30 pour cent en un an. Zéro double réservation ferme. Taux d'occupation des salles en semaine de 48 pour cent à 60 pour cent. ## Données personnelles et accessibilité Les dossiers contiennent des coordonnées professionnelles et des régimes alimentaires, dont certains révèlent des données sensibles : conformité RGPD, minimisation, accès limité à la cuisine concernée, effacement des régimes soixante jours après l'événement. Les écrans clients et équipes visent le niveau AA du RGAA, la déclinaison française des WCAG 2.1. ## Budget et calendrier 55 000 – 80 000 €, cinq mois, avec le planning des salles et les options en production sur un seul hôtel sous dix semaines.
Otwórz w edytorze →
- Gastronomia i biznes lokalny🇵🇱94/100
Grafik pracy i obsługa pokoi w hotelu sezonowym
W lipcu grafik zmienia się trzy razy dziennie, a pokojowe dowiadują się o tym z kartki przy windzie.
Przeczytaj brief
# Planowanie zmian i koordynacja pracy pokojowych w nadmorskim hotelu sezonowym ## Problem Prowadzimy nadmorski hotel sezonowy z 96 pokojami i częścią spa. Od czerwca do końca sierpnia obłożenie przekracza 90%, przez resztę roku spada poniżej 35%, a zespół rośnie z 22 do 61 osób, w tym kilkunastu pracowników sezonowych i studentów z umowami zlecenia. Grafik na kolejny tydzień powstaje w arkuszu kalkulacyjnym, jest drukowany i wieszany przy wejściu dla personelu. W szczycie sezonu zmienia się średnio trzy razy dziennie — ktoś choruje, przyjeżdża grupa autokarowa, kończy się umowa studenta. Zmiany są przekazywane telefonicznie i w wiadomościach na komunikatorze, więc w lipcu mieliśmy 11 zmian, na które nikt się nie stawił, oraz dwa dni, w których dwie pokojowe przyszły na tę samą zmianę, a inna sekcja została pusta. Osobno cierpi obsługa pokoi: lista pokoi do sprzątania jest drukowana rano na podstawie stanu z recepcji o 7:00, a wcześniejsze wymeldowania i późne wyjazdy nie trafiają do niej wcale. Recepcja dzwoni do pokojowych, żeby zapytać, czy pokój jest gotowy, średnio 40 razy dziennie. W sezonie zdarza się nam sprzedać pokój, który nie był jeszcze posprzątany, i zameldować gościa z godzinnym opóźnieniem. ## Dla kogo - Czternaście pokojowych w szczycie sezonu, poruszających się po piętrach z wózkiem, wyłącznie z telefonem w kieszeni fartucha, część z nich mówi po polsku słabo albo wcale. - Kierowniczka służby pięter, która układa sekcje i musi wiedzieć w czasie rzeczywistym, ile pokoi zostało. - Recepcja na dwie zmiany, która melduje gości i potrzebuje aktualnego statusu pokoju bez telefonowania. - Kierownik hotelu, który zatwierdza grafik, pilnuje kosztów pracy i limitów godzin przy umowach sezonowych. - Konserwator, który dostaje zgłoszenia usterek dziś na karteczkach. ## Co mamy dziś Arkusz kalkulacyjny z grafikiem, drukowany co tydzień. Grupa na komunikatorze do zmian w ostatniej chwili. System recepcyjny (PMS), w którym są rezerwacje, meldunki i status pokoju, ale do którego personel pięter nie ma dostępu. Papierowa lista pokoi drukowana rano. Zeszyt usterek przy recepcji. Godziny pracy przepisywane ręcznie na koniec miesiąca do listy płac prowadzonej przez biuro rachunkowe. ## Zakres - Grafik zmian z widokiem tygodniowym, publikowany jednym kliknięciem i dostępny na telefonie każdego pracownika. - Powiadomienie o każdej zmianie w grafiku z potwierdzeniem przyjęcia do wiadomości przez pracownika. - Zgłaszanie niedyspozycyjności i prośby o zamianę zmiany, akceptowane przez kierowniczkę pięter. - Przydział sekcji i pokoi do sprzątania generowany z danych PMS i aktualizowany w ciągu dnia. - Zmiana statusu pokoju przez pokojową z telefonu: w trakcie, gotowy, wymaga konserwacji. - Zgłoszenie usterki ze zdjęciem, trafiające bezpośrednio do konserwatora. - Zestawienie przepracowanych godzin na osobę i miesiąc do eksportu dla biura rachunkowego. ## Poza zakresem Nie budujemy własnego systemu rezerwacji ani channel managera — rezerwacje zostają w PMS i tylko je odczytujemy. Nie zajmujemy się naliczaniem wynagrodzeń, składek ani rozliczeniem umów zleceń; eksportujemy godziny, resztę robi biuro rachunkowe. Nie obejmujemy restauracji, spa ani gospodarki magazynowej środków czystości. Nie planujemy modułu dla gości. ## Kiedy uznajemy projekt za zakończony 1. Pokojowa widzi swoją listę pokoi na telefonie i zmienia status pokoju w mniej niż 15 sekund, bez wchodzenia do biura pięter. 2. Recepcja widzi status każdego pokoju bez telefonowania na piętro; liczba takich telefonów spada poniżej pięciu dziennie, mierzona przez tydzień w sierpniu. 3. Każda zmiana w opublikowanym grafiku dociera do pracownika w postaci powiadomienia, a system pokazuje, kto je potwierdził, a kto nie. 4. Grafik nie pozwala zapisać dwóch osób na tę samą zmianę w tej samej sekcji ani zostawić sekcji bez obsady — próba jest sygnalizowana przed publikacją. 5. Zestawienie godzin za pełny miesiąc powstaje jako plik do biura rachunkowego bez ręcznego przepisywania czegokolwiek. 6. Interfejs pokojowej działa w języku polskim, ukraińskim i angielskim, wybieranym przez pracownika. ## Ograniczenia techniczne Wi-fi na korytarzach starszego skrzydła jest nierówne, a w piwnicy i pralni nie ma go wcale, więc aplikacja pracownika musi działać offline i synchronizować się po powrocie zasięgu. Pracownicy korzystają z własnych telefonów, w większości starszych urządzeń z Androidem, więc nie zakładamy instalacji sklepowej ani nowego sprzętu. Dane o rezerwacjach i statusie pokoi pobieramy z interfejsu naszego systemu recepcyjnego, który udostępnia je co pięć minut. Hosting w Unii Europejskiej. Dostępność interfejsu na poziomie WCAG 2.1 AA, z czytelnością przy jasnym świetle na korytarzach. ## Założenia i ryzyka Zakładamy, że status pokoju w PMS jest wiarygodny i że recepcja rzeczywiście odnotowuje wcześniejsze wymeldowania w chwili, gdy się dzieją — dziś część z nich wpisywana jest dopiero po południu. Jeśli to założenie nie jest prawdziwe, przydział pokoi będzie równie nieaktualny jak dzisiejsza kartka, tylko szybciej. Trzeba to sprawdzić na dwóch tygodniach danych z sierpnia, zanim ruszy budowa. Drugie ryzyko jest kadrowe: pracownicy sezonowi przychodzą na sześć tygodni i nikt nie będzie ich szkolił, więc jeśli aplikacji nie da się zrozumieć w pięć minut z telefonu, w szczycie sezonu wróci komunikator i papier. Przetwarzamy dane osobowe pracowników — imię, nazwisko, dane kontaktowe, godziny pracy — więc potrzebujemy podstawy prawnej, określonego okresu przechowywania po zakończeniu sezonu i wpisu do rejestru czynności przetwarzania. Zdjęcia usterek nie mogą zawierać wizerunku gości. ## Jak mierzymy efekt Nieobsadzone zmiany z 11 w lipcu do najwyżej 2 w kolejnym sezonie. Telefony recepcji na piętra z około 40 do mniej niż 5 dziennie. Średni czas od wymeldowania do statusu „pokój gotowy" z 96 do 70 minut. Zero pokoi sprzedanych jako gotowe, gdy nie były posprzątane. Czas układania grafiku tygodniowego z około czterech godzin do jednej. ## Budżet i harmonogram 45 000–65 000 €, cztery miesiące. Kamień milowy: grafik i statusy pokoi działające na dwóch piętrach w trybie pilotażowym do 15 maja, czyli przed startem sezonu, z papierową listą prowadzoną równolegle przez pierwsze dwa tygodnie.
Otwórz w edytorze →
Dostarczone briefy
Prawdziwe projekty, które trafiły przez katalog do zespołów. Nazwy pozostają ukryte; kształt briefu nie.
- CRM integration advisory — B2B food-tech SaaSB2B SaaS / Food tech
- Digital editorial tooling — global streetwear mediaMedia / Fashion
- Digital fundraising presence — humanitarian NGO (AT)Fundraising / Humanitarian
- Campaign platform — international relief NGO (CH)Fundraising / International aid
- Fundraising microsites — paediatric home-care charityFundraising / Healthcare NGO
- Static site builder — academic publishing platformPublishing / Academic
- Brand site — premium custom bicycle manufacturerSport / Manufacturing
- Donation platform relaunch — international relief organisationFundraising / NGO
- Knowledge-sharing platform — international developmentInternational development / Public sector
- International e-commerce — precision clock brandLuxury / E-commerce
- E-commerce platform — personalised chocolateE-commerce / Food
- Academy platform — youth STEM educationEducation / NGO