Project management

Asana already has projects, sections and assignees. Your website does not know any of that exists

A visitor fills in a quote request form. It arrives as an email, sits in a shared inbox until someone has five minutes, and eventually becomes an Asana task — in whichever project the person creating it happens to have open, assigned to whoever they think of first.

None of that is a problem with Asana. Asana does exactly what it says it does: projects, sections, tasks, custom fields, an assignee per task. The gap sits between the form and the tool, and nobody designed it on purpose.

  • REST API, webhooks or a maintained connector
  • Tasks, sections, custom fields and assignees
  • From €1,700 plus service fees
The tool

What Asana is, and which part of it a website actually touches

Asana is a work management tool built around projects, with sections inside a project and tasks inside a section. Custom fields carry the detail a status alone cannot — priority, an order number, a client name. Portfolios group projects for anyone who needs one view across several. Its webhooks are genuinely good: a task moving or a field changing can tell your website in near real time, instead of your website having to ask.

The request we get is rarely "connect Asana to the website." It is specific: a form or a paid order has to open a task in the right project and section, with the right custom fields and the right assignee — not a task in a general inbox for someone to read, understand and refile before any work starts.

What goes wrong

Three things that go wrong before a request becomes a task

Not hypotheticals — this is what an unconnected form or shop looks like from the inside, on any team that uses Asana for what follows.

The Friday afternoon request nobody owns

A quote request lands in the shared inbox on Friday afternoon. On Monday three people have each half-answered it, and nobody knows whether it was sent. It never became a task, because that meant somebody deciding which project it belonged to, and nobody did that over a weekend.

What you see instead

The form submission becomes a task the moment it arrives, filed by a rule instead of by whoever reads the inbox first. Friday afternoon looks like Tuesday morning.

Every task made by hand starts in the wrong place

Someone busy files their own reminder into whatever project happens to be open, or into a general "Inbox" project nobody empties. We have seen those with sixty tasks in them, a third unassigned, because filing one properly takes longer than creating one badly.

What you see instead

A task from a form or order arrives already filed — project, section, and the fields someone would otherwise fill in later, or never.

A status question means opening two tools to answer it

A client emails asking where their request stands. Answering means opening the website or CRM to find the request, then Asana to find the task, then translating "In Progress" into something a customer can read. Multiply that by however many land in a week.

What you see instead

A status change fires a webhook that updates a field the customer already sees. The question mostly stops arriving, because the answer already is.

The bill for doing it by hand

What manually filing requests into Asana costs, and when it does not matter

Filing a request properly — reading it, choosing the project and section, filling in the fields, assigning it — takes three to five minutes done well, thirty seconds done badly, which is why it is so often done badly. At twenty requests a week and four minutes each, that is five to six hours a month, around €250 at an internal cost of €45 an hour.

That number alone will not change anyone's quarter. What does is the badly-filed version: the unassigned task nobody notices for three days, on something time-sensitive. Below a handful of requests a week, with one person always filing them into one project, this is honestly not worth building — the case gets real once there are enough requests, or enough different projects and people to choose between, that getting it right by hand every time stops being realistic.

What we build

We build the thing on the other end too

With Asana the connection itself is simple; the design work is the mapping rules that decide which project, section and assignee a form or order belongs to, and that is where we spend the first conversation.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Asana and your website or shop

Asana's API is a documented REST API with a solid webhook system and custom fields that can carry real data, not just text. The arrow says which way something moves.

  • Form submissions or orders as a new task

    Project, section, title and custom fields set from the form type or product category, with an assignee set by a rule — round robin, by category, or by whoever already owns that client.

  • Task status back onto the site or a portal

    A webhook fires on a status or field change and updates something the customer already sees, so answering "where is this" does not need Asana open.

  • Order or form details into custom fields, not the description

    An order number, a deadline, a budget — each its own field instead of buried in a paragraph, so it can be filtered, reported on, and used in an Asana rule.

  • Comments between a customer-facing tool and the task

    A message left in a portal appears as a comment on the task, and back again, so nobody needs an Asana login to follow one request.

Most projects use the first two rows: a task filed correctly, and its status visible without a login. The rest is worth adding once that has run for a month.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Asana specifically: the API and webhooks are well documented, so most of the cost sits in the mapping rules rather than the connection itself, and it is cheaper again if JKC already built the form or shop the request comes from.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Asana

Webhooks and most of the custom fields a mapping rule depends on need a paid tier — the free plan is built for a team working inside the app, not a system talking to it from outside. We check your plan before quoting, because it changes what is possible more than anything else here.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan