Everything operators ask before they switch

Nexora is a restaurant operating platform for people who run more than one restaurant. It joins the point of sale, the staff rota, the purchase ledger and the accounting feed into a single set of books, so you can see what a shift costs while it is still running rather than three weeks after the month closes.

Multi-unit restaurant operators running anywhere from 3 to 3,000 locations — owner-operators, franchisees, franchise groups and the CFOs and area managers who work with them. Every differentiating feature we have, from cross-store comparison to role-scoped access, is worth very little at a single site and becomes the reason to buy at three or more.

No. Nexora reads your existing POS. We do not want to replace the till — changing POS is one of the most disruptive things a restaurant can do, and it is not necessary to get the value Nexora provides.

No. Nexora produces approved hours and labour cost and hands them to payroll. QuickBooks is connected today; other providers are on the roadmap. You keep whatever payroll relationship you already have.

Not in the sense of a general ledger you would file taxes from. Nexora produces a store-level P&L from POS sales and your expense data, with a chart of accounts behind it, so you can see the shape of a month long before your accountant closes it. Most customers keep their accountant and give them a cleaner starting point.

The gap between the shift and the number. A restaurant's two largest controllable costs are food and labour; together over sales they give prime cost, the ratio that decides whether a location makes money. Most operators learn theirs about three weeks after the period it describes, by which point every shift has been worked and every case of chicken used.

Prime cost is cost of goods plus labour cost, divided by net sales. It is the single number that most reliably predicts whether a restaurant is profitable, and unlike rent or insurance it is controllable week to week. In our pilot group of twelve stores the spread ran from 23.60% at the best location to 75.84% at the worst — same brand, same menu, same suppliers.

A scheduling app ends when the rota is published. Nexora prices the rota as you build it, charges it against a labour budget, then reconciles it against what the till and timeclock actually recorded — per employee, per store. The schedule is an input to the money, not the product.

Enough to run daily P&L, labour, inventory and reviews for a multi-unit estate from one login, with more shipping on an ongoing basis. Anything not yet live is marked Coming soon inside the product rather than hidden.

Actively being built, and we say so inside the product rather than hiding it. Unfinished sections are labelled Coming soon and point at the screen that does the job in the meantime. What is live is in production use across a twelve-store group today.

You handle the food, the floor and the guests. Nexora handles the reconciliation, the reporting and the arithmetic underneath — the work that has to happen but generates no covers.

It runs, and the dashboard, scheduling and P&L all work at one site. But we are honest that the return is much smaller: cross-store comparison, role scoping and group reporting are where the value concentrates. If you have one location we would rather you came back when you open the second.

A workspace with locations, roles and departments can be configured the same day. The step that determines when your numbers become trustworthy is POS employee mapping, and that depends on how many staff the till knows — see the POS section below.

Your store list with addresses, POS access or an export, a staff roster (a CSV is fine), and whoever owns the monthly close. If you want the P&L populated from day one, add the last few months of expense records or bank statements.

Yes. Team has a CSV import with a documented column specification — name, email, phone, role, employment type, pay type and rate. You can also add people one at a time, and either way they are immediately schedulable.

No. Most groups start with two or three locations, prove the numbers reconcile, then add the rest. Locations are added in Settings at any time and the reporting scope follows automatically.

Clear the unlinked POS employee list. Until that is done, labour cost coverage sits below 100% and every labour ratio in the product reads artificially low. It is the highest-value setup task and it only has to be done once.

The share of worked hours that have a POS cost attached, expressed as a percentage. In the pilot group it began at 67.9%, meaning roughly a third of all hours worked — 6,043 of them in one month — carried no cost at all and were therefore missing from every report.

Yes. Departments and roles are configured in Settings and are used throughout scheduling and reporting. The pilot group runs Operations, Management, Sales and Front Desk, with roles including Cook, Cashier, Concierge, Shift Lead, Operations Associate and Manager.

Yes. Business hours are set per location in Settings, and shifts scheduled outside them are flagged so a 3am close does not slip through unnoticed.

Both. The product is designed to be set up without us, but for multi-unit groups we run the first configuration with you — locations, roles, POS mapping and the first month's close — because getting the mapping right early determines whether you trust the numbers later.

A reusable shift pattern — an opening cook, a midday cashier, a closing shift lead — with the role, department, times and break pre-filled. It turns building a week from typing into clicking.

