tensorgardenProposalFull documentPDF ↓
Short overviewFictional example

Spend less time chasing the next step.

Make ownership, status and handoffs clear in the request software your team already uses.

Your software

Stays in place.

We improve the existing request workflow instead of adding a new portal.

Your decisions

Stay with you.

You set the priorities and approve any extra work before it starts.

Where does the day go?

Unclear handoffs create work of their own.

In this fictional business, requests already move through one system. The avoidable effort comes from not knowing who has what, or what happens next.

  1. No clear owner

    A request waits until someone happens to notice it.

  2. Status means different things

    The next person has to ask what was already done before they can start.

  3. The same routine questions

    Someone stops their own work to explain the process again.

An illustrative scenario for a business with 20+ employees, not a diagnosis of your team.

Fix the friction. Keep the software.

Two priorities, in an order you agree before delivery starts.

Priority A

Fix the daily queue.

  • Clarify request categories and ownership.
  • Make unassigned requests visible to the team.

Priority B

Make status easier to understand.

  • Use consistent status labels and handoff notes.
  • Add a short guide for routine request questions.

You confirm what fits, what comes first and what waits. In this example, the queue comes first.

Not included: new features outside these priorities, until you authorize them separately. Scope and capacity are agreed for each customer; no universal allowance is implied.

See who owns the next step.

Each request shows its category, its accountable role and its current status. Requests with no owner are highlighted, so the coordinator can assign them first.

Concept preview with sample data. Request queue showing category, owner and status for six sample requests, with three unassigned requests highlighted and an Unassigned 3 filter.
Concept preview, sample data. Six sample rows from the proposed queue in the existing request software.

Concept preview · sample data

Three highlighted rows

Sample requests with no owner yet, also counted in the Unassigned filter.

One accountable role

Every assigned request names the role responsible for the next step.

A handoff that carries the context.

A consistent status plus a short handoff note tells the next person what was checked and what comes next.

Status only

SR-1433 · Shared printer not connecting

  • Status: New
  • Owner: Unassigned
  • Handoff note: none

Status with a handoff note

SR-1433 · Shared printer not connecting

  • Status: In progress
  • Owner: IT support lead
  • Handoff note: Connection checked at the workstation. Please confirm the selected printer, clear the local print queue using the agreed guide, then run one test page.
  • Next check: Confirm a test page prints

Illustrative comparison built from one sample request, not your team's current records.

Routine answers, grounded in your guide.

An employee asks how to update a request that needs more information. The answer comes from the agreed guide, names its source and leaves the change to the employee.

Concept preview with sample data. An employee question answered in four steps from the agreed user guide, citing Request workflow section 2, with the note I have not changed the request.
Concept preview, sample data. Answer drawn from the agreed guide; not a live knowledge-base connection.

Concept preview · sample data

Named source

The answer cites the guide section it came from.

People act

AI does not change the request. The employee does.

The aim is less repeated explanation, not a measured result. AI help may use capacity or incur privately agreed charges; it is not always free.

What if we want more?

Extra work waits for your decision.

New requests are welcome. They do not slip quietly into the agreed scope.

  1. Flag

    AI flags that scope or cost may have changed. Added work pauses.

  2. Explain

    Your delivery lead sets out scope, timing, capacity and charge.

  3. Decide

    You, or your named approver, approve any additional charge BEFORE added work begins.

AI never authorizes scope, spending or acceptance.

A clear handover, not just a finished task.

A short list during authorized onboarding. Documents your team can use when the work is done.

To start

What we ask for

  • Confirm the priorities and acceptance criteria.
  • Name the person who approves extra work and accepts delivery.
  • Share requirements, source, admin access and documentation only during authorized onboarding, never through a public form.

At handover

What your team receives

  • Priority register and acceptance checklist.
  • Request workflow guide and routine-question guide.
  • Change decision log, review notes and handover summary.

The decision

Choose the first priority. Name the approver.

These two choices shape the start. Scope, acceptance criteria, fees and capacity are then agreed privately before delivery begins.

Decision 1

Choose the first priority.

The queue first in this example, or the order that fits your team. You confirm what fits, what comes first and what waits.

Decision 2

Name the approver.

The owner or a designated approver: the person who approves extra work before it starts and accepts delivered work.

Nothing is authorized on this page. It is a fictional example, not an offer.

Next: the team asks for something new