Frequently Asked Questions

Cardwatch is a connected commerce platform built for senior living, hospitality and care dining. It brings together point of sale, dining-room service, mobile ordering, self-service, dining check-in, reservations, resident accounts, meal plans, reporting and culinary planning.

Communities can deploy the applications that fit their operation rather than forcing every service point into the same workflow.

No.

Point of sale is an important part of Cardwatch, but the platform extends beyond transactions. Cardwatch also supports full-service dining, mobile ordering, self-order kiosks, dining check-in, reservations, resident and guest accounts, meal plans, reporting, recipes, menus, nutrition information and production planning.

The goal is to connect the work around service rather than create another isolated transaction system.

Cardwatch is designed for organizations that need to connect food service, accounts and commerce across multiple service experiences.

Cardwatch is particularly well suited to environments where residents, guests, employees or other account holders may use several different dining and service points.

• Senior living communities
• Independent and assisted living
• Care and healthcare dining
• Campus and education dining
• Hospitality operations with complex account or service requirements

No.

Cardwatch applications are designed for different jobs. A community may need a café POS, full-service dining, mobile ordering and resident accounts without needing every application on day one.

The right configuration depends on your service points, meal plans, resident experience, administrative processes and culinary workflows.

You can start with the applications that fit your current operation and plan for expansion as your needs change.

serveit is designed for staff-operated counter service, cafés, retail counters and other high-volume transaction points.

hostit is designed for full-service dining where hosts and servers manage seating, tableside orders, resident accounts and checks.

A community can use both when it operates different service models.

orderit is the mobile experience. Residents, guests, employees and authorized users can access dining ordering and reservation workflows from their own device where configured.

skipit is the self-order kiosk experience. It gives residents and guests an on-site touchscreen option for browsing menus, customizing meals and completing an order.

They provide different ways to access the same broader dining environment.

swipeit is designed for dining check-in during busy meal periods.

It can identify a resident, validate the applicable meal-plan or account context and record the dining visit without requiring a traditional POS ordering workflow.

swipeit is for dining operations. It is not positioned as building access, parking access or a general security system.

bookit supports dining and event reservation workflows.

Depending on the community configuration, it can help teams manage:

It is designed to help hosts and administrators organize the reservation process from booking through arrival.

• Reservation locations
• Dates and times
• Party size
• Guest details
• Table assignment
• Arrival and check-in
• Dining or event reservations

trackit is the operational and account-management layer behind service.

It helps teams manage:

It gives administrators visibility into what happens behind the POS, dining and ordering applications.

• Resident and guest accounts
• Meal plans
• Billing activity
• Transactions
• Account activity
• Meal-plan usage
• Revenue and operational reporting

culinaryai supports culinary planning and food-service operations.

It can bring together workflows around:

AI is used to assist culinary teams with planning and administrative work. Culinary, nutrition and clinical decisions remain with qualified professionals.

• Recipes
• Ingredients
• Menus and menu cycles
• Nutrition and allergen information
• Dietary context
• Production planning
• Inventory and vendor connections where configured
• AI-assisted culinary workflows

Yes. Meal-plan management is a core part of the Cardwatch platform.

Cardwatch can support different meal-plan and account structures based on the needs of the community. The exact rules, entitlements, resets, allowances, exceptions and charging workflows are defined during implementation and configuration.

For more complex programs, Cardwatch Professional Services can also help document and design the operating model before configuration.

Yes.

Communities may have residents with different account types, meal-plan rules, allowances or service eligibility. Cardwatch is designed to manage those differences through resident and account configuration rather than requiring staff to remember every exception manually.

The exact configuration depends on the community's meal-plan design.

Cardwatch is designed around connected resident and account context across service points.

A resident may interact with a café, dining room, mobile ordering experience, self-service kiosk or dining check-in workflow without each location becoming a completely disconnected system.

Which accounts, meal plans and tenders are available at each location depends on the community's configuration.

Yes.

Cardwatch applications can support different account and user types, including residents, guests, employees and authorized users, depending on the deployment.

That allows communities to build different service rules around the people using each location.

Account access can be made available through configured resident-facing experiences.

The information shown depends on the applications and account features enabled for the community.

During solution planning, Cardwatch can review what information residents should be able to see and where that access should appear.

Resident-account charging can be supported where configured.

This can extend beyond traditional dining and can be useful at service points such as cafés, convenience retail, gift shops or community-service counters.

Supported tenders and charging rules depend on the deployment.

Yes.

orderit provides a mobile ordering experience that can allow residents, guests, employees and authorized users to choose a location, select an order type, browse menus, customize items and complete an order where those functions are configured.

They do not have to.

Cardwatch supports multiple service models, including:

The objective is to give the community different ways to serve people, not force everyone into one interface.

• Staff-assisted counter service with serveit
• Full-service dining with hostit
• Self-service kiosk ordering with skipit
• Mobile ordering with orderit