Yes, and we prefer it. Pick your best-performing store and your worst. If Nexora cannot show you something about the worst one you did not already know within the first month, the rollout should not happen.

Add it in Settings → Locations with its address and geofence radius, assign the people who work there, and it appears in every scope selector and report from that point on. Historical reporting for other stores is unaffected.

Nexora reads sales, order and labour data from your existing point of sale. PAR is certified today and runs the live twelve-store pilot deployment.

Beyond PAR the test is capability rather than brand: if your point of sale can export sales and timeclock data, we can connect it. Tell us which one you run and we will confirm it in writing before you commit to anything. We would rather decline a system we have not connected than discover it in week three of your onboarding.

If your group runs more than one POS across locations — common after an acquisition — say so early. It changes the implementation more than most operators expect.

Your POS knows every person who has ever clocked in on it. Your roster knows every person you employ. Those two lists are never identical — people get added at the till, names are spelled differently, old logins linger. Anyone on the POS list who is not linked to a Nexora record has their hours and cost reaching no report at all.

More than operators expect. In the pilot group the POS knew 553 people at the selected stores; 257 of them were not linked to a team member, carrying 1,253 unattributed hours in the trailing 90 days.

Effectively one-time. Linking a POS employee applies retrospectively to every hour they have ever worked, not just from today forward — so one afternoon of matching corrects your entire history.

Nexora separates them. The unlinked list is split into Needs linking, Already linked and Tills & test logins, so you are not asked to find a human behind a terminal account.

No, deliberately. Unmapped hours are left out of labour cost rather than priced at an assumed rate, and the dashboard states how many there are. Filling the gap with an assumption would make the number look complete while making it wrong.

Sales and labour data flow through on your point of sale's own reporting cadence. Nexora reads what the POS publishes; it cannot report faster than the source produces, and it does not pretend to.

Separately, the dashboard carries a Live · right now block that reports the floor as it currently stands — shifts on today, hours scheduled, who starts within the next three hours. That block deliberately ignores whatever date range you have selected.

The practical answer for an operator: yesterday closed is there in the morning, and today's floor is there all day.

Slack for shift notifications and schedule updates into channels; Google Calendar for pushing published shifts into employees' personal calendars; and QuickBooks for exporting approved timesheets and labour cost to payroll. A Snowflake warehouse connector is in progress.

A Snowflake connector is in build. In the meantime every report exports to Excel or PDF, and API keys are available under Settings → Developer for connecting an external tool or custom script.

Yes. API keys are issued in Settings → Developer. The product is explicit that most customers never need this — it is there for groups with an internal data team.

Yes. Upload a statement as PDF, Word, Excel, PowerPoint, text or a photo, and Nexora reads it line by line and proposes each charge as an expense against a P&L category. Anything it is not confident about is held as pending for a person to approve, reject or reclassify.

No. Nothing reaches the statement without human approval. Extracted lines sit in a pending queue with their proposed category and account code, and you approve, reject or recode them.

You reclassify it in the queue before it posts. Because approval is required by design, a mis-read line is a two-second correction rather than a journal entry to unwind.

Yes, one connection per store under Settings → Review connections. The connection is read-and-reply only — Nexora cannot delete a listing, transfer it, or change who else has access, and either side can disconnect at any time.

Yes. The scheduler runs on day, week, month or year views and can be scoped to one store or all of them simultaneously. Each row totals the person's hours, their overtime and what they cost.

Yes, and this is the point of the module. Creating a shift sets role, department, store, date, start and end time and break, and prices it immediately — a 7.5-hour shift at $15.00/h shows as $112.50 before it is saved.

It names the people heading past their threshold and prices the exposure before the rota is published. The overtime radar showed a material, avoidable overrun across the pilot period, with the individuals and weeks listed.

A single graded score out of 100 for the scheduled period, weighted toward overtime risk, with every deduction shown per store rather than folded into one number. In the pilot group, graded C overall, one location was clearly responsible for most of the shortfall.

Yes, weekly, in Planning. Nexora forecasts the week's sales from actual POS history — the average of the three preceding weeks and the same week last year — then sets labour at 27% of that forecast, inside the 25–30% band most stores run at. You can overtype either figure.

They are left out of the average rather than counted as zero, which would drag the forecast down and set a labour budget that starves the store.

