Erfahren Sie, wie Sie eine Web‑App für RFQs, Lieferantenantworten und Angebotsvergleiche entwerfen und bauen — Datenmodell, Workflows, UI, Sicherheit und Rollout‑Tipps.
Bevor Sie Bildschirme entwerfen oder eine Tech‑Stack auswählen, legen Sie fest, was der Workflow von Anfang bis Ende leisten muss. Ein klarer Scope verhindert „RFQ‑Creep“ (jede Abteilung fügt eigene Randfälle hinzu) und macht die erste Version sofort nutzbar.
Nennen Sie zuerst die primären Rollen und die Abgrenzungen zwischen ihnen:
Ihr MVP‑Workflow umfasst typischerweise:
„Nebeneinander“ kann in Organisationen sehr unterschiedlich sein. Entscheiden Sie früh, welche Dimensionen erstklassig sind:
Erfassen Sie harte Anforderungen früh, denn sie prägen Ihr Datenmodell und UI:
Sobald diese abgestimmt sind, können Sie Workflow‑Zustände und Berechtigungen viel zielgerichteter gestalten.
Ein klarer RFQ‑Prozess unterscheidet „jeder denkt, es ist erledigt“ von einem Workflow, dem Ihr Team vertraut. Definieren Sie vor dem Bau der Bildschirme die Zustände, durch die ein RFQ laufen kann, wer es bewegen darf und welche Nachweise in jedem Schritt vorhanden sein müssen.
Halten Sie Zustände simpel, aber explizit:
Definieren Sie, was angehängt oder erfasst werden muss, bevor das RFQ weitergeschaltet werden darf:
Das sorgt dafür, dass die App gute Praktiken durchsetzt: kein "versendet ohne Anhänge", kein "Zuschlag ohne Bewertungsprotokoll".
Modellieren Sie mindestens: Requester, Buyer, Approver, Supplier und optional Finance/Legal. Entscheiden Sie Genehmigungstore früh:
Verknüpfen Sie Benachrichtigungen mit Zustandswechseln und Fristen:
Ihr Datenmodell entscheidet, ob eine RFQ‑Management‑App flexibel bleibt oder schwerfällig wird. Streben Sie eine saubere Kette an: „RFQ → eingeladene Lieferanten → Angebote → Bewertung → Zuschlag“, mit genügend Struktur für Funktionen wie Preisvergleichstabellen, Mehrwährungsangebote und Audit‑Trails.
Beginnen Sie mit einer RFQ‑Entität für Header‑Felder, die für die ganze Anfrage gelten: Projekt/Referenz, Fälligkeitsdatum und Zeitzone, Standardwährung, Lieferort (Ship‑to), Zahlung/Incoterms und Standardkonditionen.
Modellieren Sie RFQ Line Items separat. Jede Position sollte SKU/Leistungsbeschreibung, Menge, Mengeneinheit und Ziel‑Specs speichern. Fügen Sie explizite Felder für akzeptable Ersatzartikel/Alternativen hinzu, damit Lieferanten ohne Freitext antworten können.
Eine Supplier‑Entität sollte Kontakte (mehrere E‑Mails/Rollen), bediente Kategorien, Compliance‑Dokumente (Dateien + Ablaufdaten) und interne Leistungsnotizen abdecken. Das unterstützt Automatisierung wie automatisches Filtern, wer eingeladen werden kann.
Ein Quote sollte sowohl mit dem RFQ als auch dem Supplier verknüpft sein, mit positionsbezogenen Antworten: Stückpreis, Währung, Lieferzeit, MOQ, Gültigkeitsdatum, Kommentare und Anhänge.
Für Mehrwährungsangebote speichern Sie die Originalwährung und einen Wechselkurs‑Snapshot zur Normalisierung. Überschreiben Sie niemals die Lieferanten‑Eingaben — speichern Sie berechnete "normalisierte" Summen separat.
Erstellen Sie eine Evaluation‑Entität für Scoring, Entscheidungsnotizen und Genehmigungen. Kombinieren Sie sie mit einer AuditEvent‑Tabelle, die dokumentiert, wer was wann geändert hat (Statuswechsel, Bearbeitungen, Zuschläge). Das wird das Rückgrat Ihres Genehmigungs‑Workflows und Ihrer Auditierbarkeit.
Für ein minimales Schema halten Sie es einfach: RFQ, RFQLine, Supplier, SupplierContact, Quote, QuoteLine, Evaluation, AuditEvent, FileAttachment.
Eine gute Supplier‑Experience erhöht Antwortraten und reduziert Rückfragen. Entscheiden Sie zuerst, ob Sie wirklich ein Self‑Service‑Portal brauchen oder ob E‑Mail‑Intake genügt.
Bei kleinem Lieferantenstamm, einfachen RFQs und einem Team, das Angebote nacherfassen kann, reicht E‑Mail‑Only als MVP. Ein Portal lohnt sich, wenn Sie strukturierte Antworten (Preise, Lieferzeiten, MOQ, Incoterms), häufige Wiederkäufe, viele Anhänge oder eine belastbare Prüfspur benötigen.
Eine hybride Lösung funktioniert oft am besten: Lieferanten antworten im Portal, bekommen aber E‑Mail‑Benachrichtigungen und können ein RFQ‑PDF herunterladen.
Halten Sie Onboarding schlank. Procurement sollte Lieferanten per E‑Mail einladen können, eine Ablaufzeit für Einladungslinks setzen und optional Basis‑Firmendaten vorbefüllen.
Mindestens sollte Onboarding beinhalten:
Machen Sie klar, was Lieferanten sehen: nur ihre eigenen RFQs, Einreichungen und Statusupdates — nichts anderes.
Das Antworterlebnis sollte Lieferanten durch ein strukturiertes Formular führen und trotzdem Raum für Nuancen lassen.
Enthalten sein sollten:
Nutzen Sie Autosave, klare Validierungsnachrichten und einen "Vorschau‑Absenden"‑Schritt, damit Lieferanten vor dem Absenden bestätigen können.
Lieferanten müssen oft Angebote überarbeiten. Behandeln Sie jede Abgabe als Version: bewahren Sie Historie, Zeitstempel und Einreicher‑Identität. Erlauben Sie Nachreichungen bis zur Frist, sperren Sie danach die Bearbeitung, aber erlauben Sie Leseberechtigung. Wenn Sie das RFQ wieder öffnen, erstellen Sie eine neue Runde, damit Vergleiche sauber und verteidigbar bleiben.
Geschwindigkeit ist wichtig, aber Konsistenz auch. Der beste Weg, beides zu bekommen, ist ein geführter RFQ‑Erstellungsprozess, der Wiederverwendbarkeit (Templates, vorherige Events, Lieferantenlisten) fördert und jede Änderung nachvollziehbar hält.
Bauen Sie einen Wizard, der mit einem Template startet: Standardkonditionen, Pflichtfelder, Standard‑Positionsspalten (Lieferzeit, Incoterms, Garantie) und eine voreingestellte Timeline.
Für Wiederholungskäufe fügen Sie eine "copy from previous RFQ"‑Funktion hinzu, damit ein Buyer Positionen, Anhänge und eingeladene Lieferanten klonen und nur das Anpassen muss, was sich geändert hat.
Für größere Events unterstützen Sie Bulk‑Positions‑Import via CSV. Seien Sie fehlertolerant: zeigen Sie eine Vorschau, markieren Sie invalide Zeilen und lassen Sie Spalten zuordnen (z. B. "Unit Price" vs. "Price/EA"). Das reduziert manuelle Eingabe ohne Kontrolle zu verlieren.
Die Lieferantenauswahl sollte schnell, aber deliberate sein. Bieten Sie eine genehmigte Lieferantenliste pro Kategorie und Vorschläge basierend auf historischer Teilnahme, früheren Zuschlägen oder Geographie.
Ebenso wichtig: Ausschlüsse. Erlauben Sie Buyer, Vendoren als "nicht einladen" zu markieren (Konflikt, Performance, Compliance) und eine kurze Notiz zu verlangen. Das liefert Kontext später bei Genehmigungen und Audits.
Generieren Sie ein klares "RFQ‑Pack", das Anhänge (Zeichnungen, Specs), kommerzielle Konditionen und Antwortanweisungen bündelt. Fügen Sie eine explizite Q&A‑Policy bei: ob Fragen privat oder geteilt werden und die Cutoff‑Zeit für Klarstellungen.
Zentralisieren Sie Kommunikation im RFQ. Unterstützen Sie Broadcast‑Nachrichten an alle Lieferanten, private Q&A‑Threads und Addenda‑Tracking (versionierte Änderungen an Specs, Terminen oder Mengen). Jede Nachricht und jedes Addendum sollte zeitgestempelt im RFQ‑Verlauf sichtbar sein.
Eine Vergleichsansicht funktioniert nur, wenn ein „$10“ überall dasselbe bedeutet. Ziel ist es, jede Antwort in eine konsistente, vergleichbare Form zu bringen und sie dann in einer Tabelle anzuzeigen, die Unterschiede deutlich macht.
Gestalten Sie die Kernansicht als Grid: Lieferanten als Spalten, RFQ‑Positionen als Zeilen, mit berechneten Zwischensummen und einem klaren Gesamtergebnis pro Lieferant.
Fügen Sie ein paar praktische Felder hinzu, auf die Bewertende sofort schauen: Stückpreis, Positionssumme, Lieferzeit, Gültigkeitsdatum und Lieferantennotizen. Detaillierte Notizen einklappbar halten, damit die Tabelle lesbar bleibt.
Die Normalisierung sollte beim Import (oder unmittelbar nach Einreichung) erfolgen, damit die UI nicht raten muss.
Gängige Normalisierungen:
Machen Sie Ausnahmen sichtbar mit leichten Flags:
Bewertende vergeben selten alles an einen Lieferanten. Lassen Sie Nutzer Szenarien erstellen: Zuschlag splitten, Teilmengen vergeben oder Alternativen akzeptieren.
Ein einfaches Muster ist eine "Szenario"‑Schicht über normalisierten Angeboten, die Summen neu berechnet, wenn Nutzer Mengen an Lieferanten zuweisen. Szenario‑Ergebnisse exportierbar halten (z. B. zu /blog/rfq-award-approvals) für Genehmigungsworkflows.
Sobald Angebote normalisiert und vergleichbar sind, braucht die App einen klaren Weg, aus "besser" ein "entschieden" zu machen. Bewertung sollte strukturiert genug für Konsistenz sein und flexibel genug für unterschiedliche Kategorien und Buyer.
Starten Sie mit einer Standard‑Scorecard, die die meisten Teams wiedererkennen, und erlauben Sie pro RFQ Anpassungen. Übliche Kriterien: Kosten, Lieferzeit, Zahlungsbedingungen, Garantie/Support und Lieferantenrisiko.
Jedes Kriterium explizit halten:
Gewichtetes Scoring hilft, zu verhindern, dass immer nur der niedrigste Preis gewinnt, und macht Trade‑Offs sichtbar. Unterstützen Sie einfache Gewichtungen (z. B. 40% Kosten, 25% Lieferzeit, 15% Risiko, 10% Garantie, 10% Zahlungsbedingungen) und erlauben Sie Anpassungen pro RFQ.
Priorisieren Sie Transparenz und Editierbarkeit:
Reale Entscheidungen beinhalten mehr als eine Meinung. Lassen Sie mehrere Bewerter unabhängig bewerten, Notizen hinzufügen und unterstützende Dateien hochladen (Specs, Compliance‑Docs, E‑Mails). Zeigen Sie dann eine konsolidierte Ansicht (Durchschnitt, Median oder rollen‑gewichtet), ohne die Einzelaingaben zu verbergen.
Das System sollte eine "Zuschlagsempfehlung" erzeugen, die bereit zum Teilen ist: vorgeschlagene Lieferant(en), zentrale Gründe und Trade‑Offs. Unterstützen Sie Ausnahmebehandlung — z. B. Zuschlag an teureren Lieferanten wegen kürzerer Lieferzeit — mit verpflichtender Begründung und Anhangspflicht. Das beschleunigt Genehmigungen und schützt das Team bei späteren Prüfungen.
Ein Angebotsvergleichs‑Tool funktioniert nur, wenn Menschen der Entscheidung vertrauen und belegen können, wie sie entstanden ist. Das erfordert Genehmigungen, die zur Beschaffungsrichtlinie passen, Berechtigungen, die unbefugte Änderungen verhindern, und einen Audit‑Trail, der Prüfungen standhält.
Starten Sie mit wenigen Genehmigungsregeln und erweitern Sie sie bei Bedarf. Übliche Muster:
Machen Sie Genehmigungen im UI lesbar ("warum wartet das?") und verlangen Sie Re‑Approval bei materiellen Änderungen (Scope, Mengen, Schlüsseltermine, Preisabweichungen über Schwellen).
Definieren Sie Rollen um reale Aufgaben:
Denken Sie auch an feingranulare Rechte wie "Preise sehen", "Anhänge herunterladen" und "nach Veröffentlichung bearbeiten".
Protokollieren Sie "wer hat was wann" für RFQ‑Bearbeitungen, Lieferantenangebot‑Updates, Genehmigungen und Zuschlagentscheidungen — inklusive Anhänge und wichtige Feldänderungen. Bieten Sie Exportoptionen (CSV/PDF plus zugehörige Dokumente) und definieren Sie Aufbewahrungsregeln (z. B. 7 Jahre; Legal Holds), um Audits zu unterstützen.
Eine RFQ‑App lebt von Workflow‑Zuverlässigkeit: Fristen, Revisionen, Anhänge und Genehmigungen müssen vorhersehbar funktionieren. Ein praktisches Backend‑Muster ist ein modularer Monolith (single deploy, klare Module) mit einer Job‑Queue und einer API‑first Oberfläche — leicht erweiterbar und einfach zu betreiben.
Wenn Sie Lieferung beschleunigen wollen, kann ein Vibe‑Coding‑Workflow helfen, End‑to‑End‑Prototypen schnell zu erstellen. Teams nutzen beispielsweise Koder.ai, um den RFQ‑Workflow in Klartext zu beschreiben, eine funktionierende React‑UI und Go + PostgreSQL‑Backend zu generieren und dann den Quellcode zur internen Prüfung zu exportieren.
Designen Sie um ein paar vorhersehbare Ressourcen und lassen Sie das UI die Komposition übernehmen.
POST /rfqs, GET /rfqs?status=&category=&from=&to=, GET /rfqs/{id}, PATCH /rfqs/{id} (Zustandsübergänge), POST /rfqs/{id}/invite-suppliersGET /suppliers, POST /suppliers, GET /suppliers/{id}POST /rfqs/{id}/quotes (Lieferant submit), GET /rfqs/{id}/quotes, PATCH /quotes/{id} (revise), POST /quotes/{id}/line-itemsPOST /files/presign (upload), POST /files/{id}/attach (zu RFQ/Quote/Message)GET /rfqs/{id}/messages, POST /rfqs/{id}/messagesPOST /rfqs/{id}/approvals, POST /approvals/{id}/decision (approve/reject), GET /rfqs/{id}/auditNutzen Sie eine Queue für Erinnerungen ("noch 3 Tage"), Fristensperren (auto‑close Einreichungen) und Wechselkurs‑Updates für Mehrwährungsangebote und normalisierte Vergleiche.
Speichern Sie Dateien in Object‑Storage mit signed URLs (kurze TTL), erzwingen Sie Größenlimits und führen Sie Virus‑Scans beim Upload durch. Halten Sie Metadaten (Hash, Dateiname, Owner, verknüpfte Entität) in der Datenbank.
Unterstützen Sie mindestens Filterung nach RFQ‑Status, Lieferant, Kategorie und Datumsbereichen. Beginnen Sie mit DB‑Indizes; fügen Sie später eine Suchmaschine hinzu, wenn nötig.
Security ist nicht nur Hack‑Prävention — es geht darum, dass die richtigen Personen die richtigen Daten sehen und dass Vorgänge nachvollziehbar bleiben.
Entscheiden Sie, wie sich Nutzer anmelden:
Unterstützen Sie MFA (Authententicator‑App oder E‑Mail‑Codes). Bei Passwörtern klare Regeln: Mindestlänge, rate‑limiting und Blockierung bekannter kompromittierter Passwörter.
RFQ‑Daten sind kommerziell sensibel. Standard sollte strikte Isolation sein:
Am einfachsten durchzusetzen, wenn jede API‑Anfrage sowohl Identity (wer) als auch Authorization (was erlaubt ist) prüft — nicht nur das UI.
Quote‑Eingaben bergen viele Edge‑Cases. Validieren und normalisieren an den Rändern:
Behandeln Sie Uploads als untrusted: scannen, typ‑/größenlimitieren und separat speichern.
Audit‑Logs sind am wertvollsten, wenn sie selektiv und lesbar sind. Tracken Sie Events wie:
Koppeln Sie Logging an Monitoring, damit verdächtige Muster Alerts auslösen — und stellen Sie sicher, dass Logs keine sensiblen Werte (Passwörter, vollständige Zahlungsdaten) enthalten.
Integrationen machen ein RFQ‑Tool zum Teil der täglichen Arbeit. Ziel: wenige, hochwirksame Verbindungen, die Tipp‑Arbeit reduzieren und Genehmigungen beschleunigen.
Starten Sie mit Flows, die manuelle Abstimmungen überflüssig machen:
Bauen Sie das als Integrationslayer mit idempotenten Endpunkten (safe to retry) und klarer Fehler‑Feedback‑Logik.
E‑Mail bleibt Standard‑UI für Lieferanten und Approver.
Senden Sie:
Generieren Sie optional Kalender‑Holds für Schlüsseltermine (RFQ‑Close, Evaluations‑Meeting).
Exporte helfen Stakeholdern, die selten einloggen.
Bieten Sie:
Stellen Sie sicher, dass Exporte Berechtigungen respektieren und sensible Felder ggf. redigieren.
Webhooks erlauben anderen Tools, in Echtzeit zu reagieren. Veröffentlichen Sie Events wie:
quote.submittedapproval.completedaward.issuedLiefern Sie ein stabiles Event‑Schema, Zeitstempel und IDs (RFQ‑ID, Supplier‑ID). Fügen Sie Signing‑Secrets und Retry‑Logik hinzu, damit Empfänger Authentizität prüfen und temporäre Fehler handhaben können.
Eine RFQ‑Lösung steht oder fällt mit Adoption. Ein fokussiertes MVP hilft, schnell zu liefern, Wert zu beweisen und zu vermeiden, dass Sie fortgeschrittene Features vor der Validierung bauen.
Unverzichtbare Screens und Regeln, damit ein Team echte RFQs end‑to‑end durchführen kann:
Wenn Sie schnell iterieren wollen, überlegen Sie, die erste funktionierende Version in Koder.ai zu generieren und dann Snapshots/Rollbacks sowie Quellcode‑Export zu nutzen, um Änderungen mit Stakeholdern zu prüfen.
Starten Sie mit einer Kategorie (z. B. Verpackung) und einer Handvoll kooperativer Lieferanten.
Führen Sie kurze Zyklen: 1–2 RFQs/Woche, dann 30‑minütige Review‑Meetings mit Nutzern. Erfassen Sie Friktionen (fehlende Felder, verwirrende Zustände, Supplier‑Drop‑Offs) und beheben Sie sie, bevor Sie ausweiten.
Messen Sie Wirkung mit wenigen Metriken:
Sobald das MVP stabil ist, priorisieren Sie:
Für Planung und Packaging fügen Sie einfache "Next Steps"‑Seiten wie /pricing und ein paar Educational‑Guides unter /blog hinzu.
Beginnen Sie damit, den End-to-End‑Workflow zu dokumentieren, den Sie unterstützen müssen (RFQ‑Erstellung → Einladungen → Q&A → Einreichungen → Vergleich → Bewertung → Zuschlag → Abschluss). Definieren Sie dann:
Das verhindert „RFQ‑Creep“ und macht Ihre erste Version nutzbar.
Erzwingen Sie Berechtigungen in der , nicht nur im UI, damit Regeln nicht umgangen werden können.
Halten Sie Zustände einfach, aber eindeutig, und legen Sie fest, wer sie überführen darf:
Legen Sie "erforderliche Artefakte" pro Phase fest (z. B. RFQ‑Paket vor Versand; Bewertungsprotokoll vor Zuschlag).
Behandeln Sie Kommunikation als erstklassiges, prüfbares Element:
Ein praktisches Minimalschema ist:
RFQ, Normalisieren Sie früh (bei Einreichung/Import), nicht nur bei der Anzeige:
In der Vergleichsansicht zeigen Sie sowohl als auch einen pro Lieferant.
Nutzen Sie ein Portal, wenn Sie strukturierte, vergleichbare Daten und eine belastbare Prüfspur brauchen:
Email‑Only kann für sehr kleine Lieferantenkreise funktionieren, führt aber oft zu manueller Nacharbeit. Ein Hybrid (Portal + E‑Mail‑Benachrichtigungen/PDF‑RFQ‑Pack) ist oft der beste Kompromiss.
Behandeln Sie jede Lieferanteneinreichung als versioniertes Angebot:
Wenn Sie das Event wieder öffnen, erstellen Sie eine neue Runde, statt frühere Einreichungen zu überschreiben.
Halten Sie Scoring transparent und an Belegen orientiert:
Die Ausgabe sollte eine "Zuschlagsempfehlung" mit Begründung und Flags für Ausnahmen liefern.
Machen Sie Richtlinien‑Durchsetzung explizit und prüfbar:
Priorisieren Sie Integrationen für:
Das reduziert Nachfragen und schafft eine verteidigbare Historie.
RFQLineSupplier, SupplierContactQuote, QuoteLineEvaluationAuditEventFileAttachmentWichtige Designentscheidungen:
quote.submitted, award.issued)Wenn Sie Szenario‑Ergebnisse für Genehmigungen benötigen, halten Sie Exporte referenzierbar (z. B. zu /blog/rfq-award-approvals).