Live Chat Operator Projects

opportunity

Build Integration to send IONOS Web Orders to Kipos POS

We run a food takeaway and need a developer to build an integration so that orders placed on our IONOS webstore are automatically sent into our Kipos account (https://app.kipos.uk/) and print straight to our kitchen/printer setup with no manual re-entry. This must be production-ready: fast, reliable, and built to handle busy service periods. What the integration must do 1) Capture new online orders from IONOS Detect new orders as soon as they’re paid/confirmed (or the correct “ready for kitchen” status) Pull all relevant order data: Order ID, timestamp Customer name + phone/email Delivery vs collection Address (delivery) / pickup details (collection) Requested time: ASAP vs scheduled (time slot if applicable) Customer notes (allergies, “no onions”, etc.) Items, quantities, variants Modifiers / add-ons / extras (e.g., “extra cheese”, “no sauce”, spice level) Discounts / delivery fee / tips (if present) Payment method/status 2) Create the order in Kipos exactly as the kitchen needs it Push the order into Kipos so it lands in the correct screen/queue as an online order Map all the required fields Ensure delivery/collection is correctly set and visible on print tickets Include requested time clearly (especially for scheduled orders) 3) Auto-printing to kitchen printers Orders arriving in Kipos should auto-print to our configured printer(s), or be inserted into the correct Kipos workflow/status that triggers printing. Key requirements (takeaway-specific) Modifier & note handling (critical) Must support multiple modifiers per item, and multiple items each with their own notes Preserve formatting so the ticket is easy to read during service Handle edge cases like: “No X” and allergy notes Duplicate prevention + reliability No duplicate tickets/orders if a webhook retries or the sync is re-run Retry + failure handling: Automatic retries Clear error logs Optional alert (email) if an order fails to sync Operational timing Webhook/event-driven preferred (near-instant) Polling acceptable only if webhooks aren’t available, but it must still be reliable and efficient Security Secure credential storage (environment variables/secret store) HTTPS, least-privilege access Preferred technical approach We’re open to the best implementation, but we expect this to be either: Middleware service (recommended): listens for IONOS orders and posts to Kipos or Direct plugin/integration if IONOS supports it. Deliverables Working live integration: IONOS → Kipos order creation + printing workflow Configuration options: Which order status triggers sending Item/modifier mapping method Logging dashboard or structured logs (success/failures, retries, duplicates) Documentation: Setup steps How to update menu/mappings Troubleshooting guide Test evidence: At least 10 varied test orders (modifiers, delivery/collection, scheduled/ASAP) Source code + handover (Git repo or zip) Short post-launch support period (bug fixes) Acceptance criteria A new IONOS order appears correctly in Kipos within an agreed time (e.g., under 60 seconds if webhook-based) Ticket prints automatically (or via correct Kipos status trigger) without staff interaction Items, modifiers, notes, times, and delivery/collection details are accurate and readable No duplicates under retries/network issues Clear logs for each order’s sync status To include in your proposal Your recommended approach (webhooks vs polling, architecture, hosting) Relevant experience (POS integrations, online ordering, printers/kitchen workflows) Estimated cost + timeline (phased: build → test → deploy) What you need from us (API access, sample menu, Kipos printer workflow details) Info we can provide to speed things up Sample orders (with modifiers/notes) Our current IONOS product list/menu structure Screenshot/video of our Kipos order screen + print output requirements Printer setup details inside Kipos (single printer or multiple stations)

SportPress Customisation - Wordpress

Job Specification – SportPress Customisation Project: Manager & Referee Login Portals + Match Workflow Platform: WordPress (SportPress Plugin) Objective: Build simple, user-friendly login areas for team managers and referees, with a controlled workflow for adding players, submitting match scores, and completing match reports. ⸻ 1. Overview We need two new user login areas—Manager Portal and Referee Portal—integrated with the existing SportPress plugin. These portals must be extremely simple and intuitive, suitable for non-technical users. The system must allow managers to log in, and complete their portion of match reports. Referees must be able to log in to see their assigned fixtures, record the score, and record disciplinary actions. Notifications and approval flows must be integrated. ⸻ 2. User Types 2.1 Managers • Log in to a dedicated Manager Portal. • Add players to their team (pending approval by admin before visible/active). • Receive notifications when referee has completed match data. • Complete their portion of the match report: • Goalscorers • Yellow/red cards for their players (if applicable) 2.2 Referees • Log in to a dedicated Referee Portal. • Access a list of their assigned matches only. • After the match: • Enter the final score. • Enter yellow/red cards issued (per team & player). • Submitting this triggers notifications to both teams’ managers. 2.3 Admin (Me) • Approves new players added by managers. • Can override any match data. • Receives notifications when managers and referees complete their steps. ⸻ 3. Functional Requirements 3.1 Login Portals • Entry points: • /manager-login • /referee-login • Clean, mobile-friendly UI (these users will likely be on phones). • Custom role types: • manager • referee • Restrict backend access — portals must be front-end based only. ⸻ 3.2 Manager Portal Features 1. Dashboard • Upcoming fixtures • Completed fixtures requiring match reports • Team information 2. Player Management • Add player (form fields TBD – basic info only) • Status: Pending approval / Approved • Admin receives notification when new player is submitted 3. Match Report Completion Managers should only be able to edit the following: (once completed they cannot edit) • Goals scored (select players; number of goals) • Cards for their own players (yellow/red) Validation: • Manager cannot enter scores; only referee can. • Manager cannot edit other team’s data. 4. Notifications • Email/push notification when: • Referee submits match result • Admin approves/rejects a player ⸻ 3.3 Referee Portal Features 1. Dashboard • Assigned matches • Match status indicators (e.g., pending input / completed) 2. Match Submission Form After the match, the referee should be able to record: • Final score (home/away) • Yellow cards (team → player → minute) • Red cards (team → player → minute) • Any admin notes 3. Submission Workflow • When submitted: • Lock referee fields from further editing • Trigger notification to both managers to complete their match report ⸻ 3.4 Data Workflow Summary Step 1: Match Played • Referee logs into Referee Portal → selects the match → enters: • Score • Cards • Submits match result. Step 2: Managers Notified • Both team managers receive notification (email/SMS if possible). Step 3: Managers Complete Match Reports • Each manager logs into Manager Portal. • Completes: • Goals • Cards for their players • Submits. Step 4: Data Goes Live • Once both teams submit, or after admin approves: • Results appear publicly on the website via SportPress. ⸻ 4. User Experience Requirements • Extremely simplified front-end UI. • No WordPress backend exposure. • Mobile-first responsive design. • Minimal fields and clicks. • Use large buttons, clear icons, and straightforward navigation. ⸻ 5. Technical Requirements • Integrate fully with SportPress custom post types and match data structures. • Custom post status for “player pending approval”. • Custom notifications (email or integrated WP notifications). • Use WordPress user roles/capabilities for access control. • Ensure compatibility with existing SportPress widgets and shortcodes. ⸻ 6. Deliverables • Functional Manager Portal (frontend). • Functional Referee Portal (frontend). • End-to-end workflow for match submission. • Player approval workflow. • Notification system. • Documentation for: • Adding managers/referees • Assigning referees to matches • Approving players • Editing match data