Yes — plan vs. actual variance, per employee, per store. It compares scheduled shifts against POS and timeclock records and states the hours and cost variance for each person.

Usually one of three things: staff working hours nobody scheduled, staff scheduled who did not work, or unmapped POS employees whose actual hours have no matching plan. The variance table separates them so you can tell which.

Yes — daily, weekly, or on a custom pattern. You can also copy an entire week forward as a starting point rather than rebuilding it.

Yes. Shifts can be saved as drafts while you work and published in bulk when the week is settled.

Through the Slack integration, published shifts and schedule updates go into your channels. Google Calendar pushes published shifts into employees' personal calendars.

Yes. The store manager role can view, edit and publish the schedule, manage people, approve time off and edit attendance for their location. The role is scoped, not supervised.

Yes. A team member can be assigned to several locations and scheduled at any of them, and their hours roll up correctly across stores.

Net sales divided by hours worked. The pilot group ran $45.57 across 18,826 hours in August. It is one of the fastest read-outs on whether a store is over-staffed for its volume.

Total costed labour minutes divided by order count — 25.5 minutes across 44,353 orders in the pilot period. It is useful for comparing formats with different check sizes, where a labour percentage alone can mislead.

Attendance is marked Coming soon in the product. Today, clock-in reconciliation happens through the plan vs. actual variance view, which compares the published rota against POS and timeclock records.

Yes — store-level, per month, sourced from POS sales and your expense data. It runs gross sales through sales tax, discounts, cost of goods, gross profit and operating expenses to EBITDA and net income, with the period beside the year to date.

That is the Comparison view. Every store on identical measures — orders, gross sales, net sales, COGS, labour, gross profit, prime cost percentage, sales per labour hour, average order value — ranked by net sales, with best and worst on prime cost called out.

Yes, and it is honest about its limits. Where no balance sheet has been entered for a month, inventory lines shown are purchases made in that month rather than on-hand stock, they carry no offsetting liabilities or equity, and the product says so on the page and reports the imbalance rather than adjusting figures to close.

Because it is showing you what has actually been recorded rather than what would look tidy. If assets total $220,339.72 against zero liabilities and equity, that is a data-completeness message, not an accounting error — and hiding it would be worse.

In deliberately separate ledgers so nothing is counted twice: an expense log for store-level entries, cost of goods and operating expenses that feed the statement, and a documents queue for uploads. Changes made under Operating expenses appear on the statement; the log does not touch it.

Because the statement takes its operating expenses from the accounting feed. If both fed the same line, a manager logging a receipt and a bookkeeper posting the same invoice would double-count it. The separation is a safeguard, and the product explains it on the page.

Yes. Cost of goods runs 500010 Food Ingredients through 500090 Misc Purchases; operating expenses run 700010 Rent/Lease through 700160 Franchise Fee, covering utilities, insurance, bank charges, delivery marketing, restaurant supplies, licences and more.

Yes, as Excel or PDF, for a single store or the whole group.

In the pilot, one store's June came to $52,052.83: labour and payroll $29,407.98, rent $6,791.66, delivery marketing $3,738.12, utilities $3,387.62, bank charges $2,311.31, COGS adjustments $1,855.20, restaurant supplies $1,511.17, plus insurance, accounting fees and six smaller categories.

Yes, and most customers do. Nexora gives them a cleaner starting point and gives you a view of the month before they close it. We are not trying to replace the person who signs off your accounts.

Yes. Labour, dashboard and P&L summaries can be scheduled weekly, monthly or both. Each arrives as a NexAI summary of the period with the full report attached as a PDF.

Yes, strictly. Each report is built only from what that person can see on the day it goes out, and the store scope follows their access — so locations someone gains or loses are added and dropped from their reports automatically.

Net sales divided by order count, from the POS. The pilot group ran $19.34 across 44,353 orders in August.

Yes, on the dashboard — $9.73 in the pilot period — alongside peak order day and top items by both value and quantity.

Yes, with committed and spent shown separately against the period elapsed. The pilot showed $79,902.92 committed and $209,459.71 spent against a $27,000 budget at 81% of the period elapsed — the kind of divergence that is invisible until something puts the three numbers side by side.

Yes, and it does so unprompted on the dashboard's attention list, with a direct link to set one. Without a budget there is no variance, so the product treats a missing budget as an action rather than a blank.

