Start with one piece of work

Choose one task that your team can describe from beginning to end: a part arriving at a workstation, an inspection being recorded, or a production order moving to the next shift. Write down who does the work, which information they need, and what happens when something goes wrong.

Include the people who do the task every day. Ask operators to describe routine adjustments, checks and exceptions. Include those decisions in the workflow.

Define what the pilot must prove

Agree on the question before choosing equipment or software. You might need to learn whether a machine can handle the range of parts, whether records reach the right person, or whether an operator can recover from a routine interruption. Record a baseline for the existing process and use the same definitions when reviewing the pilot.

Write down the boundary too: which products, shifts, machines, and systems are included. A limited pilot makes it easier to understand why a change helped or failed. It also makes the decision to continue, revise, or stop more concrete.

Plan for the handover

Prepare operating instructions, named owners, a way to report problems, and a clear support arrangement. Training should use the actual workflow and include common exceptions, not just the ideal sequence.

Before extending the system, review it with the people who will maintain it. Keep a list of unresolved issues and the person responsible for each one. The next phase should build on what the pilot showed, rather than on an assumed benefit.

A checklist for your project

• Map the current task, exceptions, operators and systems.
• Define cycle time, quality and recovery criteria using an existing baseline.
• Compare equipment, integration, training and support as one project.

Industrial automation planning

Published by Quindart.

Read this article on Quindart.

Name the decision first

Start by asking what a person needs to decide, and what information would help. Reviewing an inspection image, finding a relevant work instruction, and summarizing a shift report are different tasks. Each needs its own definition of a useful result.

A clear rule or a better connection between existing systems may solve the problem without AI. Comparing those options early keeps the project focused on the work rather than on a preferred technology.

Make review part of the workflow

Decide who checks a suggestion and what they can do if it is incomplete or wrong. A result should arrive with enough context for someone to understand it. Keep the original record available and make corrections easy to capture.

Try examples that reflect real working conditions, including unusual cases. A successful demonstration on a few selected inputs does not establish that the system is ready for every situation.

Improve from actual use

Agree on what to review after launch: useful suggestions, mistakes, time spent checking results, and cases that still require manual work. Give operators a simple way to record those observations.

Use that evidence to decide what to change. Review whether the suggestions helped, how much checking they required, and who needs to follow up.

A checklist for your project

• Collect examples of acceptable parts, defects and borderline cases.
• Test lighting, working distance, field of view and surface variation.
• Define rejection handling, review responsibilities and traceable records.

Machine vision and quality inspection

Published by Quindart.

Read this article on Quindart.

Describe the whole cycle

Map how a part reaches the workstation, how it is positioned, what the task involves, and where it goes next. Include the checks and records that accompany it. The robot is one element in that sequence.

Bring sample parts, drawings, and a description of the variations to an early discussion. A supplier can give a more useful answer when the task and its boundaries are concrete.

Agree on the interfaces

List the equipment and software that need to exchange information. For each connection, name the signal, its source, its destination, and the action it triggers. Include the conditions under which the next step should wait.

Assign responsibility for the complete workcell and its site-specific review with qualified specialists. A component specification alone does not describe the finished installation.

Prepare acceptance and support

Write down the tests that will demonstrate the agreed scope, using representative parts and operating conditions. Make open questions visible before delivery rather than treating them as installation details.

Confirm who provides training, documentation, spare parts, and support. These arrangements influence whether the team can keep using the system after the project team leaves.

A checklist for your project

• Document part geometry, payload, reach, cycle and available space.
• Check tooling, guarding, machine interfaces and recovery requirements.
• Validate representative parts and hand over operating instructions.

Robot integration for production

Published by Quindart.

Read this article on Quindart.

Keep the learning visible

A pilot should leave behind more than a demonstration. Record what was tested, what worked, what required an intervention, and what remains uncertain. Include feedback from the people who operated and maintained it.

Compare the outcome with the original question. If the scope changed along the way, explain why and record which parts of the original goal have not yet been tested.

Check what changes at a larger scale

Another shift may have different experience. Another line may handle different parts. More connected machines may change who needs access to records and who responds to exceptions. List these differences before repeating the installation.

Treat the next rollout as a defined extension, with its own acceptance criteria and owner. Reuse what is understood; make new assumptions explicit.

Make ownership durable

Put operating instructions, configuration records, and support contacts where the team can find them. Agree how changes are requested and recorded after handover.

Review the expanded system at an agreed interval. Choose an owner for each proposed change and record what the next review should check.

A checklist for your project

• Train using normal work and common exceptions.
• Document maintenance tasks, escalation paths and system ownership.
• Review unresolved issues before extending the installation.

Automation training and handover

Published by Quindart.

Read this article on Quindart.

Use consistent definitions

Before building a dashboard, agree what the team means by running, waiting, changeover, and stopped. Different definitions can make two reports about the same shift tell different stories.

Start with a small number of useful states. Include who records a change, when it begins, and how missing or uncertain information is shown.

Connect an interruption to an action

