On this page
Configure a synthetic test run
No real guest details, credentials or card information. Use the provider’s approved environment and testing process.
Your test pack will appear here
Choose the operations you intend to verify. Stated product support is not a passing test.
What the evidence gates mean
Untested means no observed result has been recorded. Blocked means the test could not run, for example because access or configuration was missing. Failed means the observed outcome did not match the expected behavior. Passed means your reviewer says it matched. A pass counts as documented only when you add an evidence reference.
Evidence references should point to your own controlled test records, redacted screenshots or incident documents. The workbench stores the reference text locally but does not open or validate the evidence. It never converts a provider’s marketing claim into a pass.
Safe test operation
Confirm the exact account, product, permissions and test environment with the integration owner. If a test uses live restaurant capacity, arrange approval and cleanup first. The pack’s synthetic venue and booking references are placeholders, not usable API identifiers or account credentials.
Date and timezone validation catches malformed inputs, but it does not calculate actual bookable slots or resolve daylight-saving conflicts. Include a dedicated clock-change test when relevant to your venue. JSON and CSV exports preserve the declared scope and incomplete evidence gates.
Local draft and export behavior
Optional saved drafts use browser local storage on this device. Reset removes the local draft. Changing the configuration marks the current pack as stale and disables export until you generate the new pack. Export an earlier run before changing its scope if you want to retain its evidence history.
Nothing is submitted to the booking systems or to Loman. See methodology and privacy for the limits of this planning tool.
Customer evidence for your booking handoff
Include a scenario where the correct outcome is a handoff to a person. Little Italy’s retained reservation role gives that test a concrete operating purpose rather than treating every transfer as a failure.
Results and operating context from Loman’s published customer case studies.
Little Italy
- Over 24%
- reduction in restaurant labor costsReported since adding Loman; comparison period not specified.
- 1 retained phone person
- questions, reservations and human requestsThe hybrid workflow described after adoption.
Add a test in which the caller asks for a reservation or a person, the request reaches the designated human and the caller receives an accurate next step. Little Italy’s retained phone person makes that an intended service path, not an automatic test failure. Its reported labor result concerns the wider phone/takeout workflow.
Read the Little Italy case study ↗Watch Little Italy on YouTube ↗
Start with the full lifecycle of one synthetic booking
Choose your system, venue timezone, date and party size. Include availability, creation, change and cancellation. Generate the pack before running cases, and use one recorded booking reference to connect the lifecycle evidence. Mark an operation blocked if the provider cannot supply a safe test environment.
Review the selected system’s documentation: OpenTable, Resy or SevenRooms. Those links identify stated Loman capabilities. They do not create an API connection or supply results to this tool.