Three tiers — super admin, admin and store manager — each scoped to a specific list of stores. Scope is resolved at sign-in, so what someone can reach is decided before the page renders rather than by hiding buttons.

No. Store managers can view and edit schedules, manage people, approve time off, edit attendance, view reports and view inventory. They cannot view financials, edit operating expenses or view costs. That line is the whole point of the model.

Yes. Role and store scope are assigned together, so someone can be an admin over their own region and a store manager at a location they are covering.

In Command Center, by email address. No account needs to exist first — the grant binds the first time that person signs in, and until then they show as never signed in, visible and revocable.

One click per store-role assignment. Because each is a separate chip on the person's row, you can remove one location without rebuilding their whole access.

Yes. Every role assignment, supersession, revocation and permission change is recorded with timestamp, actor, action and role, most recent first. Document uploads and archives appear alongside them.

With a one-time code sent to their email address. No password is stored, so there is nothing to phish, reuse or leak, and the credential expires whether or not anyone remembers to rotate it.

Restaurant teams turn over quickly and share devices. A password model in that environment reliably produces written-down credentials and shared logins, which makes an audit log fiction. Removing the password removes the artefact.

Yes. Data is encrypted in transit and at rest, and the sign-in page states that posture rather than burying it in a policy nobody opens.

Two architectural choices matter more than the cipher:

• No password is stored. Access is by a six-digit one-time code sent to your email address. There is no credential to phish, reuse, write on a laminated card by the till, or leak in someone else's breach. Control of the mailbox is the factor.
• Scope is resolved at authentication, not hidden in the interface. When a store general manager signs in, the platform does not load the group's financials and then decline to draw them — the query never asks for them. It is the only version of access control that survives someone typing a URL directly, and the only version a franchisee will accept when their numbers sit in the same database as a competitor's.

Every access grant, supersession and revocation is written to an audit log with timestamp and actor.

If your procurement process requires a completed third-party audit report or a signed DPA before you can evaluate software, raise it in the first ten minutes of the call. We will tell you exactly where we are rather than spend your team's time finding out.

Yes, in Settings → Permissions, which is a grid of every permission against every role. Super admin holds full access and cannot be reduced below it.

Only what they are granted. Because scope is per store and enforced at the session, a brand can be given group-level reporting across the locations that have agreed to it and nothing from those that have not.

The pilot group runs 35 people with access — 7 super admins, 5 admins and 23 store managers. Seat limits depend on plan; see pricing below.

It tracks purchasing, drawn from supplier order history — items purchased, total spend, units received and categories. The pilot group's order history covered 287 items, $4,177,783.00 of spend and 91,286 units across 15 categories.

No, and it says so rather than implying otherwise. In-hand figures shown are estimates derived from purchases and sales, not a counted stock take, and the product labels them as such. If you need true on-hand counts, that is a stock-counting workflow we do not yet have.

Estimated in-hand, quantity received, average price, total spend, order count and the date it last arrived — per SKU, per store, with pack sizes preserved.

Yes. In the pilot: frozen and fresh refrigerated foods $906,688.97, dry goods $798,079.12, poultry $743,103.77, meat products $602,848.81, disposables $327,482.23, bread and dough $276,465.43, pizza boxes $229,283.23 and cleaning products $113,645.06.

Cost of goods on the statement comes from the accounting feed and the cost-of-goods ledger, which you control. Purchasing data informs your view of what is driving COGS but does not silently overwrite your accounts.

Yes, on the dashboard. In the pilot, BOX 2 was top by both — $197,159.83 of value and 12,896 units sold in August.

Not today. Nexora reads your order history rather than placing orders. Purchase ordering is not currently on the near roadmap.

There is a Waste & Spoilage account (500070) in the cost-of-goods chart, so waste can be recorded and reported as a cost line. A dedicated waste-logging workflow is not built.

Yes. Google reviews and your own Nexora review page arrive in one inbox, per store, with replies tracked and timed. The pilot group ran 4.58 stars across 62 reviews with 79% positive sentiment.

Yes, and the product tracks how many are still waiting and your median reply time, so "we reply to everything" becomes a number rather than a belief.

Yes — comments are scored by theme: food, service, speed, value, cleanliness and staff, each with a percentage and a mention count. A rating that falls because of speed is a different operational problem from one that falls because of food.

