From the closed week to Monday's review.

One week in Kelynto, start to finish: what the system does without anyone watching, what your planner does, and who owns each step. The days below are an example. You set the fiscal week, the time zone and the hour the review is drafted.

The week, step by step.

Seven steps. Four run on their own. Three belong to your planner, and those are the ones that decide what leadership reads.

  1. Fridayor whenever your week closes

    The closed week's file arrives

    Your planning system, your warehouse or an analyst exports the week that just closed: actual sales and plan by store and category. In-stock rates and promotions come along if you send them. The file is uploaded in the app, or posted to the upload endpoint by a scheduled job on your side.

    Nothing is installed in your network and Kelynto does not pull from your systems.

    Owner Your data team or an analyst

  2. On arrivalseconds to minutes

    Every file is checked before it is loaded

    The loader reports how each column was read and names the rows it could not read. A file with errors in more than one row in five is rejected outright, and the data already loaded is left unchanged, so a bad export cannot overwrite good weeks.

    Uploading the same file twice is safe: rows are matched and updated, not duplicated.

    Owner Kelynto checks. An analyst reads the report and fixes the export if needed.

  3. Before the runautomatic

    Outside signals are refreshed

    Weather and weather alerts are looked up for your store coordinates. Local events and road work are added if an administrator has switched those sources on. Facts only you know, such as a competitor opening or a remodel, come from a signals file you send.

    A source that fails does not stop the week. The review is drafted with the signals that arrived.

    Owner Kelynto. An admin chooses which sources are on.

  4. Monday 6:00the default, in your time zone

    The review is drafted

    The weekly run splits the variance to plan by region, category and store, tests each candidate cause against its evidence, and groups what survives into findings. It builds the radar for the next three weeks and scores last week's radar against what sales then did.

    The commentary is then written from those facts by a deterministic template, and every number in it is checked against the week's data. The method is set out step by step on the Methodology page.

    Owner Kelynto. You set the day and the hour.

  5. Monday morningthe planner's part

    The planner reads, checks and corrects

    The draft is already written when the planner opens it: the headline variance, the drivers by region, category and store, each cause with its evidence and confidence, and a preview of the radar. The planner opens the evidence behind each cause and confirms it, rejects it, or corrects it to the cause they know is right. Then they edit the wording in their own voice.

    They also mark each radar item as new to them, already known or not relevant, and answer two questions: how many minutes the review took, and whether they would use this every week.

    Owner Planner

  6. Mondaybefore the business review

    The planner publishes and sends it up

    Nothing reaches leadership until a person publishes it. The published review can be copied with formatting into email or slides, downloaded, or printed, and leaders with a viewer role can read it in the app. A published review can be reopened, and every version is kept.

    Owner Planner. Leadership reads.

  7. The weeks afterautomatic

    The week is scored

    The planner's confirmations and rejections adjust how confident Kelynto is in each type of cause for your business. The difference between the draft and the published text becomes the edit rate. When the next weeks' sales arrive, each radar call is marked right or wrong.

    All of it lands on the scorecard, which the planning leader reads to decide whether this is earning its place.

    Owner Kelynto computes. The planning leader judges.

No planner time figure is quoted here because none has been measured on a real team. The two pulse questions exist to measure it on your own weeks.

Who does what.

Four roles inside the product, checked on every request, and three jobs outside it. With single sign-on the roles come from your identity provider, so removing a role there removes the access.

RoleWho it suitsWhat they do
ViewerLeadership, store operationsReads published and in-progress reviews, the radar and the scorecard.
PlannerDemand and merchandise plannersEdits the commentary, confirms, rejects or corrects causes, marks radar items, publishes.
AnalystPlanning or data analystsEverything a planner can, plus uploading data, re-running a week and exporting the labelled dataset.
AdminThe workspace ownerEverything, plus users, workspace settings (fiscal week, time zone, thresholds, signal sources, schedule) and the audit log.
Your data teamOutside the productBuilds the weekly export, by hand at first and as a scheduled job later.
Your IT teamOutside the productRegisters the application in your identity provider and assigns the four roles.
Kelynto operatorOutside the productCreates the workspace and registers your identity provider. In a pilot, can run the first weeks by hand.

Two limits to know. There are no custom roles, and no permissions by region or category: everyone in a workspace sees the whole workspace.

What goes in.

Two files are enough for a first review. Everything is weekly totals.

  • Stores. One row per store, with a store number and region. Coordinates are strongly recommended: without them no weather, event or road work can be matched.
  • Sales against plan. One row per store, week and category, with actual and plan.
  • In-stock, if you have it. This is what lets a draft tell a stockout from a demand problem.
  • Promotions and local facts, if you have them. One row per promotion or per fact.

The full list of files and columns

What comes out.

One review a week, and a record of what your planners made of it.

  • The published review, in the planner's final words, with the stores and evidence behind each cause.
  • The radar for the next three weeks, with each planner's verdict on each item.
  • The scorecard, four measures with their sample sizes.
  • A labelled dataset you own: signal, business impact, the cause a person confirmed, and the outcome. It can be exported at any time.

When something goes wrong.

Weeks are not always clean. This is what happens in the cases that come up.

  • The data is late. The scheduled run is tried again about an hour after a failure, four attempts in total by default, so a file that lands mid-morning is picked up the same day.
  • The export is wrong. The file is rejected with a report that names the columns and rows at fault. Nothing is loaded and existing data is untouched.
  • A run is interrupted. It is marked failed with its reason and has to be started again. A run cut short by a restart is not resumed.
  • The evidence is thin. Nothing is credited. The variance is listed as not yet explained, with a note when a promotion or event was on file and what it covers did not move beyond normal variation.
  • The draft names the wrong cause. The planner rejects or corrects it before anything is published. Each rejection lowers the confidence of that cause type and shows in the cause hit rate.
  • Two people edit at once. The second save gets a clear conflict message. Nothing is silently overwritten.

Before the schedule exists.

A pilot does not have to wait for single sign-on or an export job.

  • The first weeks can be run by hand. You send the week's files, a Kelynto operator runs the week and sends the exported commentary by email.
  • Your planner replies with edits and verdicts, and the operator enters them on the planner's behalf. The edit rate and hit rate are measured the same way.
  • The trade-off is stated. In this mode Kelynto staff handle your files and enter your planner's feedback, so it belongs in the pilot agreement.

Status today

  • The workflow on this page is built and was rehearsed end to end with a synthetic retailer
  • No real customer has run it yet, and the hosted service is not running
  • The outside signal sources have not been exercised from a live deployment
See what a pilot involves Or book a 20-minute conversation

Four ways to take the next step.

  1. Explore

    See the product

    The sample workspace is not open to visitors yet. The product tour shows nine real screens from it.

    Take the product tour

  2. Evaluate with your data

    Run it on your own weeks

    A backtest on your past weeks, then about six live Monday reviews, judged on four measures agreed before it starts.

    See what a pilot involves

  3. Deploy in your environment

    Check the architecture

    What runs where, what crosses the boundary, and how far each path has been proven. Azure first.

    Read the deployment notes

  4. Talk to us

    Twenty minutes with the founder

    Your process and your questions. Or write to marc@kelynto.com.

    Book a 20-minute conversation

Kelynto is an early-stage company opening its first pilots with retail planning teams. The product is built and tested on synthetic data. There are no customers and no results yet, and this site says so wherever it matters.