Build a POS-connected customer operations application

Why use this

1. A restaurant owner may want ordering, customer history, loyalty and reporting to work together, yet each area can use different identifiers and definitions. A polished prototype can conceal inconsistent totals or expose customer data to the wrong staff role.

2. A bounded prototype plan could show how the requested workflows connect and which integration questions remain unresolved. Reviewing synthetic records first would help the owner distinguish useful interface behavior from an application ready to affect real orders or payments.

Why an agent / simpler alternative

Useful judgment

Translate operational requirements into connected user flows and expose conflicting definitions.

Simpler alternative

Configure existing POS features when they already cover the required workflow.

Unsuitable when

Production integration, payment security or support ownership cannot be established.

Proposed inputs

1. Name

   Operational requirements

   Owner

   Restaurant owner

   Minimum scope

   Specific ordering, history, loyalty and reporting tasks

   Quality check

   Separate essential workflows from optional ideas.

2. Name

   Approved system descriptions

   Owner

   System owner

   Minimum scope

   Redacted field definitions, role permissions and synthetic transactions

   Quality check

   Confirm identifiers and which system is authoritative for each record.

Access and setup — proposed or unknown

Proposed minimum

1. Synthetic data and isolated prototype workspace; no production POS access.

Compatibility unknowns

1. Unknown: exact runtime, POS APIs, data model, deployment environment and supported integrations.

External actions requiring approval

1. Connecting production systems, migrating customer data, changing orders or deploying the application.

Expected deliverable and review checks

Proposed artifact

Prototype scope, linked screen flows and a reconciliation checklist for synthetic transactions.

Critical checks

1. Orders, customer history and loyalty events share verified identifiers.

2. Reports reconcile with transaction status and respect staff access boundaries.

Missing output evidence

No application build, integration test or operational deployment is added by this overlay.

Failure signals and proposed responses

1. Signal

   A cancelled order still earns loyalty credit.

   Why it matters

   Connected workflows may disagree about the customer’s balance.

   Proposed response

   Define reversal behavior and hold the flow until records reconcile.

2. Signal

   Two customers share a contact field.

   Why it matters

   A simplistic match may merge unrelated histories.

   Proposed response

   Use explicit customer identifiers and flag ambiguous matches.

Effort and cost — unknown

Setup work

1. Define source-of-truth rules and prototype acceptance scenarios.

Ongoing review

1. Review reconciliation, permissions and operational support needs.

Unknowns

1. Unknown: integration cost, hosting, security review and maintenance effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invented transactions include a cancelled order and two customers with similar contact details.

Acceptance checks

1. Cancellation effects remain consistent across reporting and loyalty.

2. Customer histories remain separate.

Stop conditions

1. Real payment data, production credentials or deployment authority is required.

Limits

1. Editorial prototype decision aid; an attributed build does not establish production readiness.