A signal is useful when someone can act on it. Decide which person receives an issue, what context they need, and how they acknowledge or pass it on. Avoid sending every event to everyone.

Keep a record of what happened and what restored the process. That history can help the team distinguish recurring problems from isolated events.

Review the causes together

Use regular conversations with operators and maintenance staff to interpret the records. A number may identify where to look; the people doing the work often explain what it means.

Choose one improvement to test, define what you expect to change, and compare the result using the same definitions. Keep that decision and its evidence with the operating record.

A checklist for your project

• Inventory signals, interfaces, access permissions and data owners.
• Agree on definitions for running, waiting, changeover and downtime.
• Connect alerts to a responsible person and a documented action.

Industrial data and machine monitoring

Published by Quindart.

Read this article on Quindart.

Write the operating context

Describe the task, the parts or materials, the available space, and the existing equipment. Include the working environment, the expected range of products, and the people who will use the installation.

Separate requirements from preferences. A useful specification explains why a requirement exists, so suppliers can propose an alternative without losing the purpose of the project.

Compare complete proposals

Look at the equipment together with tooling, integration, installation, documentation, and training. Ask suppliers to identify what is included and what someone else must provide.

Record unresolved assumptions in the comparison. Two proposals with the same headline price may cover very different responsibilities and support arrangements.

Think beyond delivery

Ask how the installation will be supported, which parts require replacement, and what information the team receives at handover. Confirm who coordinates issues involving several suppliers.

Use the agreed specification to define acceptance. A clear connection between the original task, the supplied equipment, and the handover tests makes the purchasing decision easier to explain.

A checklist for your project

• Separate mandatory requirements from preferences.
• Compare the complete scope, including tooling and installation responsibilities.
• Record assumptions and define acceptance before committing to equipment.

Automation equipment sourcing

Published by Quindart.

Read this article on Quindart.

The problem

Client context was spread across calls, payments, records, and chat. Account managers had to rebuild the story before acting.

The key decision

Keep the team's existing tools, then route the relevant context into the place where the team already coordinates work.

What we built

• Call transcripts classified and attached to the correct HubSpot contact or deal
• Stripe payment success and failure signals routed to the responsible people
• Account manager support that keeps client context close to the daily workflow
• Lead classification that helps people see where attention is needed

Before the project

• Call, payment, and client context lived in separate systems.
• Account managers reconstructed the client story before acting.
• The next owner and next action could remain implicit.

Client context across four tools

Openfair is a business marketplace where account managers work closely with clients. Calls lived in Aircall, payment events in Stripe, client history in HubSpot and follow-up discussions in Slack. Before taking action, the team had to bring those records together.

The project connected each event to the relevant client record and brought the next action into the team’s existing Slack workflow.

Coordinating work in Slack

Quindart considered a separate operating interface, then chose to connect the tools the team already used. Aircall and Stripe remained the sources for calls and payments; HubSpot held client context; Slack directed attention to the responsible person.

Call transcripts were classified and attached to the correct contact or deal. Payment success and failure signals reached the people handling that client. This kept follow-up close to the record that explained it.

The working process

1. A website inquiry, call, or payment event arrives
2. Relevant context is attached to the client record
3. The operating record is updated with the current signal
4. Slack directs the responsible person to the next action

What changed

• Payment and call events are harder to miss
• Account managers can act without rebuilding the story from separate tools
• New staff learn one operating route instead of a collection of disconnected systems

Systems involved

Aircall, HubSpot, Stripe, Slack

The lesson

A useful operating layer does not always need to be another application. It can make the existing route more dependable.

Published by Quindart.

Read this article on Quindart.

The problem

Title records were scattered across files, inboxes, calendars, and personal memory. Portfolio status needed manual reconstruction.

The key decision

Make the title the primary record, with evidence, responsibilities, dates, activity, and status attached to it.

What we built

• A structured mining title database with ownership, company, location, and status information
• Document management connected directly to the relevant title
• Obligation, deadline, and renewal tracking with reminders before action is due
• Permissions, activity history, search, filtering, map views, dashboards, and reporting

Before the project

• Title records were split across files, inboxes, calendars, and personal memory.
• Documents and obligations were not consistently attached to the title they governed.
• Portfolio status required manual reconstruction.

A record for the full title lifecycle

Mining title administration involves ownership, location, supporting documents, obligations and renewal dates. MMAM brings these records together so the team can review a title and see the work attached to it.

Each obligation has a date and an internal owner. Documents, activity and status changes stay connected to the relevant title, giving the team a record to consult during renewals and portfolio reviews.

Connecting documents, dates and responsibilities

The earlier workflow spread records across files, inboxes and calendars. Staff had to reconstruct portfolio status from those separate sources. MMAM uses the title as the main record and links the surrounding work to it.

Search, filters, map views and dashboards support different ways of reviewing the portfolio. Permissions and activity history help teams manage access and follow changes.

Preparing renewal work

The platform tracks upcoming obligations and renewal dates and sends reminders before action is due. Staff can record progress and keep supporting evidence with the title.

