ESTONIA / ECONOMY & IDEASPerspectives & context
Majandus.Estonia in perspective
EN ET

Business operations · Estonia

A first-month plan for organising small-business workflows in Estonia

Map one workflow, record where it waits and test one change. A practical first-month approach for small businesses operating in Estonia.

A customer sends an enquiry, one colleague clarifies the task and another starts work. The agreed deadline stays in a message that the second person never sees. Start by mapping one such handover. In a first planning cycle, document the process, record a baseline and test one limited change. This guide is for owners of small businesses operating in Estonia who need a practical starting point before choosing new software.

1. Choose a process with a visible start and finish

“Improve sales” is too broad for a first trial. Choose a repeated section of work: a new enquiry becoming an accepted assignment, a finished task reaching customer acceptance, or an access request reaching the person who needs it. Define the starting event and the result the next participant accepts.

The example below is a fictional service business. A customer sends an enquiry, a coordinator clarifies the scope and deadline, and a delivery colleague confirms that the information is sufficient to start. The process ends at that confirmation. Invoicing and bookkeeping handovers are outside its scope. The example illustrates a working method; it is not a case study of an observed Estonian company.

2. Map the handovers that actually happen

Review a few recent enquiries with the people who handled them. Find where the agreed conditions were recorded, who requested missing information and how the delivery colleague knew an assignment was ready. Record waiting and returns for clarification alongside the planned steps.

Use seven fields for each step. A shared document or an existing work table is enough to prepare this record.

  1. Step: the action the participant performs.
  2. Input: the event or record received.
  3. Owner: the person responsible for the next action.
  4. System: where participants find the record.
  5. Output: what is passed on and what makes it ready.
  6. Frequency: when and how often the work occurs.
  7. Observed problem: a specific wait, repeated action or missing item.

In the example, the coordinator receives the customer's message and creates an assignment with the task, expected result, deadline and delivery owner. The colleague accepts it or returns it with a list of missing details. Each transition leaves a record. Saying that a task was passed on does not establish that someone accepted it.

3. Select one problem you can observe

Choose a repeated issue visible in the records. Suppose assignments reach delivery without an agreed deadline. A first change is to require the coordinator to enter the deadline or explicitly mark it as unconfirmed before handover. Starting work before agreement then needs a separate decision by the responsible person.

Keep that trial separate from replacing the CRM, rebuilding the website or restructuring the team. Combining changes makes their effects hard to distinguish. If the cause of the problem is unclear, collect more observations before choosing a tool to address it.

4. Record a baseline and its boundaries

Appoint one process owner to check that records are complete and decide which exceptions need discussion. This person does not have to perform every step.

Before the change, record the selected assignments, handover and acceptance times, completeness of required fields and reasons for returns. Distinguish active work from waiting. A missing timestamp means the duration is unknown; it does not mean zero minutes.

Write down the observation period and selection rule. For example, include every enquiry of one defined type during a working week. This is an illustrative selection rule, not a universal minimum. If enquiries are infrequent, extend observation until actual handovers are recorded. Do not calculate an average from an empty set.

5. Write a short trial record

State the change in one sentence: “Pass an assignment to delivery with its expected result, owner and agreed deadline recorded.” Add the scope, process owner, observation period and location of the records.

Set continuation and stopping conditions before starting. In this example, an assignment needs complete fields and an explicit acceptance. If the new method prevents access to required information or loses records, stop the trial and restore the previous handover method. These are conditions for the example, not a promise of a particular productivity level.

Preserve the original records and describe how to return to the previous method. Do not delete working data to create a clean experiment. Where systems or permissions change, check a safe copy and identify the person responsible for recovery first.

6. Give the first month four separate jobs

Use week one to map the process and check it with participants. Use week two for baseline records under the selected rule. In week three, introduce one change for a limited set of assignments. Use week four to compare records and decide whether to continue, revise or stop.

This schedule is an editorial planning model, not an EIS standard or a guaranteed implementation timetable. A long approval cycle needs a different calendar. If the types of assignments differ between observation periods, record the difference: task mix itself affects completion time.

7. Review the records before choosing software

Check which returns remain, whether new waiting has appeared and how much manual effort the method requires. Keep unsuccessful cases in the review. A successful week alone does not establish causation or a return on investment.

If the current tool can hold the required fields and handover records, use it for the first cycle. Specify the requirement that the existing arrangement cannot meet before choosing a replacement. Describe record export, participant permissions and failure handling before purchase. Check actual product features and prices separately with the supplier.

8. Keep Estonia's digital services in their own part of the plan

Access to public digital services and the organisation of everyday work answer different questions. Our guide to e-Residency and business planning explains the boundary around digital access. Access to a service does not assign ownership of a customer enquiry.

EIS describes a digitalisation roadmap as an assessment of processes and a plan for changes. The first-month approach here is an independent, smaller working model. On 3 November 2026, the page for the earlier roadmap grant states that applications are closed. Do not make this trial depend on an assumed grant award. Check other programmes and their conditions separately.

9. End the cycle with a recorded decision

Bring the process map, baseline records, trial record and list of exceptions to the review. Choose the next task from the problem you found: clarify the assignment record, define measures, check access or repeat the trial for another type of work. If the records are insufficient, state that and extend observation.

The useful output of the first cycle is an understood process and a reasoned next step. Sales growth, time savings and investment returns need their own measurements.

10. Sources

  1. EIS: Digitalisation.
  2. EIS: Grant for digitalisation roadmap; status checked 3 November 2026.