Yes, where reservation functionality is enabled.

Resident-facing reservation workflows can be available through orderit, while staff and administrators can manage reservations through bookit.

The exact workflow depends on how the community wants reservations to operate.

Guest and authorized-user workflows can be supported depending on the application and community setup.

This can include ordering, reservations, guest dining and account or payment workflows where configured.

The community determines the appropriate access and rules during implementation.

No.

Cardwatch is designed to reduce administrative friction around service, not replace hospitality.

The technology supports tasks such as ordering, account validation, reservations, meal-plan management, production planning and reporting so staff can spend more of the dining experience focused on residents and guests.

Cardwatch supports integrations based on the applications, data requirements and systems involved in a deployment.

Integration discovery is normally part of implementation planning. Cardwatch reviews what data needs to move between systems, how often it needs to move and which system should remain the source of record.

Not every integration is available in every deployment.

PointClickCare-related integration workflows may be available for applicable deployments. Confirm production availability, the specific data exchanged and integration scope directly with Cardwatch, since requirements vary by organization and use case.

The goal is to reduce duplicate work and make relevant resident or dining information available to the appropriate workflows.

Yes, where those features are configured.

Cardwatch culinary workflows can include information related to ingredients, allergens, dietary restrictions, nutrition and resident food-health context.

Cardwatch supports operational and food-service workflows. Clinical nutrition and medical decisions remain with qualified healthcare and nutrition professionals.

Potential integrations should be reviewed during solution planning.

The right approach depends on:

Cardwatch does not assume every third-party system connects in the same way.

• The system involved
• Available integration methods
• Required data
• Frequency of synchronization
• Ownership of the source data
• Security and compliance requirements

A Cardwatch implementation starts with understanding how the operation works.

Typical planning can include:

The scope depends on the number of communities, applications and systems involved.

• Service locations and workflows
• Resident, employee and guest accounts
• Meal-plan and billing rules
• Devices and printers
• Data migration requirements
• Supported integration discovery
• Application configuration
• Testing and validation
• Staff training
• Go-live planning

Implementation timing varies by project.

Factors can include:

Cardwatch develops the implementation plan around the agreed project scope rather than applying one fixed timeline to every deployment.

• Number of communities
• Applications being deployed
• Service-point complexity
• Meal-plan requirements
• Data migration
• Integrations
• Hardware
• Testing
• Training
• Rollout approach

Data migration can be included in implementation planning where appropriate.

The migration approach depends on the source system, available data, data quality, account structure and agreed project scope.

Cardwatch reviews migration requirements before committing to a specific process.

Yes.

Training and operational enablement can include staff and administrator training, go-live preparation, refresher sessions, train-the-trainer support and workflow documentation depending on the engagement.

The objective is not just to install software, but to help teams understand the workflows they will use every day.

Yes.

Cardwatch is structured as a suite of distinct applications so communities can choose the tools that fit each service point.

A deployment can expand as new locations, service models or operational requirements are introduced, subject to configuration, licensing and implementation requirements.

Cardwatch deployments can include different hardware depending on the workflow, such as:

Hardware selection should be confirmed during solution planning so the equipment matches the intended applications and service environment.

• POS terminals
• Tablets
• Self-service kiosks
• Payment devices
• Printers
• Resident or guest mobile devices

The public information available here does not provide enough detail to make deployment-specific claims about product security. Specific product-security controls, hosting and compliance requirements should be confirmed directly with Cardwatch during procurement or implementation and reviewed for the applicable deployment and customer agreement.

Cardwatch does not sell user data. This does not mean information is never processed by service providers. The public Privacy Policy covers the Cardwatch marketing website and demo requests only; it does not describe Cardwatch applications, customer agreements or resident information.

Role-based access can be used to control access to information and functions.

The specific roles and permissions available depend on the application and configuration.

Access requirements should be defined during implementation so staff have the information needed for their responsibilities without unnecessary access.

Hosting, data-residency and environment requirements can vary by deployment and customer agreement.

Because those requirements may differ between organizations and jurisdictions, Cardwatch should confirm the applicable hosting model during procurement and implementation rather than publishing one answer for every customer.

Cardwatch pricing depends on the package, applications, devices, implementation services and configuration selected.

The best starting point is the current Pricing page or a conversation with the Cardwatch team to identify the applications and service points your organization actually needs.

No.

The purpose of the application model is to let communities choose the tools that fit their workflows.

Your configuration may combine several applications across different locations while leaving out applications that are not relevant to your operation.

Software subscriptions, hardware, implementation and Professional Services may be scoped separately depending on the proposal or agreement.

The applicable inclusions and costs should be confirmed in your Cardwatch proposal.

Existing customers can contact Cardwatch Support by phone or email, or use the Cardwatch support portal for technical assistance.

For questions about the platform, applications, pricing or a potential deployment, contact Cardwatch Sales.