Yes, there is an Ask for a review action, and reviews collected through Nexora appear alongside Google's in the same inbox.

Once per store, in Settings → Review connections. Read-and-reply access only.

By rating, by source, by store, by date range, and by whether they still need a reply.

Reviews sit alongside the operational data for the same store and period, which is where the value is: a speed score that drops in the same week overtime spiked is a staffing story, not a kitchen story.

Yes, for their location. Reviews are part of running the store, so they are inside the store manager's scope.

A question box over your own data. Ask in the words you would use with your accountant — what were total expenses last month, which store had the highest labour cost this week, show me the top five expense categories this quarter — and it answers from your ledger.

It answers from your records and shows the breakdown behind the figure. Asked for June's total expenses in the pilot, it returned $52,052.83 and then listed every category that made it up, so the answer can be checked rather than trusted.

Yes. It renders the same figures as a visualisation as well as a table, which is usually how the shape of a month becomes obvious.

Yes — Schedule by voice in NexAI accepts spoken instructions such as "create a shift for Sarah, Monday 9am–5pm", "delete Bradley's Friday shift" or "publish this week".

It operates inside the same scope as the person asking. Someone who cannot see group financials in the interface cannot obtain them by asking for them.

This is the right question, and it deserves a written answer rather than a marketing one — from us or from any vendor you evaluate. Ask for the data-handling position in writing before you connect a point of sale, and read it.

What can be stated from how the product is built: NexAI answers from your own ledger, scoped to exactly what your session is entitled to see, and every figure it returns draws the breakdown behind it so you can trace the number to the rows it came from. It is a question box over your data, not a general-purpose assistant that happens to have seen it.

The formal data-handling and processing terms are issued with your agreement.

Aggregations and comparisons over periods, stores and categories — totals, rankings, top-N, and "which store" questions. It removes the need to know which screen a number lives on, which is the largest practical barrier to a busy operator using any reporting tool.

It answers from what is in the system. If your POS employees are unmapped, NexAI will report the same incomplete labour picture the rest of the product does — accurately, and with the same coverage warning.

Yes. Each scheduled report arrives as a NexAI summary of the period with the full report attached as a PDF, so the email is readable on a phone and the detail is there when you want it.

Three intelligence modules currently marked Coming soon. Insights will surface anomalies and ranked opportunities without being asked; Benchmarking will place a store against its own history and the rest of the estate by percentile; Forecasting will project sales and the labour they imply, and be held to account against actuals.

Nexora does not publish a price list, and not as a negotiating tactic.

A four-store group on one POS and a twenty-store group carrying two POS systems and 300 unmapped employee records are not the same implementation. A single number on a page would be wrong for both, and you would find out which way at the worst possible moment.

What happens instead: twenty minutes on a call, we scope the estate — locations, point of sale, headcount, what you need reported to whom — and you get a figure in writing the same week. If you want a range before you spend the twenty minutes, say so in the demo form and we will send one.

Neither on its own. The quote is built from your estate as a whole — how many locations, how many POS systems, how many people need reporting access — not a flat per-seat or per-location rate. Bring those answers to the scoping call and the quote takes minutes rather than a round of emails.

A person with access to Nexora — an owner, a director, a GM. Your hourly staff who appear on the rota are not seats; they are team records, and there is no per-employee charge for scheduling them.

There is an evaluation tier — it exists in the platform's own permission grid as a real scope, not a demo sandbox with fake data in it.

What it is worth to a multi-unit operator depends entirely on setup, and this is worth understanding before you start any trial of any product in this category. Until your POS is connected and your employees are mapped, every labour figure you see will read low — because unmapped POS employees carry hours that reach no report. A fourteen-day clock that expires while you are still chasing POS credentials has told you nothing.

So the scope and the length are agreed with you on the call, against your actual setup timeline.

Terms are agreed per group and confirmed in writing before you connect anything.

Our position as a young product is that lock-in earns nothing. If the numbers are not useful you should be able to stop — a long contract does not make the product better, it only delays our finding out that it was not working.

Implementation is quoted with the estate, so you see it before you agree to anything rather than as a line item afterwards.

For multi-unit groups we run the first configuration with you, and we would do it even if it were free. The single highest-value setup task in the product is clearing the unlinked POS employee list — until it is done, labour cost coverage sits below 100% and every labour ratio you look at reads low. It is also the task most likely to be done badly by someone doing it alone for the first time.

Yes — tell your account contact and it is added to the estate at renewal, priced the same way the original quote was: against what you actually run, not a metered overage.

Tell us how many point-of-sale systems your estate runs before you ask for a number. It is the largest single variable in an implementation, and any quote given without it will move.

Connections are scoped and priced with the estate rather than appearing later as a surprise line.

Annual terms are available and priced on the call. Ask for both figures — monthly and annual — and decide with them side by side.

We would rather discount a commitment you actually want to make than advertise a percentage that assumes it.

Those are scheduling-first products and good at it. The difference is where the workflow ends: a scheduling tool finishes when the rota is published; Nexora prices the rota, charges it against a labour budget and reconciles it against the till the next morning, then rolls it into a store P&L. If all you need is a rota, a scheduling tool is cheaper and you should buy one.

Restaurant365 is an accounting-first suite built around a full general ledger, and for groups that want to replace their accounting stack it is a serious product. Nexora sits earlier in the chain — between the POS and the P&L — and is designed for operators who want the operating picture weekly without migrating their accounting.

No. Nexora reads your existing POS and has no interest in replacing it.

No. Approved hours and labour cost export to payroll — QuickBooks today.

Yes, and most groups do for the first month. Run your existing scheduling in parallel, compare the labour numbers at the end of the period, and switch when Nexora's reconcile against the till and the existing ones do not.

POS employee mapping, and we would rather say so up front. It is a one-off afternoon for most groups, it applies retrospectively to all historical hours, and until it is done your labour percentages will read low.

Staff rosters import by CSV. Historical expenses can be brought in through the document extractor by uploading past statements. POS history comes through the POS connection itself.

Talk to us. Most groups at that scale are already running their own data warehouse and a dedicated integration team, and we would rather have that conversation directly than guess at your architecture from a web form.

Then a point solution is probably better value. Nexora earns its price when the schedule, the roster, the purchasing and the money are the same data — that is the whole argument.

You should not, on our word. Run the pilot on your worst-performing store, keep your existing process in parallel for a month, and check whether our figures reconcile against your POS and your accountant's. That is a test we are happy to be judged on, and it is the reason the product surfaces its own data gaps rather than papering over them.

Support runs by email to the address on your account, and through the person who configured your estate rather than through a queue that has never seen your data. During implementation that is direct access; afterwards it is the same address.

Response targets are set out in your agreement. Ask for them in writing before you sign — from us, and from every other vendor you are looking at.

Yes. Every report exports to Excel or PDF, and API keys are available for programmatic access.

Your data is yours and it leaves with you.

Everything the platform reports on exports while you are a customer, not only at the end: the P&L statement and the store comparison, labour reports, expense reports and the plan-versus-actual variance all download as Excel or PDF from inside the product. API keys are available under Settings → Developer if you want to pull the whole account programmatically.

Export before you close the account. The retention and deletion terms — how long data is held after termination and how deletion is confirmed — are set out in your agreement; ask for that clause specifically and read it.

Nexora runs on managed cloud infrastructure. The region and provider are named in your agreement — ask for them on the call, in writing, before you connect a point of sale.

If your group has a data-residency requirement, raise it in the first ten minutes. It is a genuine yes-or-no and neither of us benefits from discovering it in week six.

The product is in active development, and service status is communicated to your named contact directly rather than through a public page.

If a public status page and a published uptime history are a procurement requirement for your group, raise it before you evaluate. It is a reasonable thing to require, and it is better established at the start than assumed.

Yes — Corporate Library holds store updates, franchise rules, policies and training material, filed per store. A Required Actions module that tracks who has acknowledged what is marked Coming soon.

Nexora is a responsive web application. It runs in a phone or tablet browser at the same address, with the same one-time-code sign-in and the same scope — which is how a district manager reads the overtime radar from a car park between visits.

There is no separate native app to install, update, or leave sitting on the phone of someone who left in March. Removing their access in Command Center removes it everywhere, immediately.

US English and US dollars, across US time zones — the live pilot estate spans locations from Michigan to Florida to Ohio, including America/Detroit.

If your group operates outside the US, or needs a second currency in the same set of books, that is a roadmap conversation rather than a settings toggle. Raise it before you evaluate rather than after.