Administrative, compliance, legal, management and field teams can work from the same record when preparing a file or checking its current status.

The working process

1. A mining title is registered with its core information and supporting evidence
2. Obligations, dates, documents, and internal owners are connected to that title
3. The system monitors upcoming dates and sends reminders before action is required
4. Progress and evidence are recorded so management can review the portfolio position

What changed

• A clearer view across mining titles and their current status
• Easier monitoring of deadlines and responsibilities
• Supporting documents linked to renewal and regulatory preparation
• Less dependence on individual memory for portfolio knowledge

Systems involved

Mining titles, Documents, Obligations, Renewals

The lesson

When the work has a long lifecycle, the system needs to preserve the relationship between the record and every action around it.

Published by Quindart.

Read this article on Quindart.

The problem

A fluent answer is not enough when the evidence cannot be checked or private documents need a clear boundary.

The key decision

Treat retrieval, source context, document privacy, and limitations as part of the product experience.

What we built

• An AI-assisted legal research interface for questions about Moroccan legal topics
• Structured retrieval from relevant legal material before a response is produced
• Citation-supported answers that give users a path back to the underlying material
• Private document upload, analysis, saved conversations, access controls, and subscription support

Before the project

• General-purpose answers could sound certain without a controlled Moroccan legal source base.
• Users had no dependable route from an answer back to material they could inspect.
• Private document analysis needed a boundary from public legal knowledge.

Research grounded in Moroccan legal material

Jurist.ma is an AI-assisted legal research and document-analysis platform focused on Moroccan law. It helps users find relevant material, ask questions and inspect the sources behind an answer.

The research flow retrieves relevant legal context before producing a response. The answer presents available sources so users can return to the material and review it.

From question to source

Quindart designed the workflow around four steps: ask a question, retrieve relevant material, generate a structured response and present sources for review. The interface keeps that sequence visible to the user.

A source trail supports review of the response. Users still need to assess whether the material applies to their situation and obtain professional advice when required.

Keeping private documents separate

Users can upload a document and ask about its clauses, sections and meaning. The platform keeps this private document context separate from the public legal knowledge base.

Accounts, access controls, saved conversations and subscription support form the surrounding product. Document analysis provides an initial review that the user can check against the original text.

The working process

1. A user asks a question or uploads a document for review
2. The platform finds relevant material from the appropriate context
3. The response is generated with that context and available sources are surfaced
4. The user reviews the information and remains responsible for professional judgment

What changed

• Relevant legal information retrieved before an answer is generated
• A more transparent way to explore answers than a general purpose chatbot provides
• A useful first pass for long documents without treating the result as legal advice
• A searchable product experience built around an existing legal content library

Systems involved

Legal knowledge base, Source retrieval, Document analysis, User accounts

The lesson

Trust is designed into the route from question to evidence; it cannot be added after the interface is finished.

Published by Quindart.

Read this article on Quindart.

The problem

Job seekers repeated research across listings, recruiter profiles, and company pages while trying to decide what deserved attention.

The key decision

Put evidence beside the listing or message instead of asking users to break their concentration and search elsewhere.

What we built

• A browser extension that recognises job listings and presents relevant signals in context
• Listing, recruiter, company, freshness, reposting, salary, and role-relevance analysis
• User accounts, authentication, application support, and a supporting product platform
• Gmail assistance and product infrastructure that keep job discovery and communication connected

Before the project

• Job seekers repeated research across listings, recruiter profiles, and company pages.
• Useful warning signals were separated from the moment of decision.
• Probability and uncertainty could be mistaken for fact without an explanation layer.

Information beside the job listing

Job seekers often decide what to do while reading a listing, recruiter profile or email. Nojob places relevant information in that workflow through a browser extension and supporting platform.

On supported listings, the extension retrieves signals about the role, recruiter, company, listing age and reposting. Users can inspect that context while considering an application.

Explaining what a signal means

An older listing or an inactive recruiter can be useful context, but neither reveals an employer’s private intentions. Nojob presents evidence and risk signals with an explanation of the available information.

The user can examine why a warning appears and where evidence is incomplete, then decide whether to apply, investigate further or move on.

Supporting the browser workflow

The extension has to respond to changes in supported page structures and retrieve information while keeping the host website usable. Its design also accounts for privacy and platform limits.

User accounts, authentication, application support and Gmail assistance connect the listing review with the next steps in the job search.

The working process

1. A user opens a job listing in a supported environment
2. The extension detects the listing and retrieves the available signals
3. The product presents a clear summary of what the evidence suggests
4. The user decides whether to apply, investigate further, or skip the opportunity

What changed

• Listing, recruiter and company research presented beside supported opportunities
• More informed application decisions before a user invests time in an application
• Clearer continuity between job discovery, evaluation, and recruiter communication
• A product that explains uncertainty instead of presenting a probability as fact

Systems involved

LinkedIn, Gmail, Browser extension, User accounts

The lesson

The best interface is often the one that respects the environment where the decision is already being made.

Published by Quindart.

Read this article on Quindart.